The voxel-style engines tend to feature a longer draw distance (due to it being cheaper to render, as you can easily use various hacks to eg. halve texture accesses far away).

For a detailed look into the rendering of Magic Carpet, start from Slide 8 of [2].

[1]: https://tcrf.net/Prerelease:Magic_Carpet_(DOS)#1993 [2]: https://web.archive.org/web/20180330004301/http://www.glennc...

With that, it's mostly byte-parallel (though data-dependent as I mentioned).

Even though decoding the lengths must be serial (since's there's no unambiguous way to differentiate a tag and data byte), it's still doable within the wider SIMD registers, so there's some theoretical efficiency gain to be had (depending on the shape of the data).

On a general note, the continuation bit and prefix byte forms are equivalent, you just broadcast the prefix byte and compare against an increasing vector to convert it to a mask. Yeah, there's probably more fiddly SIMD if there are multiple prefixes in the register, but doable (it's just not byte-parallel, you eg. unroll the serial decode loop 8 times or whatever your maximum output byte width is, and mask out).

Simplified:

  // Just maps a byte to its position in the register
  __m128i idx = _mm_setr_epi8(0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15);
  // Broadcast the prefix
  __m128i nn = _mm_set1_epi8((char)prefix_byte);
  // Get applicable locations: prefix_byte contains the length, if byte_pos < len, the corresponding byte will be set
  __m128i m = _mm_cmpgt_epi8(nn, idx);
  // If you *really* want a high-bit mask:
  m = _mm_and_si128(m, _mm_set1_epi8((char)0x80));

It might be slightly more instructions than some other serial VL (variable-length) integer codec choices, but overall I don't think it's more difficult.

The very efficient SIMD VL codecs tend to stripe (separate) the control and data bits, so they're in a different design space anyway.

Hopefully P2P WebTransport takes off soon... https://w3c.github.io/p2p-webtransport/

Logically, it's more the other way around - REPLs are in that sense a compensation for static types, since nothing forbids having a REPL and static types (see: eg. Julia. OCaml, Haskell, Scala etc. have REPLs too, but they are closed-world).

There's a fundamental trade-off though, with the open- vs closed-world assumption - if your types and (generic) methods are open world, then certain kinds of errors are just not analyzable. (this is a more general mathematical truth, also occurring in eg. description logics and the Semantic Web)

As you hinted, REPLs also don't work well for eg. large pipelines farmed out to clusters of machines, or anything that requires a high degree of static assurance, eg. control software - you either must statically analyze for all errors for it to even be legal, or the cost of having to "live fix" an error is much larger than preventing it in the first place (or just impractical for clusters).

Sure, a degree of live patching and experimenting is desirable (namedrop JPL as Lispers do), but that's a somewhat orthogonal concern.

A Lisp-style REPL combines introspection and live patching for both code and data. This can be achieved in many heterogenous ways besides a REPL, though. It's just not a nice, curated and holistic experience. But agents don't really care about that. LLMs don't get magic feelings. They can easily work around minor annoyances and a lack of ergonomics (assuming it doesn't burn context).

(Since LLMs tend to leave junk behind and slowly corrupt everything over time, a persistent image is also not necessarily a good thing. Reproducibility is also harder.)

The Unix philosophy "everything is a file" can ultimately also be viewed as image-based programming. [1] The system is the image.

As long as you have a way to address (via files, namespaced symbols, UUIDs, URLs, numbers etc.) the code, the execution state (ie. the stack frames) and memory (ie. the heap of objects), it has the same effect.

The problem with most software is that its internals are not addressable. I don't think one has to use eg. Lisp to fix that though. I do acknowledge that most static languages fail here.

[1]: "Unix, Plan 9 and the Lurking Smalltalk" https://www.humprog.org/~stephen/research/papers/kell19unix-...

And yeah, if Clojure had a better static safety story, it would actually rank high, since it's high-abstraction with metaprogramming capabilities, excellent runtime specifications, and has a good "garden path" ie. natural code is good code.

(As a devil's advocate though, REPLs can be replaced with gluing together scripts with ad-hoc state/caching via the file system, which LLMs seem to be pretty good at already...)

So as an addendum, introspectability is also important ie. allowing to discover the state and composition of the system at any moment - though that's partially a language (eg. reflection) and partially a tooling (eg. debuggers) issue.

Therefore the best language for agents is likely the one that, on one hand erases all irrelevant details (ie. raises the level of abstraction and does not force focusing on eg. memory management), and on the other hand encodes any domain-relevant details in the code (eg. using advanced type systems, annotations, contracts, spec-like tests eg. property-based).

Human readability is a separate concern and still relevant, but the two mentioned properties actually generally improve on that as well (at least for engineers persistent enough to scale the tower of abstraction).

Based on this, it seems Go is certainly not that "agent endgame" language. It has large amounts of boilerplate, a general lack of safety around concurrency features, a pretty middling static safety story overall with a generally underpowered type system.

I don't think the perfect language exists, yet, but just wildly imagining, it would probably be something like a cross between Scala, Elixir and Lean (or equivalents). Unfortunately none of those languages also have the large training corpus required to make them perform well in all agenting engineering situations (yet).

For any language comparison, one must separate the expressiveness of the language, which limits the long-term possibilities for agents, and the training corpus, which is what mostly gives it the current standing. I think we are still in the phase where the languages are separated by essentially random non-design factors such as the amount of training environments the frontier labs are willing to create for them.

Given that, the syntax does not matter all that much, as long as the base language itself is flexible enough - as a another wild idea, it's also possible that eg. Python could mostly swallow all these features through external tools (eg. the pre-existing type checkers or linters), and if the frontier labs bother to RL on those tools, that would also work (see also: Mojo).

> I began by noting that TS has literals and set theoretic types

Can you please quote me exactly the part of your original comment that implies that literal types are structural and have subtyping? Because that is what I said. If you did imply that, well, excuse me for helping you by clarifying then.

> aggressively trying to prove that TS is somehow "better" than Haskell

Sorry, what? Refer to the first line of this comment. Just saying that some type system features are extensions or harder to use in Haskell says nothing about the superiority of TS. This is completely your imagination.

Here's me criticizing TS 4 months ago: https://news.ycombinator.com/item?id=46501061

> I wasn't the one to bring Zod into a discussion of type systems...

Not sure why this is even relevant, but this was a direct reply to: "...language like TS, which is not type safe at runtime, and which will happily ingest an unexpected value, silently coerce it in all sorts of fun and wacky ways"

Zod (just a random library) is a direct counter-example to that. There may be better counter-examples. One just needs a proof of existence - it doesn't have to be good.

I then had to repeat that I am also talking about static types because of: "...exhaustive runtime schema for your zero-first non-empty integer array example...". TS can both enforce that as a type (which you never presented for Haskell) and as a value. (nominally typed solutions quickly run into ergonomic problems like phantom types not being composable across library boundaries - eg. refinement types, which are even safer by nature, are structural!)

In any case, I'd estimate 99% of people using TS don't encounter any type safety issues caused by the design of TS. Haskell has `unsafeCoerce` too, just a bit wordier than in TS.

If wanting to talk about real unsoundness, one would mention something like bivariance (see also: linked comment), but even then almost all of that is entirely irrelevant in most practical software engineering.

> (a) I don't understand literals and set theoretic types, despite this whole thread being in reply to a post where I give examples of them in TS; and (b) that I care which type system is "better".

Huh, what? Again, I'm thinking none of that. Again, you imply you know better what I'm thinking...

> Structural typing would be a gaping hole in Haskell's strict type safety

I mean, yeah, let me just repeat OCaml and Scala here, both also famously type safe languages... Why make an argument when there's two immediate counterexamples that were already mentioned?

> but I do note I seem to have the edge there

This pretty much sums up the difference in attitude, I'm not here to score internet points in an argument.

I just wanted to comment on why the world is not black and white and even technically flawed languages like TS have something to learn from.

Quake 1 had QuakeC: [1] https://en.wikipedia.org/wiki/QuakeC [2] Hello world in QuakeC - https://www.leonrische.me/pages/quakec_bytecode_hello_world....

Quake 2 moved to native binaries.

Quake 3 had a new VM that enabled compiling regular C using LCC: [1] https://fabiensanglard.net/quake3/qvm.php [2] Spec - https://www.icculus.org/~phaethon/q3mc/q3vm_specs.html

Does not seem like this:

> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

> Personally, I consider all of Go to be a mistake.

You also consider Scala and OCaml to be mistakes? Because all of what I've mentioned also works in a very similar way in Scala.

> an appeal to authority

No, I didn't appeal to authority. It's the opposite - it's statistics. Multiple experienced language designers don't add features later for nothing. For a similar process, see eg. closures getting added to every mainstream language.

> complete, exhaustive runtime schema

Again, I wasn't talking about runtime schemas, but types. I only mentioned runtime as a counterpoint to the false statement that TypeScript doesn't enforce this. Only reducing this to runtime checking is a fallacy, again.

> A little hypocritical, no?

No, they aren't comparable since I wasn't using the examples as supports for an argument of whether X is better than Y. Strawmen involve argumentation.

> read my comment... examples... that were already in my comment

I read it in detail, the problem is you didn't really read my comment in detail, which illustrated both the subtyping and structural typing aspects (albeit trivially, yes), which yours didn't.

> You're also fairly clearly using string literals to type input without properly parsing it

Okay then, the arrogance of this is pretty astounding... You seem to know what I'm doing better than I am!

To be clear, I'm not doing any of that. And I've written Haskell way before I wrote any TypeScript.

The Person/Wine example is a pointless strawman. That's not what structural typing is generally used for.

The entire comment is basically making up strawmans... I didn't give practical examples to save space, obviously, it was just to disambiguate what I meant.

TypeScript has several runtime-safe advanced validators based on its type system (most well-known being Zod), capable of enforcing types similar to what I provided.

To conclude, these type system features were added by multiple experienced language designers for a reason, to languages that already had functional ADTs, so going "huh but what are these even useful for?!" to me sounds a bit clueless (or argumentative), so I don't see a productive continuation to this discussion.

Because TypeScript has structural sub-typing, while standard Haskell (eg. `A | B | C`) has neither subtyping nor structural typing, which both are very useful features for safe "integration/glue" type of programs.

(String) literals form a fundamental part of the TS "row polymorphism" (record types) and eg. tuple union type implementation.

You can type a non-empty array that starts with zero...

    type Arr = [0, ...number[]];
    const a: Arr = [0, 1, 2, 3, 4]

The C# union does not store any discriminator. Just look at the implementation - it's a single `object?` field.

The discriminative part is handled by run-time type information, which is stored in the object itself, not the union - which is why the C# built-in implementation requires boxing.

Also, you can use the same class/record type ("discriminator") in several different unions - again, a feature which ADTs/sum-types/tagged unions in most functional languages do not have.

You can even store one single object (ie. identical by reference equality) in several different union values at the same time, theoretically, which in combination with mutability is... uhh, certainly not common functional/mathematical semantics.

In TS in particular, in combination with other features (mapped types), they are equivalent to row polymorphism + whatever Haskell/GHC features enable type families to specialize on constant literal arguments (or you can use atomic types, but that's not structural / open-world)... so pretty advanced.

This is valid TS/Python:

    type ABC = "A" |"B" | "C"
    type AB = "A" | "B"
    const x: AB = "A";
    const y: ABC = x;

https://arxiv.org/abs/2507.03516

Links to other talks/abstracts: https://functional-architecture.org/events/funarch-2025/

CGO_ENABLED=0 breaks nsswitch etc. and overall makes Go a poor ecosystem inhabitant. Only usable if you only care about your own system.