back
14 comments
On index benchmark results:

>Still not quite as fast as Go, but it's close. Honestly, I don't know why the memchr-based implementation is still slower than Go's assembly here, but I decided not to pursue it any further.

Libc call overhead. Your version is using an already-fast memchr, but it still has to cross a general libc boundary and then do the pointer/index around it.

Index with a 1-byte needle collapses to IndexByte, and on arm64 that goes into Go asm.

Refreshing seeing someone coding without AI in 2026.
Interestingly enough, the initial Go implementation was indeed just a transpiler to C, and generally Go and C are semantically very similar. So the fact that you can even (successfully and relatively easily) do Go->C transpiling isn't entirely surprising. Of course you can't port `go` keyword and GC, but the language that the author is developing (called So) doesn't support these features anyway :).
Early Go was the first time I ever saw the Plan 9 compiler/linker used in action:

https://9p.io/sys/doc/compiler.html

I could be wrong, but I don't think the initial Go implementation was a C transpiler. It was written in C, but it did its own compilation.
Alef is the missing link between C and Go.
Nope, Limbo is the missing link, plus a bit of Oberon-2 on top.

Additionally Limbo also carries the lessons learnt out of Alef failure in Plan 9.

Limbo compiles to bytecode and comes with an os; it feels more like a branch than a link.
With a JIT compiler, and actually shipped, unlike Alef which was aborted and they pivoted back to C.
Sure, but that makes my point for me.
Nope, because it is

    C => Alef (abandoned) => Limbo => Go
                                       ^
                   Oberon => Oberon-2 /
Anyone schooled in compilers and language design knows how to differentiate language, semantics and implementations.
No transpilation was taking place, they replaced the frontend to understand Go.