7 ms·

Didn't fix the actual annoyances I have with C++: - Long build times - Overly complex language - Ugly syntax

deleted 4y ago
[deleted]
simplotek 4y ago
> Long build times Build times in C++ projects nowadays are mainly the result of naive approaches to project structure and total lack of care towards modularity. On top of that we also have helpers such as ccache and the like to further reduce build times by not having to build at all.
wheelerof4te 4y ago
Yeah, that's the one of the points of my comment. Rust inherited a lot of problems C++ had. While making some progress in areas such as security is a huge success already, the language has a lot of potential to do more.
Daishiman 4y ago
The long build times are a product of the type safety mechanisms built in. The language complexity is also a result of the qualities required for a low level language that can manage memory and resources with precision. Ugly syntax is subjective; I find it expresses cleanly most of the things you want in the domain. Those are not really priorities of Rust or most of its domains anyway.
- lifthrasiir 4y ago
  Interestingly enough, there is actually a bit of common misconception going. Rust compiles pretty quick if you don't generate binary. If you don't believe me you can compare `cargo check` and `cargo build` yourself. The current bottleneck of Rust compilation time is actually LLVM; there has been lots of efforts to reduce this (including MIR, because less code passed to LLVM means less time spent in LLVM), but LLVM performance still remains a major factor.
- svnpenn 4y ago
  This whole comment reads as a series of rationalizations. I like Rust and write software with it, but I also understand that Rust has some big problems, that are either a long way from being fixed, or will never be fixed. > The long build times are a product of the type safety mechanisms built in. The long builds times are a product of the crate culture. Like JavaScript, many people are happy to pull in crates that are tiny to avoid having to write anything themself. So you end up with many packages pulling in over 100 crates.
  - estebank 4y ago
    Funnily enough, total code size remaining constant, it is preferable to have more smaller crates than a few big ones. This is because the compilation unit in the Rust compiler is the crate, so having more independent crates allows for parallelization during compilation. You can argue that rustc should have either tools to help you split your large crates and/or automatically detect when a single crate has non-overlapping elements that could be compiled concurrently (but the former is not something anyone is working on to my knowledge and the later has the risk of small refactors significantly affecting compile times in an opaque way).
jll29 4y ago
You are right that some problems remain. The Rust compiler team is working on speeding up build times as we speak. Give it some time. If a language was perfect in other respects (e.g. free of memory leaks), I won't mind waiting a little longer for my builds, but I know this bothers many. In any case, it's being looked into. The complexity argument I agree. Rust won't be the last language for that reason. Already it influences languages like Zig and Jakt, who aspire to be simpler and still suitable for systems programming. I disagree re: ugly syntax, but that's a matter of taste.

deleted 4y ago

[deleted]

> Long build times Build times in C++ projects nowadays are mainly the result of naive approaches to project structure and total lack of care towards modularity. On top of that we also have helpers such as ccache and the like to further reduce build times by not having to build at all.

wheelerof4te 4y ago

Yeah, that's the one of the points of my comment. Rust inherited a lot of problems C++ had. While making some progress in areas such as security is a huge success already, the language has a lot of potential to do more.

Daishiman 4y ago

The long build times are a product of the type safety mechanisms built in. The language complexity is also a result of the qualities required for a low level language that can manage memory and resources with precision. Ugly syntax is subjective; I find it expresses cleanly most of the things you want in the domain. Those are not really priorities of Rust or most of its domains anyway.

lifthrasiir 4y ago
Interestingly enough, there is actually a bit of common misconception going. Rust compiles pretty quick if you don't generate binary. If you don't believe me you can compare `cargo check` and `cargo build` yourself. The current bottleneck of Rust compilation time is actually LLVM; there has been lots of efforts to reduce this (including MIR, because less code passed to LLVM means less time spent in LLVM), but LLVM performance still remains a major factor.
svnpenn 4y ago
This whole comment reads as a series of rationalizations. I like Rust and write software with it, but I also understand that Rust has some big problems, that are either a long way from being fixed, or will never be fixed. > The long build times are a product of the type safety mechanisms built in. The long builds times are a product of the crate culture. Like JavaScript, many people are happy to pull in crates that are tiny to avoid having to write anything themself. So you end up with many packages pulling in over 100 crates.
- estebank 4y ago
  Funnily enough, total code size remaining constant, it is preferable to have more smaller crates than a few big ones. This is because the compilation unit in the Rust compiler is the crate, so having more independent crates allows for parallelization during compilation. You can argue that rustc should have either tools to help you split your large crates and/or automatically detect when a single crate has non-overlapping elements that could be compiled concurrently (but the former is not something anyone is working on to my knowledge and the later has the risk of small refactors significantly affecting compile times in an opaque way).

jll29 4y ago

You are right that some problems remain. The Rust compiler team is working on speeding up build times as we speak. Give it some time. If a language was perfect in other respects (e.g. free of memory leaks), I won't mind waiting a little longer for my builds, but I know this bothers many. In any case, it's being looked into. The complexity argument I agree. Rust won't be the last language for that reason. Already it influences languages like Zig and Jakt, who aspire to be simpler and still suitable for systems programming. I disagree re: ugly syntax, but that's a matter of taste.