This is very interesting! Would love to see it in play in Wasmer at some point.
I was aware of TinyGo, which allows compiling Go programs via LLVM (and targeting Wasm, for example). They have a very tiny footprint (programs could even run on the browser) https://tinygo.org/
Given that Go can already be compiled to WebAssembly (with the ability to use TinyGo if you want to trade-off some language features for efficiency), is there anything that would make this more attractive than the alternatives? That it's written in Rust and can be used as a library by Rust code?
The Go-in-Go compiler was significantly slower than the Go-in-C compiler that it replaced, although most users didn't notice it because the new compiler contained many algorithmic improvements that were judiciously not backported to the old compiler in order to make the transition smoother. A compiler written in Rust could conceivably be faster than the current Go compiler.
If the Go compiler was twice as fast, I wouldn't really notice.
If the Go linker was twice as fast, that would be a minor convenience, sometimes.
I wouldn't expect much more that twice, maybe thrice at the very outside. And it'd be a long journey to get there with bugs and such to work through. The blow-your-socks-off improvements come from when you start with scripting languages. Go may be among the slower compiled languages, but it's still a compiled language with performance in the compiled-language class; there's not a factor of 10 or 20 sitting on the table.
But having another implementation could be useful on its own merits. I haven't heard much about gccgo lately, though the project [1] seems to be getting commits still. A highly-compatible Go compiler that also did a lot of compile-time optimizations, the sort of code that may be more fun and somewhat more safe to write in Rust (though I would perceive that the challenge of such code is for the optimizations themselves to be correct rather than the optimization process not crashing, and Rust's ability to help with that is marginal). The resulting compiler would be slower but might be able to create much faster executables.
The Go compiler is already ridiculously fast. As far as I know the garbage collector usually doesn't even activate for short-lived programs, which compilation usually is. Turning garbage collection off entirely doesn't have much of an impact on build times.
What significant opportunities exist for performance with a Rust implementation that aren't possible in Go?
The original port was slower because it was a near straight transpile impl of the original C compiler. It didn't do anything to try to speed things up, they went for correctness first. Then in subsequent releases they worked on speed improvements.
> A compiler written in Rust could conceivably be faster than the current Go compiler.
Is that really relevant, though? A compiler written in Rust is unlikely to be that much faster than a compiler written in Go. Most users might not notice a tiny difference in build times.
While Its a cool experiment. Is there some purpose I'm missing? Go can already do this natively and compilation speed is already its selling point so not sure how rust could help there.
Seems like effort would be better towards improving rust compilation speed. Unless you just wanted to create a compiler for learning or HN points which here ya go.
While interesting for the author, as learning exercise, the existing reference compiler is a much better proposition, being bootstraped and proving the point Go is usable for systems programming.
Unless writing compilers, linkers, assemblers, a GC runtime is no longer considered systems programming.
Readit News
I was aware of TinyGo, which allows compiling Go programs via LLVM (and targeting Wasm, for example). They have a very tiny footprint (programs could even run on the browser) https://tinygo.org/
But this approach is very interesting. I wonder how much compatible Goiaba is with Go vs TinyGo https://tinygo.org/docs/reference/lang-support/stdlib/
If the Go linker was twice as fast, that would be a minor convenience, sometimes.
I wouldn't expect much more that twice, maybe thrice at the very outside. And it'd be a long journey to get there with bugs and such to work through. The blow-your-socks-off improvements come from when you start with scripting languages. Go may be among the slower compiled languages, but it's still a compiled language with performance in the compiled-language class; there's not a factor of 10 or 20 sitting on the table.
But having another implementation could be useful on its own merits. I haven't heard much about gccgo lately, though the project [1] seems to be getting commits still. A highly-compatible Go compiler that also did a lot of compile-time optimizations, the sort of code that may be more fun and somewhat more safe to write in Rust (though I would perceive that the challenge of such code is for the optimizations themselves to be correct rather than the optimization process not crashing, and Rust's ability to help with that is marginal). The resulting compiler would be slower but might be able to create much faster executables.
[1]: https://github.com/golang/gofrontend
What significant opportunities exist for performance with a Rust implementation that aren't possible in Go?
Compilation speed is not something I worry about in Go, versus Rust, which I seldom bother with nowadays, compilation speed being one of the reasons.
Is that really relevant, though? A compiler written in Rust is unlikely to be that much faster than a compiler written in Go. Most users might not notice a tiny difference in build times.
https://github.com/golang/go/issues/73608
Sounds like they want to maybe include https://github.com/usbarmory/tamago in the compiler.
Seems like effort would be better towards improving rust compilation speed. Unless you just wanted to create a compiler for learning or HN points which here ya go.
Unless writing compilers, linkers, assemblers, a GC runtime is no longer considered systems programming.