5 ms·

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 l

by Crinus 7y ago

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.

munmaek 7y ago
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.
- boris 7y ago
  You probably mean 9.0.0, 4 is several years old. Or is Rust really still using something pre-4?
  - steveklabnik 7y ago
    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.
  - munmaek 7y ago
    My bad, I guess I was confused earlier about something else.
kbenson 7y ago
> 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.
- pjmlp 7y ago
  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.
  - pcwalton 7y ago
    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.
    - pjmlp 7y ago
      So you have measured ldc, F# .NET Native, Delphi LLVM backend, Eiffel compilation via clang?
      - pcwalton 7y ago
        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.
        steveklabnik 7y ago
        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.
fluffything 7y ago
> 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).
- tick_tock_tick 7y ago
  If you use similar feature sets rust compiles significantly slower.
- pjmlp 7y ago
  With C++ I don't need to compile 3rd party dependencies from scratch.
Rusky 7y ago
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.
- pjmlp 7y ago
  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.
  - Rusky 7y ago
    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.
unlinked_dll 7y ago
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.
- TheCoelacanth 7y ago
  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.
- pjmlp 7y ago
  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.
- Crinus 7y ago
  > 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).

by Crinus 7y ago

munmaek 7y ago

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.

boris 7y ago
You probably mean 9.0.0, 4 is several years old. Or is Rust really still using something pre-4?
- steveklabnik 7y ago
  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.
- munmaek 7y ago
  My bad, I guess I was confused earlier about something else.

kbenson 7y ago

> 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.

pjmlp 7y ago
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.
- pcwalton 7y ago
  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.
  - pjmlp 7y ago
    So you have measured ldc, F# .NET Native, Delphi LLVM backend, Eiffel compilation via clang?
    - pcwalton 7y ago
      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.
      - steveklabnik 7y ago
        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.

fluffything 7y ago

> 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).

tick_tock_tick 7y ago
If you use similar feature sets rust compiles significantly slower.
pjmlp 7y ago
With C++ I don't need to compile 3rd party dependencies from scratch.

Rusky 7y ago

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.

pjmlp 7y ago
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.
- Rusky 7y ago
  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.

unlinked_dll 7y ago

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.

TheCoelacanth 7y ago
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.
pjmlp 7y ago
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.
Crinus 7y ago
> 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).