>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.
>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.
reply