Hacker News new | ask | show | jobs
by entha_saava 2160 days ago
I'd say Go is a fair comparison here.

Type checking and Parsing isn't bottleneck in Rust compilation. Code generation is. LLVM is particularly heavy and while it generates optimized code, it is quite slow.

Go Authors didn't pick LLVM because of compile speed reasons (as well as complexity), and that turned out to be worthwhile tradeoff.

3 comments

Well, worthwhile in terms of compile times, which makes sense knowing google’s codebase. Most people aren’t compiling massive dependency trees that can’t fit on any single computer when they push a commit.

Anyway in C++ land massive compile times are just as much of a problem. Fast code is expensive. Go’s a lot of things, but being good at generating fast code ain’t one of them (looking holistically anyway).

> Fast code is expensive.

Indeed, because all bigtech can invest on is LLVM and C++.

The research on compilers and optimizations has not been getting the attention because of LLVM monoculture and the monstrosity that is C++.

Well, rust is modularizing, so there will be opportunities for alternative backend (crane lift?).
Go's authors didn't pick LLVM because they weren't sufficiently familiar with it to implement what they needed (e.g. segmented stacks). See https://news.ycombinator.com/item?id=8817990 for the full explanation.
The reason it's not a fair comparison is because go is a barely typed language that requires casting to interface non stop
I told type system is not the bottleneck, codegen is.

Even if you count the size of ode after monomorphization, I am pretty sure the Go compiler compiles it much faster. Because the compiler is not in the benchmarks rat race of adding one optimization pass from every academic paper in the world for diminishing returns. That would be unnecessary for a development compiler.

Go compiler could have an optimized slow build option, in ideal world, but that's a different matter altogether.

If you're casting to interface{} non-stop, you are doing something against the grain of the language. It works, but there's probably a better way of getting the result you are looking for.
Right, building generic, reusable code is against the grain of the language.