>big projects (my biggest project is 45k LoC) and it takes a couple of minutes to compile it

I don't think 45k LoC could be considered big, and I _do_ think a couple minutes compile time is a problem. I say that as a C++ programmer, a full recompile will easily get me out of the zone

Out of curiosity, not to argue: how much time it takes in C++ to compile 45k LoC?

It depends heavily on how you're counting lines of code and what C++ features you're using.

If you include a couple of C++ stdlib headers you're already well past 45kloc per compilation unit (for instance, including <vector> pulls in about 25kloc of code). Such a file usually compiles in a second or so, but the problem in C++ projects is that each source file pulls in the same headers over and over, which explodes the line count the compiler has to crunch through (I bet that in most bigger C++ projects, the actual project code is less than 5% of what the compiler actually needs to compile).

C is much more predictable, a 45kloc C project should compile and link in under a second for a full rebuild without optimizations, and at most 2..3 seconds with optimizations. The link-step is usually the critical part, since that's hard to speed up by throwing more hardware resources at it.

I have some projects of that size (ballpark), typically using some Boost (but not heavy on meta programming), Qt, and the likes. A fresh non-incremental compile usually takes less than a minute.

I have Rust projects that are many times smaller but take much more time for a non-incremental build. Of course, a large difference is that a fresh Rust build (after a cargo clean) compiles all its dependent crates, whereas many C/C++ libraries are provided pre-compiled by whatever system you are compiling on.

Well, what is the point in this comparison then? I'm not trying to say Rust is the fastest compiler on the planet, but really people don't even try to be objective.

If you're comparing, say, a 10 KLOC C++ program vs. a 10 KLOC Rust program, then the comparison is fair IMO. The end user doesn't care whether Rust chooses a different compilation strategy for dependencies.

End users run "cargo clean" really rare (I can't even name examples - really rare). If we compare regular compilation in C++, then we should take regular compilation in Rust, not something exceptional.

~100k loc takes 40 secs with `make -j 4` on my laptop.

Finally some numbers, thanks. Yes, Rust compilation is slower.

Like the others say: depends. But wasn’t saying C++ compiles faster, just that I know from experience that anything over a couple of seconds can ruin your flow.

No shit, I recently restarted a project [0] in straight C after giving it a serious try in C++. It's been a while since I dipped my toes, but a couple of weeks of decoding screens upon screens of template instantiations for every single compilation error and waiting minutes for a fresh build brings back memories. I'm not touching that madness with a ten foot pole again, they have some kind of crazy cult thing going where everyone agreed to pretend it's all good. Compiling the same thing in C is instant, I don't even want to think about how much time I wasted.

[0] https://gitlab.com/sifoo/snigl

Well, if you can't even call a range (seconds, minutes, hours) then I can say that Rust is more predictable at least :)

Couple of seconds for 45k lines - I think you are too demanding :) But if C++ can compile it in couple of seconds - great, good competition for Rust :)

That really heavily depends on the kind of code. Template metaprogramming slows down the compiler a lot.

So sometimes it takes couple of seconds, sometimes couple of hours? Maybe there's some approximate range.

C++ compile times heavily depend on the code that is being compiled and the build system that is compiling it. Code that doesn't touch STL or boost or do much metaprogramming of its own is going to compile extremely fast (especially when compiled in parallel). Code that pulls in half of boost isn't going to compile so quick without tweaking the build settings. Due to how variable compilation times are, I don't think the range you provided is that unreasonable. Build time is something that changes on a project to project basis.

It is indeed true that you can unintentionally leak resources, but it is still much harder. Also, what do you mean that it has unhandled exceptions and race conditions? Rust doesn't even have exceptions (although there are panics, which is not the same thing), and race conditions are statically prevented in safe code due to how a mutable reference works.

It's important to understand the difference between data races and race conditions. The former are a subset of the latter. Race conditions in general can happen even in single-threaded code. (Although admittedly Rust ownership semantics prevent many of the latter as well; for instance, modifying a collection while iterating over it is impossible, cf. Java `ConcurrentModificationException` which itself is thrown only on a best-effort basis.)

Theoretically they are different, in practice they are the same (it's just more difficult to handle panicking - sometimes you can't use catch_unwind because of it's trait limitations).

About race conditions: https://doc.rust-lang.org/nomicon/races.html

I feel like its quite difficult to call them the same in practice, when they serve very different roles: errors that are likely to be recoverable are not panics! in a sane rust api, whereas they very much are exceptions in sane C++. You recover from either in similar fashion, but panics! are intended to serve a much different role than exceptions (the common usage of exceptions in C++ being covered by Result<> in rust).

I hate when people use exceptions for regular errors, it triggers me hard. Please let's don't start this topic :)

You started it.... exceptions are mostly annoying because they are so verbose. Writing try... catch... is a whole lot longer than "if func() == null".

Exceptions are mostly annoying because they’re infectious, and somewhat undocumented (they’ve not part of the api; if an upstream library adds a new exception, all downstream code must now handle it [or document it]), and if anyone misses the update, its a runtime error waiting to happen. But notably, your compiler won’t say a word about it (unless its java, in which case you’ll probably get too much :-). Return codes are similar, but less cascade-y. Try-catch being verbose and fucking up control flow is just an added bonus.

Which is easier:

try: module.find_element() except: # handle not found else: # handle found

Or this:

if module.find_element(): # handle found else: # handle not found

It surely does, my Gtkmm demo application I wrote several years for "The C/C++ Users Journal" still compiles faster than the Rust rewrite in Gtk-rs, when doing fresh build or after minor changes.

Lack of binary library support on cargo, not having incremental compilation and linking does hurt.

There is incremental compilation. And cargo doesn't recompile libraries every time. Not sure how you don't know it if you really use Rust.

yeah, downvote it when you have nothing to say, that's how to make a discussion.

Facts:

Incremental compilation from 1.24 stable: https://blog.rust-lang.org/2018/02/15/Rust-1.24.html

Cargo recompiles dependencies only after "cargo clean" or after Rust version update.

I didn't downvote you.

Cargo surely recompiles common dependencies across crates, unless one uses the workspace trick and even then recompiles do happen.

Just get Gtk-rs, get nightly and then trace the build log. I once even mailed Rust devs about it.

Incremental compilation still isn't up to incremental compilation + incremental linking, which is why I explicitly mentioned both on my comment.

To clarify two things you've said:

1. Hacker News won't let you downvote someone who replies to you, so it is literally impossible for you to have downvoted in this situation.

2. Both of you are correct, because you're talking about different things. Evgeniy means "You only need to compile your dependencies upon the first build", and you mean "if I use the same dependency in two projects, it will be compiled twice, once on the initial compile of both."

Thanks for the clarification.

No problem. Others haven't had this conversation as many times as you and I have :)

Yep, I still look forward to eventually advocate the contrary.

Even when I sometimes sound negative, I really appreciate your work.

Rust achievements thus far already influenced design decisions in other languages.

> And cargo doesn't recompile libraries every time.

Given how often Rust updates, it might as well.