Hacker News Reader

Comment by Crinus | Hacker News Reader

While i appreciate the type safety that Rust may provide (even if it is overblown and only just a little, it can still be useful - e.g. while i prefer C, i do like C++'s "enum class"), my two main issues are that it is only a single implementation (and that implementation looks is too Unix-y with the Windows versions looking bolted at the side) and -especially- too slow.

I get annoyed when my C builds take more than a few seconds and a major reason i avoid C++ for my own stuff (C++'s complexity is another reason) and i hear that Rust has worse compile times than C++. This is enough for me to stay away from it.

But if Rust manages to get an implementation that feels at home at Windows with a full IDE and debugger and also gets around C-like compilation speeds, then i'd like to check it out.

View on HN

> and also gets around C-like compilation speeds

Isn't that possibly asking for a bit much? The Rust compiler is doing significantly more than a C compiler, so why would be expect it to have C-like speeds? Should we not also expect C to have compile speed improvements in that period, which might leave them relatively unchanged with respect to each other?

It feels sort of like you're comparing a Mercedes sedan and Land Rover. Both very capably vehicles, but targeted to excel in slightly different circumstances, and when people suggest a Land Rover for rougher terrain, you're noting that when they can provide the same acceleration and gas mileage as the sedan then you'll be interested, which is both unlikely to happen and missing the point, since an off-road vehicle can do things a sedan just can't. Preferring one over the other is fine, expecting one to be superior to the other in every way is a tall order.

That keeps getting brought up as reason for Rust compiler slowness, e.g. complex language requires long compile times.

So then lets pick D, Delphi, .NET Native, Eiffel, Ada as examples of toolchains from complex languages that compile faster than rustc is currently capable of.

> complex language requires long compile times.

My point is not so much that the language is complex, but that the compiler does a lot more stuff along the lines of correctness checking. If you take a C or C++ compiler and add in the equivalent level of checks that Rust is doing, can we expect it to be faster than the Rust compiler?

Are any of the other examples you're putting forth doing things of the same complexity? I know many of them have their own ways of providing assurances, but I know some of them are not compile-time (or at least not more than inserting instructions for run-time checks). You would know better than me, since you've expressed previously that you have experience with many of those, at least at a cursory level. Can you comment on what they're doing at a compile time level that's approaching or surpassing the complexity of the borrow checking in Rust?

Regarding C++ compilation, here is the latest blog entries regarding Visual C++ compilation speedups,

https://devblogs.microsoft.com/cppblog/improved-linker-funda...

https://devblogs.microsoft.com/cppblog/msvc-backend-updates-...

Another ways of improving compilation times:

D has fast compiler as reference implementation, leaving the hard work for gcc and llvm backends.

Eiffel uses a JIT for development, with AOT compilation via the C or C++ system compiler for production releases.

.NET Native, which now also supports F# (so H-N comes into play) takes advantage of MSIL, the development builds are a bit lightweight in optimizations and only the deployment via the store does the heavy crunching of optimizations, based on Visual C++ backend.

None of which do anywhere near the level of optimization that LLVM does. They also don't do H-M type inference or borrow checking.

FWIW i do not care that much about having LLVM's optimizations. As long as there are a few decent optimizations to do most of the stupid stuff i'm fine - i can do the rest myself whenever (and if) needed. It is only a very tiny part of the codebase that would need heavy optimizations anyway, yet having to pay (in terms of compilation time) for that for the entire codebase is an absurdity that we just seem to got used to.

So you have measured ldc, F# .NET Native, Delphi LLVM backend, Eiffel compilation via clang?

I don't understand what your point is. I think you're trying to imply something like "rustc is fundamentally misdesigned and it would be easy to make huge performance improvements", but there really is not much low-hanging fruit left in rustc. The fact is that H-M type inference, borrow checking, and optimization take time. There is no magic bullet that other languages do to compile quickly that Rust does not, other than not having Rust's features or not doing optimization. There's even an entirely separate compiler implementation now, mrustc, which as far as I know is not significantly faster than rustc.

There was a time when rustc could be called a relatively slow compiler for what it does, but not anymore. It's actually a reasonably fast compiler now. I expect small wins to continue in the future, but the only remaining foreseeable large win is Cranelift.

I didn't say it is easy, just that there is still room for improvement.

So here go my couch coach ideas.

You already mentioned one possible improvement, I don't need to compile with all optimizations turned on on debug builds.

Secondly, combine JIT for development with AOT compilation for release deployment, e.g. Eiffel / .NET Native.

Thirdly, make use of a build cache across crates, including third party dependencies instead of building the whole world from scratch.

Combine that with an incremental compiler/linker, like Visual C++ does, where the team use Unreal, CryEngine, Windows, Office and other similar sized projects to measure build improvements.

Optimizations are not turned on for debug builds and never have been. The issue is that LLVM is still pretty heavyweight even when not optimizing. An entirely separate backend is needed.

As Steve mentioned, there is a global build cache already.

We have an incremental compiler. It's not as incremental as it could be, however.

We already have an extensive system, crater, that can measure build time improvements.

> Thirdly, make use of a build cache across crates, including third party dependencies instead of building the whole world from scratch.

This already exists and is easy to use: https://github.com/mozilla/sccache

Thanks for the heads up.

I agree with your overall point, but

> but the only remaining foreseeable large win is Cranelift.

I'm not so sure about that, given the huge work going on to make rustc truly incremental.

And incremental compilation is more than virtually all the listed compilers can do.

I think the issue is more that not many people are using those languages in anger (except for Delphi I suppose, but Object Pascal is a comparatively simple language with no H-M inference that also does very little optimization). People don't hit the limitations.

> Isn't that possibly asking for a bit much? The Rust compiler is doing significantly more than a C compiler, so why would be expect it to have C-like speeds?

I do not expect it, i'd just want it to be fast for me to want to use it. I mean, i do not really care why it is slow (outside of curiosity, but not as an for accepting it), i care that it is slow.

> I get annoyed when my C builds take more than a few seconds and a major reason i avoid C++ for my own stuff (C++'s complexity is another reason) and i hear that Rust has worse compile times than C++. This is enough for me to stay away from it.

One of the main reason we stopped using C++ is because Rust compiles much faster than clang. That was 3 years ago, and in this time frame Rust has improved compile-times significantly (e.g. reductions of ~30% per year).

If you use similar feature sets rust compiles significantly slower.

With C++ I don't need to compile 3rd party dependencies from scratch.

For what it's worth, Rust will soon improve its linking stage by switching to ldd, as part of upgrading to LLVM 4.0. From what I've read ldd can dramatically reduce the time needed.

You probably mean 9.0.0, 4 is several years old. Or is Rust really still using something pre-4?

No, we run very close to the latest release; we also have our own patches that we try to upstream.

We do support back a little bit, to help distros.

My bad, I guess I was confused earlier about something else.

Rust has some of the best Windows support, in my experience. It uses native ABIs and object/debuginfo formats (not MinGW), and I debug it from Visual Studio.

It does well on Windows, but I still look forward to VS mixed mode debugging like .NET/Java and C++ IDEs are capable of, and being as productive as C++/WinRT to write COM/UWP components.

VS mixed mode debugging doesn't need language support. You can already call back and forth between Rust and C# and the debugger will handle it fine.

On the other hand, I think user time is more valuable than developer time and when building complex/efficient software expecting lightning builds isn't just unwarranted, it's selfish.

> I think user time is more valuable than developer time

Developers are users of their development tools.

> when building complex/efficient software expecting lightning builds isn't just unwarranted, it's selfish.

This is wrong. There is no rule that says that you cannot write fast applications with fast builds. It is just that we got used to C++'s slow build times.

This sort of thinking even falls flat on its face when you consider that C provides similar optimization opportunities as C++ (and in pretty much every modern compiler it uses the same backend and most - if not all - optimizations) while compiles much faster.

But beyond that most of the codebase of a decently sized application does not need more than the most basic of optimizations - it is only a tiny tiny fraction that needs that, yet with modern C/C++ (and most other) compilers, the entire codebase suffers for it (i think only Visual C++ allows you to control optimization settings on a per-function basis, but i haven't encountered any codebase that actually uses this outside of temporarily disabling optimizations for debugging and/or working around bugs).

Users typically want more features and lower cost a lot more than they want maximum performance. Faster builds help developers deliver more features at lower cost, so faster builds potentially have a bigger impact for users than faster software getting produced at the end of the build.

Yeah, but when there are other languages that also AOT compile to native code, with faster compiler toolchains, it is already a deciding factor when choosing languages.

Reply on news.ycombinator.com