21–30 of 62 posts
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.
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.
Over the years compile speed improved quite a bit (recently this: https://blog.rust-lang.org/2023/11/09/parallel-rustc.html made quite the difference) If we can squeeze more performance that's great but the largest concern I have around compilation is with the size of the target directory It can balloon up to node_modules levels
Earlier quoted context omitted.
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.
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.
For every generic function f, rustc will generate as many instances as there are type instances (shape instances? Does the Compiler distinguish between different kinds of references that all get compiled to pointers?).
This feature has a cost. Compare to OCaml's uniform object representation that enables comparatively blazing compilation performance but pays a prize in performance and weird FFI restrictions (integers with a tag bit).
Btw. It's misleading to say "it's the backend" when the frontend is responsible for creating so much work for it.
Monomorphization. For every generic function f, rustc will generate as many instances as there are type instances (shape instances? Does the Compiler distinguish between different kinds of references that all get compiled to pointers?). This feature has a cost. Compare to OCaml's uniform object representation that enables comparatively blazing compilation performance but pays a prize in performance and weird FFI rest…
Monomorphization. For every generic function f, rustc will generate as many instances as there are type instances (shape instances? Does the Compiler distinguish between different kinds of references that all get compiled to pointers?). This feature has a cost. Compare to OCaml's uniform object representation that enables comparatively blazing compilation performance but pays a prize in performance and weird FFI rest…
By using binary libraries, external templates for common type sets, incremental compilation and linking, and nowadays (at least for VC++ already) modules.
What Rust still lacks is having sound alternatives to LLVM, or someone supporting similar workflows in Rust.
Using OCaml as an example, it is great to have multiple backends in the box, plus an interpreter, and pick and choose during development workflows.
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.
Monomorphization. For every generic function f, rustc will generate as many instances as there are type instances (shape instances? Does the Compiler distinguish between different kinds of references that all get compiled to pointers?). This feature has a cost. Compare to OCaml's uniform object representation that enables comparatively blazing compilation performance but pays a prize in performance and weird FFI rest…
Earlier quoted context omitted.
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.
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.
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.
OCaml compiles just as fast without having to compromise on the type system.