21–30 of 69 posts
This is sort of off topic, but the fact that every change to the source requires (on my machine) 3-4 full seconds to recompile, without optimization, is indicative of the compiler performance problems that remain my main roadblock with Rust.
This is sort of off topic, but the fact that every change to the source requires (on my machine) 3-4 full seconds to recompile, without optimization, is indicative of the compiler performance problems that remain my main roadblock with Rust.
It is in the top 3 issues with Scala as well. The amount of drag it causes in a project just isn't worth it.
This is sort of off topic, but the fact that every change to the source requires (on my machine) 3-4 full seconds to recompile, without optimization, is indicative of the compiler performance problems that remain my main roadblock with Rust.
It is in the top 3 issues with Scala as well. The amount of drag it causes in a project just isn't worth it.
Earlier quoted context omitted.
> They also didn't have the zero-cost memory safety abstractions that Rust has. No, but it is was better than what C and C++ have. > Nor did they do much optimization. I don't use them since the late 90's, but they used to be comparable to contemporary C and C++ MS-DOS/Windows compilers.
> I don't use them since the late 90's, but they used to be comparable to contemporary C and C++ MS-DOS/Windows compilers. There has been an enormous difference in the quality of optimization and code generation since the 1990s, when single-pass compilers such as Turbo Pascal and Delphi were common. At that time you usually went straight from AST to machine code, doing some peephole optimizations along the way, but t…
What I was trying to say, it that if you put a C or C++ compiler against Turbo Pascal or Delphi compiler of the same age, the latter will compile way faster and generate similar code in terms of quality.
If they had received the same investment as C and C++ had become since those days, the situation would still hold.
But history took another path, so it is kind of moot point now.
Earlier quoted context omitted.
They also didn't have the zero-cost memory safety abstractions that Rust has. Nor did they do much optimization. That said, we're working on compilation speed. The focus so far has been getting the language in shape and runtime performance of the generated code, not compilation speed (although we've picked most of the low-hanging fruit in compilation speed anyway).
How optimistic are you that the compilation speed can be significantly increased? Are there a lot of easy optimizations available or is this just the price paid for extra compile time safety? I'm not really a fan of Go but waiting for the compiler can be a pretty significant productivity killer on larger projects. Their fast compilation times are a pretty big selling point for what is (IMO) an otherwise underwhelming…
Generally I think many people complain too much for what takes a few seconds.
C++ builds are measured in hours, usually require distributed build systems, clever use of forward declarations and cutting class private declarations into static code or PImpl classes to bring it down to something manageable.
This is sort of off topic, but the fact that every change to the source requires (on my machine) 3-4 full seconds to recompile, without optimization, is indicative of the compiler performance problems that remain my main roadblock with Rust.
Have you profiled the build? Is most of it spent in the compiler? A more practical point is that the main competitor is C++, a language notorious for long compilation times, so not-ultra-fast compile times might not be the highest priority for people working on rustc.
$ wc test1
279506 897765 10174700 test1
Earlier quoted context omitted.
Have you profiled the build? Is most of it spent in the compiler? A more practical point is that the main competitor is C++, a language notorious for long compilation times, so not-ultra-fast compile times might not be the highest priority for people working on rustc.
C++ compilers are very fast (I would say amazingly fast) unfortunately atrocious header only implementations like Boost drags it down. I just did clang++ -E on a single #include of cpp-netlib which depends on Boost asio and the dumped output came to: $ wc test1 279506 897765 10174700 test1 And this is after enabling dynamic linking which cuts down a few thousand lines. Library writers are not giving compiler writers…
"Doom I/II written in Rust" is a fine title for what this is.
Earlier quoted context omitted.
It is in the top 3 issues with Scala as well. The amount of drag it causes in a project just isn't worth it.
The Rust compiler is much faster than Scala's compiler, from everything I have heard.