Doing stuff isn't free. For instance, Go compiles relatively quickly for a modern language, but the biggest reason for that is that it does less stuff than most compilers... less optimization, less checking, and some stuff built into the language to avoid some of the problems with having to read lots of headers just to compile a file and other ways of doing less stuff, but mostly the key is it does less stuff, in both the good and bad senses of that.
If you want something like Rust that offers guarantees and checks and cross-checks by the boatload, it adds up. Macros, monomorphization, implicit code generation with traits and all those other things add up too. And you can't always get O(n) or O(n log n) code to implement those checks. Maybe it can be sped up and maybe there's tricks here or there, but at the Pareto frontier, a language that has more checks will be slower to compile than one that has fewer.
And that's not a bad thing or a deficit in Rust, it's just the nature of the beast.
Instead of Go, you could have reached out to complex languages with fast compilation times like D, OCaml, Haskell, Ada, Delphi, C++.
All of them have alternative implementations with fast compilation times.
D, use dmd for fast development workflows, gdc or ldc for the ultimate performance at the expense of compilation times.
OCaml, use the REPL or bytecode interpreter for fast development times, the full blow compiler for ultimate performance.
Haskell, use the REPL, GHCi for the fast development cycles, GHC for the release build.
Ada and Delphi, have had fast implementations since forever, although Ada/SPARK is indeed somehow expensive.
C++, yes it isn't a mistake. Use Live++, VS hot reload, coupled with binary libraries, or a REPL like CINT (nee ROOT), binary libraries for dependencies, incremental compilation and incremental linking for the development workflow.
The problem with Rust isn't the language itself, rather the ecosystem currently lacking such kind of options being available.
Surac · · focus · HN ↗
What is the performance killer?
jerf · · focus · HN ↗
If you want something like Rust that offers guarantees and checks and cross-checks by the boatload, it adds up. Macros, monomorphization, implicit code generation with traits and all those other things add up too. And you can't always get O(n) or O(n log n) code to implement those checks. Maybe it can be sped up and maybe there's tricks here or there, but at the Pareto frontier, a language that has more checks will be slower to compile than one that has fewer.
And that's not a bad thing or a deficit in Rust, it's just the nature of the beast.
pjmlp · · focus · HN ↗
Instead of Go, you could have reached out to complex languages with fast compilation times like D, OCaml, Haskell, Ada, Delphi, C++.
All of them have alternative implementations with fast compilation times.
D, use dmd for fast development workflows, gdc or ldc for the ultimate performance at the expense of compilation times.
OCaml, use the REPL or bytecode interpreter for fast development times, the full blow compiler for ultimate performance.
Haskell, use the REPL, GHCi for the fast development cycles, GHC for the release build.
Ada and Delphi, have had fast implementations since forever, although Ada/SPARK is indeed somehow expensive.
C++, yes it isn't a mistake. Use Live++, VS hot reload, coupled with binary libraries, or a REPL like CINT (nee ROOT), binary libraries for dependencies, incremental compilation and incremental linking for the development workflow.
The problem with Rust isn't the language itself, rather the ecosystem currently lacking such kind of options being available.
[deleted] · · focus · HN ↗
[deleted]