5 ms·

One reason for me moving from Rust to Go was compilation speed. Go is a simpler language, so apples to oranges, but Go compiles so fast, which to me makes devel

One reason for me moving from Rust to Go was compilation speed. Go is a simpler language, so apples to oranges, but Go compiles so fast, which to me makes development very different.

makapuf 3y ago
That is definitely true, but from the article it's the backend that takes time, not the frontend where the language itself resides. If you compile go from llvm, it maybe as long as rust.
- KingOfCoders 3y ago
  I wonder why we do not split up compilation more - especially for web developer. Rust does this a little with "check", C with "-O". I want fast compilation for my dev cycle or for unit tests, I want slow compilation with optimizations, escape analysis, correctness etc. for production (the distinction between a compiler and linter is also not clear, some compiles do what linters do in other languages).
  - jokethrowaway 3y ago
    We do, you have profile configuration for dev or for release You can get pretty big differences in terms of compile speed / binary size
  - IshKebab 3y ago
    Giving up entirely on the compile time of "performance" builds can be bad too though, e.g. for people writing games, audio software, etc.
    - bluGill 3y ago
      Only if you need to test the full game. If you can unit test algorithms and learn something then fast builds matter.
- GrumpySloth 3y ago
  It’s not just Rust. Practically every compiler based on LLVM is slow. Swift, Zig, Clang. The Go compiler being written from scratch based on the Plan9 C compiler is a huge advantage.
  - txdv 3y ago
    Zig is moving away from LLVM. Its already has its own backend targeting debug builds for x86 and arm. ReleaseFast and ReleaseSmall is an entire different beast, but its going to be tackled eventually.
  - rvdca 3y ago
    I will chime in to day that rust is also building a alternative to the LLVM backend in the form of cranelift : https://github.com/rust-lang/rustc_codegen_cranelift https://github.com/rust-lang/rustc_codegen_cranelift
  - kjksf 3y ago
    Minor correction: Go compiler used to be a modification of Plan9 C compiler, then a Go port of that modification but then it was completely rewritten as a SSA-based compiler so today it has almost nothing to do with the original Plan9 code.
anonyfox 3y ago
second that. also another point: I write most Go code using only the stdlib, so there is no dependency web to take care on top of the actual code.
- KingOfCoders 3y ago
  I also have much less dependencies with Go compared to other languages, especially in TS.
pjmlp 3y ago
OCaml compiles just as fast without having to compromise on the type system.
- kjksf 3y ago
  But then you have to compromise on speed of generated code, poor support of windows, number of libraries and overall ecosystem, no ability to generate standalone executables and probably more but I tried OCaml only briefly so can't speak to all of its shortcomings.
  - pjmlp 3y ago
    OCaml optimizations are certainly better than Go compiler that hardly does inlining and only recently got some PGO support, and those that care about using LLVM or GCC backends have to compromise on fronteds that still don't do generics. Go support on Windows is also not great, plugin package doesn't work, filesystem support assumes POSIX semantics, cgo requires installing mingw.
    - sigsev_251 3y ago
      > using LLVM backends Wait, there is an LLVM based Go toolchain? I thought the Go crowd was known for their NIH obsession.
      - pjmlp 3y ago
        TinyGo.
- KingOfCoders 3y ago
  Some see it as a compromising on types, I don't. After some years writing Scala code, trying to come up with even better types each day, Go to me is not a compromise but a relief. My love for types peaked when I was in my mid-40s, now that I'm 50+ I want simple things.
  - 3y ago

One reason for me moving from Rust to Go was compilation speed. Go is a simpler language, so apples to oranges, but Go compiles so fast, which to me makes development very different.

makapuf 3y ago

That is definitely true, but from the article it's the backend that takes time, not the frontend where the language itself resides. If you compile go from llvm, it maybe as long as rust.

KingOfCoders 3y ago
I wonder why we do not split up compilation more - especially for web developer. Rust does this a little with "check", C with "-O". I want fast compilation for my dev cycle or for unit tests, I want slow compilation with optimizations, escape analysis, correctness etc. for production (the distinction between a compiler and linter is also not clear, some compiles do what linters do in other languages).
- jokethrowaway 3y ago
  We do, you have profile configuration for dev or for release You can get pretty big differences in terms of compile speed / binary size
- IshKebab 3y ago
  Giving up entirely on the compile time of "performance" builds can be bad too though, e.g. for people writing games, audio software, etc.
  - bluGill 3y ago
    Only if you need to test the full game. If you can unit test algorithms and learn something then fast builds matter.
GrumpySloth 3y ago
It’s not just Rust. Practically every compiler based on LLVM is slow. Swift, Zig, Clang. The Go compiler being written from scratch based on the Plan9 C compiler is a huge advantage.
- txdv 3y ago
  Zig is moving away from LLVM. Its already has its own backend targeting debug builds for x86 and arm. ReleaseFast and ReleaseSmall is an entire different beast, but its going to be tackled eventually.
- rvdca 3y ago
  I will chime in to day that rust is also building a alternative to the LLVM backend in the form of cranelift : https://github.com/rust-lang/rustc_codegen_cranelift https://github.com/rust-lang/rustc_codegen_cranelift
- kjksf 3y ago
  Minor correction: Go compiler used to be a modification of Plan9 C compiler, then a Go port of that modification but then it was completely rewritten as a SSA-based compiler so today it has almost nothing to do with the original Plan9 code.

anonyfox 3y ago

second that. also another point: I write most Go code using only the stdlib, so there is no dependency web to take care on top of the actual code.

KingOfCoders 3y ago
I also have much less dependencies with Go compared to other languages, especially in TS.

pjmlp 3y ago

OCaml compiles just as fast without having to compromise on the type system.

kjksf 3y ago
But then you have to compromise on speed of generated code, poor support of windows, number of libraries and overall ecosystem, no ability to generate standalone executables and probably more but I tried OCaml only briefly so can't speak to all of its shortcomings.
- pjmlp 3y ago
  OCaml optimizations are certainly better than Go compiler that hardly does inlining and only recently got some PGO support, and those that care about using LLVM or GCC backends have to compromise on fronteds that still don't do generics. Go support on Windows is also not great, plugin package doesn't work, filesystem support assumes POSIX semantics, cgo requires installing mingw.
  - sigsev_251 3y ago
    > using LLVM backends Wait, there is an LLVM based Go toolchain? I thought the Go crowd was known for their NIH obsession.
    - pjmlp 3y ago
      TinyGo.
KingOfCoders 3y ago
Some see it as a compromising on types, I don't. After some years writing Scala code, trying to come up with even better types each day, Go to me is not a compromise but a relief. My love for types peaked when I was in my mid-40s, now that I'm 50+ I want simple things.
- 3y ago