Hacker News Reader

> I agree, though in practice with many Rust programs that iteration cycle is actually not "edit, compile, run", it's "edit, save, wait for rust-analyzer to update" which is generally much quicker (even if it is sometimes still a little slow).

This is one area that I think Dart did a good job on. They support both a JIT (I am not sure if it’s tiered) and AOT modes of compiling, the JIT targeted for development and AOT for production. This is the ultimate extreme of optimizing for both use cases, obviously it’s a ton of work, but I would love more languages to be like this. (I believe the JIT mode works directly on the source so there isn't an intermediate compilation step like Java, but it’s been a few years since I’ve used Dart)

[1]: https://dart.dev/overview#native-platform

I agree. And Dart's VSCode extension is suspiciously fast. Like it accurately finds compile errors in easily 100ms. I don't know what they've done so differently to pretty much every other system, where you're talking ~1-2s typically. It's very nice though.

This is the best of both worlds, that traces back to Lisp and BASIC environments.

Have all variants available and allow the devs to pick the right one for their current workflow.

Java, .NET, Eiffel, Common Lisp, Scheme, C++ (via stuff like ROOT and Live++, VC++ hot reload isn't that full proof), OCaml, Haskel, are all examples of these mixed tooling approach.

> in practice with many Rust programs that iteration cycle is actually not "edit, compile, run", it's "edit, save, wait for rust-analyzer to update" which is generally much quicker

Rust-analyzer is struggling significantly on larger repos, to the point of being barely usable.

Is this with the likes of Leptos? The fancy HTML macros add a ton of compilation time (and are an antipattern IMO).

No, just ordinary distributed systems stuff. tokio, serde, bincode, error/logging/testing crates, and stdlib.

> In most cases, Rust's very strong type system means you spend a lot less time actually running your program.

That just sounds wrong to me TBH. IME it never pays off to 'front-load' too much, you might get a working implementation of your original idea without ever running the code, but that original idea will almost certainly be "wrong" once you see it in action and you just wasted a lot of time agonizing over your type structure which turned out to implement a quickly outdated idea.

Nothing beats quick iteration on a running program when it comes to productivity.

> Because Rust's unit of compilation (a crate) is very large. In C/C++ it's a single file.

If the a C++ file includes any C++ stdlib header it will also also become very large (tens of thousands of lines of gnarly template code for common headers like <vector> or <string>). If the unit of compilation is a crate in Rust it should actually be faster to build than typical C++ projects which often put the implementation for one class into one source file (and each of those source files is expanded to tens of thousands of lines of code after includes are resolved).

C mostly doesn't suffer from this problem though, since C header typically are only a couple dozen or hundred lines of API declarations.

> If the a C++ file includes any C++ stdlib header it will also also become very large (tens of thousands of lines of gnarly template code for common headers like <vector> or <string>). If the unit of compilation is a crate in Rust it should actually be faster to build than typical C++ projects which often put the implementation for one class into one source file (and each of those source files is expanded to tens of thousands of lines of code after includes are resolved).

> C mostly doesn't suffer from this problem though, since C header typically are only a couple dozen or hundred lines of API declarations.

But then, there's no reason why Rust couldn't be like C. The issue comes from the dependencies and libraries bundled, which is not an issue per se of the language.

This sounds overblown to me, TBH. IME you hardly need to agonize over type structure for common day to day code. The benefits of the type system are highly advantageous to refactoring without causing breakage, so I become more nimble in getting towards the proper structure. This is precisely what allows me to iterate more quickly and is a benefit.

I had lots of coffee pauses when doing builds back in 2000, where our C bindings for the Tcl based server, used as Apache and IIS modules, across Aix, HP-UX, Solaris, Windows 2000/NT, Red-Hat Linux would take one hour per platform on average.

It is a single file, but when you include header files which get dropped in they can get to many hundreds of thousands of lines of code in practice per corresponding .o file.

But the level of parallelism possible is downright insane with C++ because of this property... once, out of anger at my build time on something I was working on back in 2016/2017, I set up a AWS Lambda as a compilation server (fully generic: all it had was my toolchain, not the code in question or even the build scripts) for something akin to ccache and successfully managed to build my project with a pipeline (I use that word as I was still doing the preprocessing locally) of at least a hundred simultaneous jobs: good luck ever pulling that off with Rust.

It is also generally very easy to break apart any file or decouple any header files using various techniques that don't affect your project layout or require any mental maintenance once done. In contrast, with Rust, you have to essentially refactor what your project even "means" to pull that off as you now need to be juggling a ton of microcrates (and then it seems like there is some inherent crate overhead so this becomes a painful tradeoff plane you need to optimize; compilation units have to become degenerated small before that matters in C++).

And, even then, the remaining slowest file in my insanely complex C++ project does tend to take a ridiculously long time to build (I have a 30-60 second long compile for one small component) and I have run out of low-hanging fruit; but, I honestly hardly ever actually have to build it: the coupling of header files is massively overstated as when you are in a tight build/update cycle you are generally modifying a single function in a source code file, not changing some header file of basic data types that will affect the code generation of literally the entire rest of the project.

Like, I get it: thinking about code as a merged set of linear forward passes is sometimes annoying, but it doesn't just enable massive gains in compile time... it also encourages more legitimate coupling between components as circular dependencies require extra code and upkeep for prototypes and that's good because circular dependencies are bad. Rust thereby is doing something that frankly feels super awkward: it is elevating behavior that frankly makes more sense only within a single file or at best a single object to a project organizational unit, which suddenly makes this all seem much more complicated to handle correctly.

In C++ it can be a module nowadays, which is similar to being a crate, yet it is faster, from my clang/vc++ experience.

> Because Rust's unit of compilation (a crate) is very large. In C/C++ it's a single file.

What do you mean exactly here?

In C++ you can compile each file independently from every other file. You can't do that in Rust; you can only compile crates (which are made of many files) independently. Within a crate you can have circular references for example.

So the smallest chunk of work that can be parallelised is much bigger in Rust than in C++. (Unless you are writing atypically small Rust crates and atypically enormous C++ files.)

I understand that's not a language limitation, but rather a compiler/toolset/ecosystem issue (like not having a standard ABI?).

I ask becasue I wonder what's the real culprit here and whether it can be solved or if it's due to the language.

It is like you say, mostly compiler/toolset/ecosystem, all 3.

While staying in the same ecosystem you can split your application into smaller crates, which many are doing. It's just not that ergonomic.

It kind of is a language limitations. They could have said "no circular dependencies at all!" (which is quite reasonable) and then it would be easier to deal with.

> In most cases, Rust's very strong type system means you spend a lot less time actually running your program.

> There are definitely exceptions though.

I mean.. I know what you mean but this is kinda what I meant with cope. Putting “running code” aside as an edge case seems like a dangerous moving-the-goalpost kind of Rustism that kinda grew out of the “Rust is so safe that if it compiles it’s correct”-meme. Once we’re doing serious and boring good old development, it’s a redeeming quality at best, imo. Not to mention that rust analyzer also suffers slowdowns in similar ways.

> LLVM is still the vast majority

That’s interesting. So why the meager numbers from cranelift then, judging by the post? Granted, I’m not doing Rust day-to-day anymore so I’ve been ootl.

> Because Rust's unit of compilation (a crate) is very large. In C/C++ it's a single file.

Isn’t this the same for Go? Sure, it’s a simpler language but we’re talking many, many times on similar sized projects (wish I could link to something but unfortunately anecdotally only). Is it monomorphization, macros, or just everything combined?

> So why the meager numbers from cranelift then

People are seeing 20-30% improvements thanks to Cranelift. Not sure why you think that’s meagre.

> edge case

It’s not an edge case but it is valid to say that the pattern of development is different. You’re right that people need feedback that what they’re doing is right within 1-2 seconds. They are getting that thanks to the IDE. They need their tests to compile and run within a few seconds, and they’re getting close to that.

I’m not disagreeing with you. In an ideal world all builds and tests would run within 2 seconds, like you’re suggesting. And yet, people are managing to ship software successfully, despite it taking more than 2 seconds. That suggests that maybe this 2 second thing isn’t a requirement and more of a nice to have. And that maybe, there is something to people relying on IDE feedback while coding.