Most active commenters
  • frollogaston(9)
  • rednafi(5)
  • pjmlp(4)

←back to thread

Why is the Rust compiler so slow?

(sharnoff.io)
302 points Bogdanp | 28 comments | 26 Jun 25 19:29 UTC | HN request time: 0.632s | source | bottom
Show context
rednafi ◴[26 Jun 25 23:05 UTC] No.44392307[source]▶
I’m glad that Go went the other way around: compilation speed over optimization.

For the kind of work I do — writing servers, networking, and glue code — fast compilation is absolutely paramount. At the same time, I want some type safety, but not the overly obnoxious kind that won’t let me sloppily prototype. Also, the GC helps. So I’ll gladly pay the price. Not having to deal with sigil soup is another plus point.

I guess Google’s years of experience led to the conclusion that, for software development to scale, a simple type system, GC, and wicked fast compilation speed are more important than raw runtime throughput and semantic correctness. Given the amount of networking and large - scale infrastructure software written in Go, I think they absolutely nailed it.

But of course there are places where GC can’t be tolerated or correctness matters more than development speed. But I don’t work in that arena and am quite happy with the tradeoffs that Go made.

replies(9): >>44392470 #>>44392882 #>>44393976 #>>44394789 #>>44395314 #>>44395527 #>>44395624 #>>44398142 #>>44398420 #
1. mike_hearn ◴[27 Jun 25 08:06 UTC] No.44394789[source]▶
> fast compilation is absolutely paramount. At the same time, I want some type safety, but not the overly obnoxious kind that won’t let me sloppily prototype. Also, the GC helps

Well, that point in the design space was already occupied by Java which also has extremely fast builds. Go exists primarily because the designers wanted to make a new programming language, as far as I can tell. It has some nice implementation aspects but it picked up its users mostly from the Python/Ruby/JS world rather than C/C++/Java, which was the original target market they had in mind (i.e. Google servers). Scripting language users were in the market for a language that had a type system but not one that was too advanced, and which kept the scripting "feel" of very fast turnaround times. But not Java because that was old and unhip, and all the interesting intellectual space like writing libs/conf talks was camped on already.

replies(5): >>44395036 #>>44396542 #>>44396960 #>>44397814 #>>44398191 #
2. rsanheim ◴[27 Jun 25 08:46 UTC] No.44395036[source]▶
Java still had slow startup and warmup time circa 2005-2007, on the order of 1-3 seconds for hello world and quite a bit more for real apps. That is horrendous for anything CLI based.

And you left out classloader/classpath/JAR dependency hell, which was horrid circa late 90s/early 2000s...and I'm guessing was still a struggle when Go really started development. Especially at Google's scale.

Don't get me wrong, Java has come a long way and is a fine language and the JVM is fantastic. But the java of 2025 is not the same as mid-to-late 2000s.

replies(2): >>44396358 #>>44403007 #
3. mike_hearn ◴[27 Jun 25 12:42 UTC] No.44396358[source]▶
Maybe so, although I don't recall it being that bad.

But Go wasn't designed for CLI apps. It was designed for writing highly multi-threaded servers at Google, according to the designers, hence the focus on features like goroutines. And in that context startup time just doesn't matter. Startup time of servers at Google was (in that era) dominated by cluster scheduling, connecting to backends, loading reference data and so on. Nothing that a change in programming language would have fixed.

Google didn't use classloader based frameworks so that also wasn't relevant.

replies(1): >>44398337 #
4. loudmax ◴[27 Jun 25 13:10 UTC] No.44396542[source]▶
As a system administrator, I vastly prefer to deploy Go programs over Java programs. Go programs are typically distributed as a single executable file with no reliance on external libraries. I can usually run `./program -h` and it tells me about all the flags.

Java programs rely on the JVM, of which there are many variants. Run time options are often split into multiple XML files -- one file for logging, another to control the number of threads and so on. Checking for the running process using `ps | grep` yields some long line that wraps the terminal window, or doesn't fit neatly into columns shown in `htop` or `btop`.

These complaints are mostly about conventions and idioms, not the languages themselves. I appreciate that the Java ecosystem is extremely powerful and flexible. It is possible to compile Java programs into standalone binaries, though I rarely see these in practice. Containers can mitigate the messiness, and that helps, up until the point when you need to debug some weird runtime issue.

I wouldn't argue that people should stop programming in Java, as there are places where it really is the best choice. For example deep legacy codebases, or where you need the power of the JVM for dynamic runtime performance optimizations.

There are a lot of places where Go is the best choice (eg. simple network services, CLI utilities), and in those cases, please, please deploy simple Go programs. Most of the time, developers will reach for whatever language they're most comfortable with.

What I like most about Go is how convenient it is, by default. This makes a big difference.

5. k__ ◴[27 Jun 25 14:14 UTC] No.44396960[source]▶
"it picked up its users mostly from the Python/Ruby/JS world rather than C/C++/Java"

And with the increasing performance of Bun, it seems that Go is about to get a whooping by JS.

(Which isn't really true, as most of the Bun perf comes from Zig, but they are targeting JS Devs.)

replies(1): >>44397867 #
6. rednafi ◴[27 Jun 25 15:58 UTC] No.44397814[source]▶
Java absolutely does not fill in the niche that Go targeted. Even without OO theology, JVM applications are heavy and memory intensive. Plus the startup time of the VM alone is a show stopper for the type of work I do. Also yes, Java isn’t hip and you couldn’t pay me to write it anymore.
replies(1): >>44403011 #
7. rednafi ◴[27 Jun 25 16:04 UTC] No.44397867[source]▶
Runtimes like Bun, Deno, or type systems like TypeScript don’t change the fact it’s still JS underneath — a crappily designed language that should’ve never left throwable frontend code.

None of these runtimes make JS anywhere even close to single-threaded Go perf, let alone multithreaded (goroutine) perf.

replies(1): >>44398255 #
8. frollogaston ◴[27 Jun 25 16:37 UTC] No.44398191[source]▶
Golang having solid n:m greenthreading day 1 was its big deal. Java has had no good way to do IO-heavy multitasking, leading to all those async/promise frameworks that jack up your code. I cannot even read the Java code we have at work. Java recently got virtual threads, but even if that fixes the problem, it'll be a while before things change to that. Python had the same problem before asyncio. This isn't even a niche thing, your typical web backend needs cooperative multitasking.

I'm also not fond of any of the Golang syntax, especially not having exceptions. Or if you want explicit errors, fine, at least provide nice unwrap syntax like Rust does.

replies(2): >>44399022 #>>44399279 #
9. frollogaston ◴[27 Jun 25 16:45 UTC] No.44398255{3}[source]▶
JS is perfectly designed for what it does, frontend and non-CPU-intensive backend code. It's never going to reach singlethreaded Golang perf.
replies(1): >>44398983 #
10. frollogaston ◴[27 Jun 25 16:56 UTC] No.44398337{3}[source]▶
Golang is frequently used for CLIs, even if it wasn't designed for that exactly
replies(1): >>44399977 #
11. rednafi ◴[27 Jun 25 18:14 UTC] No.44398983{4}[source]▶
JavaScript was never designed for non-browser usage. It’s the community’s unquenchable thirst to use the same language everywhere that brought us here.
replies(1): >>44399087 #
12. aaronblohowiak ◴[27 Jun 25 18:20 UTC] No.44399022[source]▶
by FAR my biggest complaint about Golang was null instead of Option. could have been special cased like their slice and map and would have been so so so much better than nil checks imho. really, a big miss.
13. frollogaston ◴[27 Jun 25 18:29 UTC] No.44399087{5}[source]▶
NodeJS about page makes its case pretty succinctly, JS was a good fit for IO-bound concurrent backends because of the event loop. This was at a time when no other major language/runtime had a good answer for this unless you count Erlang. Plenty of people using it didn't even come from the web frontend side, myself included.

npm was also maybe the first default package manager that "just works," unlike Python or browser JS.

replies(1): >>44399889 #
14. cogman10 ◴[27 Jun 25 18:53 UTC] No.44399279[source]▶
Java 21 has n:m green threads, but with caveats. Java 24 removed a major source of the caveats.
replies(2): >>44400277 #>>44400464 #
15. AgentME ◴[27 Jun 25 20:18 UTC] No.44399889{6}[source]▶
A lot of people don't realize NodeJS was made because the creator wanted to make a runtime dedicated to asynchronous IO, didn't want to use a language with a pre-existing standard library and ecosystem built around synchronous IO, and realized that JS almost uniquely fit the bill. It was not built for the purpose of letting people who only knew JS use JS on the server.
replies(1): >>44400205 #
16. zenlot ◴[27 Jun 25 20:29 UTC] No.44399977{4}[source]▶
If you want to write CLI tool, you use Rust.
replies(2): >>44400159 #>>44400741 #
17. frollogaston ◴[27 Jun 25 20:56 UTC] No.44400159{5}[source]▶
Or you use Golang? A lot of the time there isn't a big difference.
18. frollogaston ◴[27 Jun 25 21:02 UTC] No.44400205{7}[source]▶
This tracks, cause the NodeJS website also doesn't mention anything about people already knowing JS. And imports worked completely differently between browser and Node, so they were pretty separate things at least at the start.
19. frollogaston ◴[27 Jun 25 21:11 UTC] No.44400277{3}[source]▶
Yeah, I'm hoping that fixes things eventually. We still can't use that at work, and even once we can, there's 10yo code still using 3 different old ways of async.
20. computably ◴[27 Jun 25 21:36 UTC] No.44400464{3}[source]▶
I'm sure you're already aware but for those who aren't - Java 21 was released in 2023. Golang 1.0 was released in 2012.
replies(1): >>44403029 #
21. rednafi ◴[27 Jun 25 22:11 UTC] No.44400741{5}[source]▶
Who said that? Go is pretty amazing to whip up great CLIs quickly.
replies(1): >>44400948 #
22. ◴[27 Jun 25 22:42 UTC] No.44400948{6}[source]▶
23. pjmlp ◴[28 Jun 25 08:04 UTC] No.44403007[source]▶
Not when using commercial JDKs, but naturally most HNers never worked on companies that paid for those.

For example initial JIT caching experiments on OpenJDK came from J/Rockit.

24. pjmlp ◴[28 Jun 25 08:05 UTC] No.44403011[source]▶
The old OOP testament was written by Smalltalk and C++ apostles, then the school of Objective-C belivers was found, and some of the scholars helped with the new Java religion.
25. pjmlp ◴[28 Jun 25 08:09 UTC] No.44403029{4}[source]▶
In 2012 we could do much of the same stuff with Java 5 concurrency framework and futures (aka promises everyone raves about on JS land), with the advance that scheduling can be customised.
replies(1): >>44405691 #
26. frollogaston ◴[28 Jun 25 16:02 UTC] No.44405691{5}[source]▶
That's what I meant by unreadable code. You have to twist everything to work with whatever async framework.
replies(1): >>44406651 #
27. pjmlp ◴[28 Jun 25 17:46 UTC] No.44406651{6}[source]▶
Have you ever had to write down channel sending dependencies graph?

I had to, to make sense of whatever was going on.

replies(1): >>44426393 #
28. frollogaston ◴[30 Jun 25 18:30 UTC] No.44426393{7}[source]▶
If this is an app backend, you aren't dealing with Golang channels directly. Your webserver or whatever it is spawns a new goroutine (greenthread) for each incoming request, then you use blocking calls without worrying. Looks similar in JS but the event loop handles it instead, and you async/await stuff. JS webpages and app frontends also don't worry about this.

If this is systems programming, yeah you're reasoning about channels, but that's mostly the same in any language. Golang has slightly nicer support for that if anything.