7 ms·

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

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.

monadic2 6y ago
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).
- entha_saava 6y ago
  > 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++.
  - monadic2 6y ago
    Well, rust is modularizing, so there will be opportunities for alternative backend (crane lift?).
deleuze 6y ago
The reason it's not a fair comparison is because go is a barely typed language that requires casting to interface non stop
- 65a 6y ago
  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.
  - deleuze 6y ago
    Right, building generic, reusable code is against the grain of the language.
- entha_saava 6y ago
  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.
atombender 6y ago
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 https://news.ycombinator.com/item?id=8817990 for the full explanation.

monadic2 6y ago

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).

entha_saava 6y ago
> 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++.
- monadic2 6y ago
  Well, rust is modularizing, so there will be opportunities for alternative backend (crane lift?).

deleuze 6y ago

The reason it's not a fair comparison is because go is a barely typed language that requires casting to interface non stop

65a 6y ago
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.
- deleuze 6y ago
  Right, building generic, reusable code is against the grain of the language.
entha_saava 6y ago
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.

atombender 6y ago

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 https://news.ycombinator.com/item?id=8817990 for the full explanation.