>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.
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 :).
Limbo was also abandoned, and go doesn't include most of its innovations. Hence why I explicitly said alef and not limbo.
> Anyone schooled in compilers and language design knows how to differentiate language, semantics and implementations.
I'm not sure what your point is. not one of these languages have semantic innovation—I suppose you could argue the `go` keyword is, but even that feels facetious.
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
Anyone schooled in compilers and language design knows how to differentiate language, semantics and implementations.Limbo was also abandoned, and go doesn't include most of its innovations. Hence why I explicitly said alef and not limbo.
> Anyone schooled in compilers and language design knows how to differentiate language, semantics and implementations.
I'm not sure what your point is. not one of these languages have semantic innovation—I suppose you could argue the `go` keyword is, but even that feels facetious.
No it wasn't, the software reached production deployment to several customers from AT&T, and Vita Nuova.
Alef never saw the light of the day outside some programmer offices.
No transpilation was taking place, they replaced the frontend to understand Go.