[HN Gopher] Goiaba: An experimental Go compiler, written in Rust
___________________________________________________________________
Goiaba: An experimental Go compiler, written in Rust
Author : SchwKatze
Score : 59 points
Date : 2025-10-09 16:15 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| schoen wrote:
| (It's Portuguese for "guava".)
| mariusseufzer wrote:
| man i love this fruit
| swah wrote:
| I hate it but starts with Go so great choice...
| tbrockman wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| > 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?
| pjmlp wrote:
| This sample code took 12 minutes on a clean build on my
| travel netbook, now dead.
|
| https://github.com/pjmlp/gwc-rs
|
| Maybe nowadays it is faster, I have not bothered since I
| made the RIR exercise.
|
| Get the community editions of Delphi, FreePascal, or D
| and see what a fast build means.
|
| Better yet, take the lastest version of Turbo Pascal for
| MS-DOS, meaning 7, and try it out on FreeDOS.
| littlestymaar wrote:
| > This sample code took 12 minutes on a clean build on my
| travel netbook, now dead.
|
| Clean builds are slow indeed. But they are also once
| every six week at most if switch to the latest compiler
| at every release.
|
| > Get the community editions of Delphi, FreePascal, or D
| and see what a fast build means.
|
| Honestly, who cares about the difference between 1s vs
| 100ms vs 10ms for a build though? Rust compilation isn't
| optimal by any means, and it wouldn't have been workable
| at all in the 90s, but computers are so fast today (even
| 13-years old computers) it rarely matters in practice
| IMHO.
| alain_gilbert wrote:
| > Honestly, who cares about the difference between 1s vs
| 100ms vs 10ms for a build though?
|
| I definitely do. Not necessarily because of the 10ms vs
| 1s. But because of the later stage when it becomes 600ms
| vs 60s.
| littlestymaar wrote:
| > But because of the later stage when it becomes 600ms vs
| 60s.
|
| What later stage though, as I said I worked with big code
| bases on old hardware without issues.
|
| I'm simply not convinced that there exist a situation
| where incremental rebuild of the crate you're working on
| is going to take 60s, at all, especially if you're using
| hardware from this decade.
| alain_gilbert wrote:
| I have a fairly small go project (100k loc) and it takes
| ~30sec to build.
|
| I'd be thrilled to have it build in 300ms.
|
| (Using a macbook pro 2019)
| nicoburns wrote:
| Consider upgrading your hardware if/when you get a chance
| to (obviously this is expensive). My builds (Rust not Go,
| but it might well be similar?) got 10x faster when I
| upgraded from a 2015 MBP to an M1. I suspect 2019 to M4
| might be similar.
| merely-unlikely wrote:
| I must be doing something wrong because incremental
| builds regularly take 30-60 seconds for me. Much more if
| I add a dependency. And I try to keep my crates small.
| balamatom wrote:
| PSA: try https://github.com/rui314/mold
|
| (Not affiliated with the project. Just switched to it and
| never looked back.)
| veber-alex wrote:
| > This sample code took 12 minutes on a clean build on my
| travel netbook, now dead.
|
| > Maybe nowadays it is faster, I have not bothered since
| I made the RIR exercise.
|
| Took me 18 seconds on a M4 Pro.
|
| Please stop spreading FUD about Rust. Compile times are
| much better now then what they were and are constantly
| improving. Maybe it will never be as fast as one of those
| old languages that you like that nobody uses anymore but
| it's plenty usable.
| bakul wrote:
| The default serial build of V (tcc backend) takes 0.6
| (with production compiler) to 1.3 seconds (with tcc
| backend compiler).
|
| The _production_ (clang backend) parallel build of V
| language takes about 3.2 seconds. All on an m1 mac. Even
| the go compiler seems slow in comparison.
| merely-unlikely wrote:
| It's still my number one complaint about Rust, even
| though it has definitely gotten better over time. Partly
| my fault - I'm stuck on a slightly underpowered Windows
| machine at work. My Macs at home compile significantly
| faster. But as soon as I add certain crates like serde,
| tokio, windows, and some others, the compile times grow
| quickly. It also means that tasks Rust isn't necessarily
| designed for but can be used for (like web backends)
| become frustrating enough to dissuade me from using it as
| a do-it-all language despite certain aspects of the
| language being really nice. Even a 30-45 second tweak-
| test loop becomes annoying after a while. Again more of a
| personal problem than anything, but the point is I
| personally am constantly frustrated with the compile
| times.
| jerf wrote:
| 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
| kyrra wrote:
| 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
|
| Sounds like they want to maybe include
| https://github.com/usbarmory/tamago in the compiler.
| syrusakbary wrote:
| 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/
|
| 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/
| dkga wrote:
| Love the name!
| citizenpaul wrote:
| 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.
| pjmlp wrote:
| 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.
___________________________________________________________________
(page generated 2025-10-09 23:00 UTC)