3 ms·
Go is known by the speed of it's compiler, doing extra work during the compilation would slow it down. I would not mind either to have a "release" flag that wou
by diegobernardes 2y ago
Go is known by the speed of it's compiler, doing extra work during the compilation would slow it down. I would not mind either to have a "release" flag that would take minutes and produce a more optimized binary.
- pjmlp 2y agoIn theory that is what gccgo is for, in practice it is stuck in Go 1.18.
- nasretdinov 2y agotinygo also tries really hard to produce an optimised binary, however it mostly optimises for size, not speed.
- eliben 2y agoIn a way, that's what the PGO mode of the compiler is
- KingOfCoders 2y agoYes this, I mainly use Go for it's simplicity and the speed of the compiler. What I don't want is Rust compile speeds.
- pjmlp 2y agoAs proven by D, OCaml, F#, Delphi, Ada, C++23 (with modules, VC++/clang 18), it is a matter of toolchain. What we need is a Rust interpreter, or having something like Cranelift properly integrated, to only depend on LLVM when doing release builds on the CI/CD.
- KingOfCoders 2y agoHaving used Scala for some years with it's abysmal compile speed, I fear it has to do with complexity of the language and features, it was "implicit" in Scala, it might be the borrow checker in Rust (IANACG)
- pjmlp 2y agoNote that I left out Scala, while I included other languages of similar complexity, exactly because improving compile times has never been a major focus in Scala land, versus features. Example, development effort wasted on Scala 3 Python like syntax. There are several performance reports that show that the major culprit is the pile of LLVM IR sent to the backend.
- steveklabnik 2y agoIf you examine what takes time in the Rust compiler, the borrow checker is never a significant component. The largest single bit tends to be codegen, which is why cargo check is so much faster than cargo build.
- KingOfCoders 2y agoAh!