5 ms·

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 a

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?

kibwen 1y ago
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.
- kyrra 1y ago
  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.
- xyzzy_plugh 1y ago
  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?
- pjmlp 1y ago
  Yes, and with time improvements were made. 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.
  - littlestymaar 1y ago
    It really puzzles me that people complain about compilation speed in Rust these days: I've worked on pretty big Rust code bases with lots of dependencies also, and cargo check has always been pretty much instant for me, including when I'm traveling and I use my mid-range laptop from 2012! (my main desktop is from 2018, I bought it because my previous desktop, from 2009 struggled to compile servo, mostly due to having too little RAM). Debug build take a bit longer (a few seconds) on the desktop, while still staying below a minute on the laptop (remember, I'm talking about a 12 years old Clevo laptop, not a recent Macbook). It's definitely not worse than Typescript compilation or even Javascript bundling, yet we pretty much never hear complains about how typescript has too big compile times. Yes, it could be faster with a different compiler architecture, especially on clean release builds and that would be nice, but it's a very minor annoyance (I don't do a full release build unless I've updated my compiler version, which only happens a few times a year). The contrast between the discourse and my day-to-day experience on near obsolete hardware is very striking. (Compilation artifact eating up hundreds of GB of my hard drive are a much, much bigger nuisance in practice, yet nobody seem to talk about that here on HN).
    - nicoburns 1y ago
      > I don't do a full release build unless I've updated my compiler version, which only happens a few times a year That's probably part of the difference. I do tens of these every single day. GUI apps can be quite slow in debug mode, and as you say, the compilation artifacts build up quickly, which requires a cargo clean and then a fresh build.
      - littlestymaar 1y ago
        > I do tens of these every single day. Tens of clean builds? I'm very curious: why? (because obviously that puts you in a completely different situation compared to someone who can rely on incremental builds) > GUI apps can be quite slow in debug mode Full debug mode, definitely, but in that case I've always found that building the dependencies in release mode was enough, but YMMV. But then that's what incremental rebuild are about. > and as you say, the compilation artifacts build up quickly, which requires a cargo clean and then a fresh build. I've mostly experienced the PITA when working with multiple code bases over time or in parallel, but surely it doesn't happen every day, let alone multiple times per day, does it?
- jerf 1y ago
  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. [1]: https://github.com/golang/gofrontend https://github.com/golang/gofrontend
- lelanthran 1y ago
  > 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.
kyrra 1y ago
Semi related: there is an active proposal of having a go OS Target of "none" (or noos (No-OS)). https://github.com/golang/go/issues/73608 https://github.com/golang/go/issues/73608 Sounds like they want to maybe include https://github.com/usbarmory/tamago https://github.com/usbarmory/tamago in the compiler.

kibwen 1y ago

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.

kyrra 1y ago
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.
xyzzy_plugh 1y ago
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?
pjmlp 1y ago
Yes, and with time improvements were made. 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.
- littlestymaar 1y ago
  It really puzzles me that people complain about compilation speed in Rust these days: I've worked on pretty big Rust code bases with lots of dependencies also, and cargo check has always been pretty much instant for me, including when I'm traveling and I use my mid-range laptop from 2012! (my main desktop is from 2018, I bought it because my previous desktop, from 2009 struggled to compile servo, mostly due to having too little RAM). Debug build take a bit longer (a few seconds) on the desktop, while still staying below a minute on the laptop (remember, I'm talking about a 12 years old Clevo laptop, not a recent Macbook). It's definitely not worse than Typescript compilation or even Javascript bundling, yet we pretty much never hear complains about how typescript has too big compile times. Yes, it could be faster with a different compiler architecture, especially on clean release builds and that would be nice, but it's a very minor annoyance (I don't do a full release build unless I've updated my compiler version, which only happens a few times a year). The contrast between the discourse and my day-to-day experience on near obsolete hardware is very striking. (Compilation artifact eating up hundreds of GB of my hard drive are a much, much bigger nuisance in practice, yet nobody seem to talk about that here on HN).
  - nicoburns 1y ago
    > I don't do a full release build unless I've updated my compiler version, which only happens a few times a year That's probably part of the difference. I do tens of these every single day. GUI apps can be quite slow in debug mode, and as you say, the compilation artifacts build up quickly, which requires a cargo clean and then a fresh build.
    - littlestymaar 1y ago
      > I do tens of these every single day. Tens of clean builds? I'm very curious: why? (because obviously that puts you in a completely different situation compared to someone who can rely on incremental builds) > GUI apps can be quite slow in debug mode Full debug mode, definitely, but in that case I've always found that building the dependencies in release mode was enough, but YMMV. But then that's what incremental rebuild are about. > and as you say, the compilation artifacts build up quickly, which requires a cargo clean and then a fresh build. I've mostly experienced the PITA when working with multiple code bases over time or in parallel, but surely it doesn't happen every day, let alone multiple times per day, does it?
jerf 1y ago
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. [1]: https://github.com/golang/gofrontend https://github.com/golang/gofrontend
lelanthran 1y ago
> 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.

kyrra 1y ago

Semi related: there is an active proposal of having a go OS Target of "none" (or noos (No-OS)). https://github.com/golang/go/issues/73608 https://github.com/golang/go/issues/73608 Sounds like they want to maybe include https://github.com/usbarmory/tamago https://github.com/usbarmory/tamago in the compiler.