jaen

Doesn't really matter for H-Nets. These are Unicode bytes, as you said, so the nets can recover their structure (as demonstrated in the article!).

(I guess the training these could be somewhat more efficient if it was codepoints instead)

Bytes are not used as tokens here and are in some sense an arbitrary choice (but they are a good one).

The article's approach just requires some indivisible base "atoms" to start the building the larger "tokens" from. (see: the DNA example)

It could be raw bits, but that's pointless, since dividing bytes into bits does not give the model any extra expressive power and requires 8× more computation. (yes, there's some structure at the bit level eg. lowercase/uppercase is represented as a bit in ASCII, but that's trivial to learn from just bytes at the scale the model operates)

Bytes are the ~best point on the expressivity/computation curve for this approach (for text).

(something else to ponder - why do bytes have 8 bits?)

For those who might wonder, Blackfin is a CPU architecture with an assembly language thas has a more pseudo-codeish syntax [1]:

    R0 = R1 + R2

[1]: https://en.wikipedia.org/wiki/Blackfin#Core_features

No point in hashing, it's trivial to infer the license plate from the hash since the space of license plate numbers is finitely small - one can just brute-force calculate a hash -> license plate table (also called a rainbow table).

The project just exposes everything the hardware can do, the audio codec chip used for the conversion is Burr-Brown PCM3168A 24-Bit, 96-kHz/192-kHz, 6-In/8-Out.

This seems to rebuild the entire view from scratch on every model update? Or is there some diffing magic that's not shown in the article?

This loses all non-persistent UI state such as scroll positions, half-entered text etc. etc.

Not really a workable architecture for a real app. React was invented because of this problem (how to make functional-style view building actually work...)

Exactly the same thing also happened in 2020 with the Facebook SDK:

https://news.ycombinator.com/item?id=23097459

If by enums you mean sum-type ADTs (like in Rust), then Python is certainly quite expressive - it has union types, which can represent polymorphic variants - those are slightly more expressive than pure Rust-style ADTs since you can arbitrarily subset or extend the enum cases.

  @dataclass @final class CaseA[T]:
     field: T

  type MyEnum[T] = CaseA[T] | CaseB

This also gets exhaustiveness checking in `match` statements (depending on the type checker). Overall, enums have a similar style to Scala and Java >=21 (mixing OO + ADT). I guess syntactically it can be slightly verbose depending on the exact situation... I wouldn't call them second class, but yeah, not a lot of existing libraries use this style.

Typed dicts (with the latest PEPs) are an improvement over any other language besides TypeScript. Yes, in TS, certainly `Partial` / `Pick` / `Omit` and intersection types make modeling the web API swamp easier, and that's one place TS is superior to anything else.

Python does have the Type Manipulation PEP 827 [1] out to give it similar powers to TS, but I feel that's unlikely to be implemented soon / as-is.

Having an effect system for exceptions would be nice indeed. That's actually something I'm looking into (having an "allowed exceptions" annotation for functions and then checking it at test-time via failure injection and possibly in type checkers).

[1]: https://peps.python.org/pep-0827/

Python has a strong, expressive static type system with a very fast type checker (Pyrefly).

Fun times...

This is before the DOM Canvas 2D API existed, so effects like digging are implemented by overlaying multiple 1px-high black GIF <img> tags over the background.

More detailed presentations about the Monaka CPU:

wccftech summary: https://wccftech.com/fujitsus-monaka-chip-3d-stacks-2nm-cpu-...

2026: https://global.fujitsu/-/media/Project/Fujitsu/Fujitsu-HQ/te...

2023: https://global.fujitsu/-/media/Project/Fujitsu/Fujitsu-HQ/te...

FugakuNEXT, the supercomputer it will be used in, also some details about the next-gen Monaka-X: https://global.fujitsu/-/media/Project/Fujitsu/Fujitsu-HQ/te...

For a single CPU: 844 GB/s memory bandwidth (12 channels of DDR5 RDIMM, 8800MT/s). 4.3-6 TFLOPS.

Basically comparable to a modern (although not top-end) GPU, so good for HPC & AI workloads. (though only 2 CPUs per node, with GPUs 4-8 is more common)

Previous discussion of this on HN (2009): https://news.ycombinator.com/item?id=634692

For anyone else wondering what Loom is, it's a concurrency permutation testing tool in Rust:

https://docs.rs/loom/latest/loom/

You're just offering non-helpful ivory tower criticism without even understanding the problem space (which is actually one of the hardest open research problems in software engineering, cs.PL + formal methods).

But if I'm wrong, dare say, how would you write a production memory-safe JIT compiler today?

This is only applicable to die photographs of the silicon layer.

For CT scans, which use X-rays, the visible structure is very likely due to the metallic (copper) interconnect, clock- and power-delivery layers, which are generally quite different from the underlying transistors.

These layers are larger-scale, and copper also absorbs X-rays much more strongly than silicon.

No... Adaptive sampling is a family of statistical methods to choose an appropriate decimation strategy for arbitrary events based on real-world occurrence distributions.

It can be applied to tracing, metrics, logging ("sampling") and profiling.

I'm sure the writer knew this possibility since the article is written/edited by Claude.

I think you overestimate the amount of senior engineers... even at the extreme end of top-tier big tech, only around 30% can be considered senior. Staff engineers who regularly think at the level GP talks about are 5-10%.

Everywhere else the percentages are quite a bit lower still (if judged by the same standards).

What? All of this has been solved for a long time. How do you think hyperscalers do this?

Search keyword: "Adaptive sampling"

Yeah, it's very likely GLM.

Trick: it's easy to check this - just try eg. a specific short almost-nonsense high-entropy phrase such as "Scarf Color Plump 蘼撅" via OpenRouter using the playground for different providers/models, and observe the shape and language of the reasoning and the response, which tend to be quite different (MiMo and GLM are quite similar, but still identifiably different enough).

(as I and others have mentioned in the thread): The attacker can just move the malicious code from build.rs to lib.rs (ie. build-time -> test/execution-time).

Then the problem is the language, as the grandparent observes.

The only safe solution is to review all the code's changes (or trust someone else to do it).

Forbidding compile/build-time shenaningans is trivially bypassable and has already been bypassed in the NPM ecosystem by just making the library code itself (not the build scripts) malicious - eg. do the bad thing when the code is loaded/tested, assuming the language has static constructors.

The slightly sad part is that most of these LLM-assisted fixes probably never make it upstream, so life for non-technical Linux users does not improve...

If you do AI fixes, for the greater good, at least publish them (or even better, try to submit upstream, although expect to be ignored if the upstream does not like slop...)! :)

Do you have any more insight into its progress?

Seems like it's far from production-ready and there hasn't been much activity this year?

WASM is not a substitute for Fil-C.

WASM is not memory safe in the same sense, in particular, heap corruption vulnerabilities still exist, which could eg. allow bypassing auth, leaking private information etc.

C compiled to WASM is still vulnerable to something like OpenSSL Heartbleed. Fil-C (and CHERI) is not.

Naah.

Solvable by turning the usual C library allocation pattern inside-out:

Only the C side allocates, Rust gets views of that memory.

Also well established - calling WebAssembly components requires exactly the same pattern, as the only way to malloc is to call into the WASM side.

Errrrr... how is the first paper related to A* and path finding?

It's about "planning" (ie. searching an action space) which does not generally have a heuristic, so it needs to do "exploration" (which is exactly the opposite of what you want for optimal path finding) to counteract getting stuck in local optima due to greedy search...

Choosing 8×8 blocks is very likely highly suboptimal when it comes to the quality of the codec.

The point of the 4×2 tiles is exactly to avoid the blockiness artifacts of vector quantization (visible in the article).

Larger tiles increase the average error and entropy because of the way VQ works - it tries to find blocks that look like each other and then encode all similar blocks by referencing a single tile (usually choosing the "average" or "mode" the blocks).

As tiles grow larger, the chance to find highly similar blocks obviously decreases (and deviation from the representative tile increases).

Reducing one of the dimensions is probably better positioned on the quality-speed frontier.

I didn't imply that you were being insincere...

re: the greeting, I think introverts around the world do not necessarily appreciate being randomly greeted by strangers, they just get used to it if the culture is like that. From that perspective, I don't think just a random greeting from a stranger always makes people feel more warm and the days more bearable either. It's more of a correlation rather than causation.

People have different personalities and different associations.

> Smiling at strangers is considered poor social form here and it doesn't matter if you're a foreigner or native.

It's not. Insincerity and mindless, automatic smiles might be a little bit frowned upon. Genuine, but subtle smiles (as appropriate for strangers) are appreciated, at least for the younger generation. The older generation might still be somewhat "traumatized" by the Soviet occupation and its cultural effects.