Hacker News Reader

Comment by johnfn | Hacker News Reader

I tried Rust about a month ago. The language itself is amazing, the pattern matching is super expressive, the borrow checker is incredible in the kinds of errors it can pick up on, and rust-analyzer is leagues beyond where RLS was. But... the compile times are an absolute non-starter for me. I'm the kind of guy that likes to re-run his code continually to see if it validates to what I expect it to be doing. In Rust, this kind of workflow just doesn't work at all. The long compile times completely kill any enjoyment or flow that I normally get out of productive programming. Even worse, I found myself anxious to introduce new dependencies, because each new crate would add a few more seconds to the compile time, which immediately correlates to less coding enjoyment.

I keep reading in Rust surveys that Rustaceans just don't care that much about compile times enough to prioritize improving them. I've often wondered how this can be possible, given that to me it's such an obvious glaring issue that all the other cited problems are distant distant seconds at best. I have a theory: there must be two groups of engineers. One group loves fast compile times and quickly validating hypotheses. The other group must value thinking about their code a lot more than running it, and so compile times aren't that important. My guess is that, while the second group hangs around and loves Rust, Rust has completely driven away the first group (including myself) to the degree that they don't use the language enough to even fill out the surveys.

Anyways, I know it has a wide swath of use cases, mostly in systems programming. I'm just bummed that if I ever do any of them, I won't really enjoy it. :-(

[EDIT:] Gotta go to sleep, it's far too late here. I really appreciate all the thoughtful replies. Rust's amazing community is another reason it annoys me that I can't fully get into the language as I'd like to.

View on HN

> I keep reading in Rust surveys that Rustaceans just don't care that much about compile times enough to prioritize improving them.

I am interested in how you got that impression, because at least in our official surveys, it's often one of the most-requested improvements to Rust, and it's something that we're constantly working on improving. Still a ton of work to do though!

For what it's worth, my workflow is closer to yours than "compile twice a day." And if you're using rust-analyzer, by default, it compiles the code every save!

Maybe with some heuristics, you could hide some latency by beginning to compile before saving.

Maybe. At the rate I hit :w, probably not :)

How do you have Vim (or neovim) set up to do that and report errors inline?

I use VS Code with the vim plugin.

I hear you can get this working with vim/neovim but I haven’t done it myself.

How I did it is that I install VimPlug then CoC then the rust extension.

I use ALE, which I believe includes Rust by default.

https://github.com/dense-analysis/ale

One of the first computer system I used frequently was Windows ME. This system used to crash (BSOD) extremely frequently (depending on what you were doing, it could be as frequently as every 20 minutes), and any unsaved work would be lost.

I have therefore developed a reflex where I hit Cmd-S every time I finish typing. I actually have to put conscious effort in to stop this when using software where saving is slow.

I used to work on some 3D printing related software, and so I had to type “Objet” a bunch and it was impossible to not type “object.”

Here's the exact thing that I checked when making this conclusion a few weeks back, the most up-to-date state of the compiler roadmap that I could find: https://rust-lang.github.io/compiler-team/minutes/design-mee... I see 16 top-level goals on here for next year (under the Goals section). The only thing that seems related to compile speed is to continue working at incremental compilation (no new initiatives?). And even there, the only action item for the entire year is to create a working group.

I love rust-analyzer! But I'm not sure what you mean by "it compiles the code every save." I love how fast it can type-check my code, but I was unaware it could actually compile my code into something I can run? I thought it was just a LSP provider.

Ahh I see. Yes, so that's meeting minutes, so they're very inside baseball, and so it would make total sense that you would get this impression from this.

Before we get into that, to answer the other question:

> But I'm not sure what you mean by "it compiles the code every save."

Rust-analyzer (by default) will run "cargo check" on save. cargo check does everything except codegen, so it won't give you something you can run, but it does invoke the full set of compiler analyses and everything else.

Now, what it does with the type-check stuff is the key to understanding what you're missing from the compiler team roadmap, funny enough. So rust-analyzer is actually going to end up merging with the rustc codebase eventually, if all things go to plan. Basically, rust-analyzer is slowly re-implementing the compiler from the outside in. It's doing this because the best way to get the largest win on compile times is to completely re-architect the compiler. This comment is too long, so I won't get into too many details, other than to say that it's going to be less like the Dragon Book and more like C#'s Roslyn, if that means anything to you.

It's doing this by taking advantage of a process called "librarification," which is extracting stuff from the compiler into re-usable libraries. You can see this on the notes when they talk about chalk; chalk is the next-generation trait resolution system. This is integrated into rust-analyzer, and into the compiler. So slowly, bit by bit, things are being re-architected and integrated in a way that will be much, much better in the future.

So this is a massive, massive project that touches everything, and so there's nothing spelled out in the minutes that says "this is for compile times" because the folks involved already have this context, basically.

And so yeah, that's the big project. There are also contributors who, while this larger work is going on, are working on individual PRs to make things faster. See https://blog.mozilla.org/nnethercote/ for one of the largest contributors in this regard, that talks about the work he's doing. But that doesn't appear on this either; there's no need for a plan or coordination here.

... does that all make sense? I am thinking maybe it would be good for us (to be clear, I mean the Rust project, I am not on the compiler team and am not doing this work) to like, actually write a blog post on all of this...

Mostly, that makes sense. I think the thing that doesn't make sense to me is that rust-analyzer seems to me to be a LSP - my mental model of it has nothing to do with codegen. And I thought that codegen and linking was the slow part in Rust (cargo check runs so fast!), so how could those gains be brought back to rustc? I'd bet other people have this misconception, too - maybe that should be highlighted on the rust-analyzer readme on Github.

If rust-analyzer will eventually introduce those gains to rustc, that is fantastic news, and I'll be watching it with great interest! The improvement from RLS to rust-analyzer is exactly the type of improvement that brought Rust from the "fascinating tech demo" to "I could actually see myself using this day-to-day."

And yeah, I'd love to read a blog that went into more detail.

> working on individual PRs to make things faster. See https://blog.mozilla.org/nnethercote/ for one of the largest contributors in this regard

Yeah, I read through that too. He's my hero! :-) But the feeling I got when reading it was: "fast compile times" really need to be part of the DNA of a language. Let me explain what I mean. Some languages, like Go and TypeScript, have this in their DNA, and that means that every design decision and every addition to the language is considered seriously through the lens of compile time speed, and vetoed if it were too costly. But with Rust, the fact that there's one guy writing a blog post about some incremental wins he managed to chalk up just... doesn't seem like it's part of the DNA. If it is, why is it just one guy, and why do a lot of his changes seem more like incremental wins than the big sweeping changes I'd expect to be necessary? I could definitely be wrong here (sounds like I am and rust-analyzer is that big sweeping change).

Thanks for all your great responses, by the way. I really appreciate it!

> Thanks for all your great responses, by the way. I really appreciate it!

Any time. :D

A couple more brief comments:

> rust-analyzer seems to me to be a LSP

Remember that LSP is a protocol, something/someone has to actually figure out the answers. Like, the LSP says "please draw the squiggles here", but something has to actually say "line 1, column 10, please". Doing that involves semantic analysis, which is what a compiler does.

> And I thought that codegen and linking was the slow part in Rust

It is the slowest part of the current architecture, but that doesn't mean that the current architecture is the best possible one.

The RLS invoked the compiler, and then examined its output to say "line 1, column 10, please". And you said you saw the improvement with the architectural switch to rust-analyzer. Same thing.

> "fast compile times" really need to be part of the DNA of a language.

You are correct that, when push comes to shove, if there's a tension between, say, runtime speed and compile-time speed, Rust will choose runtime speed. Rust will not have compile speed as high up on the list of concerns as Go does. But it is important enough that we don't let major regressions happen, and actively pursue improvements where possible. https://perf.rust-lang.org/ for example, tracks this data over time for this kind of reason.

> why do a lot of his changes seem more like incremental wins than the big sweeping changes I'd expect to be necessary?

Well, again, it's not always either or. He's doing the incremental thing, and others are doing the big sweeping changes thing. His improvements land nearly every release, but the bigger projects take a lot longer. They work in tandem to make things better than they were before.

I don't have that much to add to the discussion, really. I just wanted to ruminate on something:

> I've often wondered how this can be possible, given that to me it's such an obvious glaring issue that all the other cited problems are distant distant seconds at best.

It's amazing how little I understand your point of view. And I'm being genuine and not critical of you at all.

To me, all of the features of the language, from move semantics, to ergonomic sum types, to nicer error handling (to me. I know it's debatable), and great runtime performance are so important, and bring me so much more peace and joy while working that compile times are literally not even on my radar. I simply don't care if they ever get better (assuming that effort is being put elsewhere. I guess if the language is "done" then work on the compile times is appreciated).

And I've certainly done real work in languages that compile fast (Go, Java) and languages that don't even compile. They always made me so much less happy because of the languages themselves just not clicking with my mental model of problem solving. Again, compile-run feedback loop just had nothing to do with it.

All that said, I use Rust Analyzer for code completion and it's generally fast enough. But it's still sometimes has a noticeable stall. That's not my favorite and it's kinda related to compile times.

Just really amazing how different people using the same tool have such wildly different modes of interaction and perceptions. Cool stuff. Cheers!

The time to compile these small web apps is not worth worrying about after the initial compile. I'm not sure what he's getting at to be honest. While it's certainly not instant, it's not that bad.

Believe me, I love the same things you love about rust. Move semantics, sum types, error handling are all amazing, to say nothing of the ridiculous perf!

I think our difference is I spend a lot of time on graphics and games, where there's a lot of manual tweaking that you have to do. (Is 20px far enough? 25px? Is 1 second long enough for the explosion? Maybe 0.5s instead?) There's just no way to test it outside of rerunning the app.

In dynamic languages like JavaScript or Python it's necessary to continually run your code in order to validate that the API (of the standard library or of dependencies) was used correctly, that the types match, etc.

Rerunning your code continually is no longer necessary in a language like Rust, because the compiler already does that for you.

People complaining about slow compile times in static languages like Rust, Haskell, Scala miss the forest from the trees, which is that the compiler eliminates entire bug categories, logic you'd otherwise need to check at runtime, either via unit tests or at least by running the code locally. Compiler times can always be better, but the compiler works as a theorem prover and the slowness is entirely justified, overall yielding a better ROI.

N.B. I'm not saying that with Rust you don't need to run your code or have unit tests. There's only so much a compiler can prove. But you no longer need to do it as often.

You can't switch to a language like Rust and expect Python and if you do, then the experience is going to be horrible, because Rust is a very different language.

> In dynamic languages like JavaScript or Python it's necessary to continually run your code

No it's not. It's just preferable to do your work in smaller batches so that your feedback loop is fast and you know exactly which change broke things, rather than making 10 changes and then having to figure out which of those changes 4 bugs relate to. And it's better to discover a flaw in your implementation early rather than late, which is also easier when working in small increments.

You get used to it and adapt. That might sound bad but comes with benefits as well. You will train yourself to think and be thorough to get it right the first time without it slowing you down.

Getting feedback quickly can be useful (especially when trying something new), but not needing it is liberating (especially when trying something new).

For me the problem would be learning how something does or does not work, even with a compiled language.

The reason I hate Spring for example (not that I've worked with it extensively) is that the documentation gives you zero feel for what you expect the behaviour to be. It will compile, but until you run it and check what it's doing, very often you'll be developing with no idea of what you're actually building.

Especially if you're trying to get specific behaviour of what you want to see (e.g: figuring out why it won't send mail, or why it doesn't ignore a certain json key or whatever), it still needs many runs to get right.

In theory and to some degree in practice. The compiler won't fix the code that compiles but runs incorrectly. Besides, there are statically typed functional languages where compiling time is not a problem, see D.

I haven't worked with D, but D isn't a functional programming language ;-)

You will be surprised if you do ;) Multi-paradigm to be exact. Scala is a multi-paradigm as well btw.

http://beza1e1.tuxen.de/stuff/FunctionalD.pdf

Julia also has plenty of functional features, but is above all a practical, fast, and fast-compiling language.

The elegance is free.

You can have your cake and eat it too, Ocaml & Go both have type systems and compilers that are fast enough to work iteratively

Ocaml is a somewhat fair comparison, but I have to say that Go is really in no way comparable to Rust. Rust is massively more complex.

I'd say Go is a fair comparison here.

Type checking and Parsing isn't bottleneck in Rust compilation. Code generation is. LLVM is particularly heavy and while it generates optimized code, it is quite slow.

Go Authors didn't pick LLVM because of compile speed reasons (as well as complexity), and that turned out to be worthwhile tradeoff.

Well, worthwhile in terms of compile times, which makes sense knowing google’s codebase. Most people aren’t compiling massive dependency trees that can’t fit on any single computer when they push a commit.

Anyway in C++ land massive compile times are just as much of a problem. Fast code is expensive. Go’s a lot of things, but being good at generating fast code ain’t one of them (looking holistically anyway).

> Fast code is expensive.

Indeed, because all bigtech can invest on is LLVM and C++.

The research on compilers and optimizations has not been getting the attention because of LLVM monoculture and the monstrosity that is C++.

Well, rust is modularizing, so there will be opportunities for alternative backend (crane lift?).

The reason it's not a fair comparison is because go is a barely typed language that requires casting to interface non stop

If you're casting to interface{} non-stop, you are doing something against the grain of the language. It works, but there's probably a better way of getting the result you are looking for.

Right, building generic, reusable code is against the grain of the language.

I told type system is not the bottleneck, codegen is.

Even if you count the size of ode after monomorphization, I am pretty sure the Go compiler compiles it much faster. Because the compiler is not in the benchmarks rat race of adding one optimization pass from every academic paper in the world for diminishing returns. That would be unnecessary for a development compiler.

Go compiler could have an optimized slow build option, in ideal world, but that's a different matter altogether.

Go's authors didn't pick LLVM because they weren't sufficiently familiar with it to implement what they needed (e.g. segmented stacks). See https://news.ycombinator.com/item?id=8817990 for the full explanation.

But the compiler checks your code, and if the compiler is slow, the problem remains.

A good IDE effectively checks your code continuously.

The compiler is slow at building code. It's much, much faster at checking it.

Rust's type system doesn't have a notion of "looks right visually," so the compiler is ipso facto unhelpful there

Could you expand on this? It seems like you might have a really interesting point to make but I can't tell what it is :)

Short compile times are beneficial when development involves a lot of trial-and-error.

The parent comment was insinuating that, when developing in Rust, one can leverage its type system to replace this trial-and-error with static verification. And, indeed, if what you're worried about is a dangling or null reference error, the Rust type system has a rich language for specifying expected behavior so you don't have to run your code to check it.

If, on the other hand, your job description includes the nebulous mandate to "make it look right," there isn't any feasible way to design your types so that Rust can check that. For example, sometimes I have to do something like "make sure the dialog box is wide enough that it doesn't truncate the title string on any relevant platform." The Rust type system has no way for me to query several versions of macOS and Windows about when they start truncating dialog-box title strings and size my dialog that way, so here I am, still performing this task by trial-and-error, waiting forever to compile my code each time.

Nothing about this is Rust-specific by the way. I'm similarly bearish on statically-verified cross-platform dialog boxen in Haskell. And that's one of my dumber "make it look right" tasks - I work on CAD software so most of them involve 3-D graphics and/or computational geometry.

And, returning to the parent comment, waiting for C++ to compile in order to test things is a giant fucking time-sink and drain on my productivity. It can't really be automated, or, if it can, it's way beyond the reach of this organization's know-how.

In summary, I call bullshit on static verification replacing snappy trial-and-error in the UI / Graphics space. In practice, you're left shifting UI / Graphics customization out of the host language and into "content" so that you can tweak it without re-compiling. But this is another massive fucking time and complexity sink that only exists because at some point you let your compile-times get so far out of control that your people couldn't do their job ("make it look right") in a reasonable amount of time.

I see, the type system cannot ensure logic bugs, specifically with an applied example of the visual aspect of an application. Got it. Thank you for expanding on it!

As a datapoint for your hypothesis, when working in a typed language I will build my code only a few times a day.

I much prefer working from a logical and thoughtful approach rather than iteration. At the point where I start a build I am already reasonably confident that it will do what I want it to.

There are some bugs where I will need to re-build several times consecutively but these are relatively rare for me (I work on REST API systems - so nothing too crazy).

That's really interesting. Compiling only a few times a day is mind boggling to me - in a normal day I'd probably average hundreds to a thousand compilation cycles!

The main thing that I use compiling for is to validate little off-by-one things. Like, is substring() exclusive on the second parameter? What about range syntax and the slice operator? What if I wrote + 1 instead of - 1 somewhere, or did < instead of <=? I could spend a few minutes combing documentation, or just compile it and check immediately. Well, assuming compilation is fast anyways.

>> in a normal day I'd probably average hundreds to a thousand compilation cycles!

Maybe it's time to switch to an interpreter ? :-)

Or a language like Go, C or Nim that can compile tens of thousands of lines of code in a few seconds.

Or OCaml, Java, C#, F#, Eiffel, Delphi,...

Just googling “f# compile times” would beg to differ.

Apparently you didn't bother to read the 3 answers that come up.

Only one of them says anything and it an empty statement like

> F#'s compile times also seem to err on the long side but not very much so, my impression goes.

However it is quite easy to validate write the same algorithm in F# and Rust and then compare.

Ah but Rust is AOT compiled, easy, use NGEN, .NET Native, or Mono AOT for the F# compile time measurements.

Apparently you assume that everyone’s google results are identical.

If that’s the case, then there’s no point in making any claims about what “just googling ‘f# compile times’ ” will reveal.

I've had a reviewer in a (scientific) journal tell me some paper is relevant, and thus I need to cite it, because it "appears on their top google results".

People should be educated on the huge bias introduced by personalized services like google.

I've worked in a C# code base where compiling the solution took 40 minutes.

Wow, one of our solutions is nearly 100 projects (legacy) and the compile time for the whole solution is sub-5 minutes. I'd love to see what kind of solution would take 40 minutes to compile! (or maybe I don't :)).

That being said, C# is clever enough to only need to recompile the assemblies affected by your code change, so often you can get away with 10 second compile times even for large solutions.

IIRC our solution was around 450 projects. Visual Studio just woudn't open the whole solution.

So you had to work in individual projects at a time, slowly going through and changing stuff project by project.

VS wouldn't even build it either, really. YOu had to build via batch file that did various ms build magic. I would make changes, set of a build and go to lunch, then come back and fix the errors.

Once you checked the code into source control it would trigger a build which would sometimes take upwards of an hour :( I hated that code base.

It got even worse when they added Coded UI tests. Wait an hour for a build and then a random Coded UI test would fail and the advice from the people who wrote the Coded UI was "just run another build!", yeah, flakey tests on a code bases that tests an hour to run...

Now imagine with the current Rust compile times, compiling those 450 projects from scratch, I bet the 40m would turn into hours.

You forgot about D, where you can basically bind ctrl+s to rdmd in your favourite IDE and enjoy scripting language akin experience.

D is sadly very underrated.

My day job is in C and compile time is 30 minutes. It really depends what you're working on.

Does it take that long for an incremental build?

I've used Nim just a bit on Windows/MingW (I'm from python world). The very short program I made (about 200 lines, mostly math stuff, no framework imports) compiles in 2-3 seconds. It's already too long for me to iterate (it's not a rant against Nim, it's just that it's too long for my way of working; the language is nice and gives good results). Also note that Nim compiles fast, it's the compile-to-native compilation step that takes 90% of the time.

You mean a REPL, or an interpreted language?

I'd love a REPL that could somehow load the state of my entire app so I could test stuff out, but I've never found a language that could do that and also had reasonable type safety guarantees.

Some of the best solutions to that world right now seem to be things like lisps with dynamic typing added. You get a great set of repl support, but you can also build components and systems into easy wrapper scripts to load them as needed.

I assume you mean static typing enabled. Because lisps are already dynamically typed to begin with.

Thanks, I actually meant gradually typed systems, like rust typed or closure with heavy spec usage.

I think you mean Clojure. Closure is something different.

What a terrible day for autocorrect, thank you.

Clojure has a java type system which can be partially enforced statically with clj-kondo

Clojure spec is great at system boundaries but it's hard to describe it is a type system, it's a predicate system it can define very arbitrary constraints mostly at runtime

As a spec user in production, I must say it's very nice usability-wise and can help alleviate most of the issues coming from a lack of a type system.

But god it's slow... Some static analysis support would also be hugely appreciated. Not being able to check everything doesn't meen you shouldn't attempt to check something! Many specs are type predicates anyway.

Visual Studio can give you a REPL experience for a number of languages (notably C#, of course) using its Immediate and Interactive windows.

With Jetbrains IDEs (IntelliJ, Webstorm, CLion) you can run a "sketch" that can "see" any module in your project. I use that a lot in Java/Groovy/Kotlin/Rust and it feels much superior to a REPL because I can write not just one-liners, but larger amounts of code, with all the features of the IDE like auto-completion, inline docs, syntax checking etc.

A test suite facility can also be used like this. And Rust adds any "examples" you write in the code (with proper doc formatting) to the test suite, as mentioned elsewhere.

A test suite has a different use case... REPLs/Sketches are useful for exploration... both of your own design and of libraries you're using. Tests can be used for this as well, but it's not as convenient when you're very "early" in your exploration or have no code yet to test at all.

Have you try Haskell? The most used compiler, GHC, shipped with it's own REPL and it's quite good. Something I missed when coding in Rust.

> The main thing that I use compiling for is to validate little off-by-one things. Like, is substring() exclusive on the second parameter? What about range syntax and the slice operator? What if I wrote + 1 instead of - 1 somewhere, or did < instead of <=? I could spend a few minutes combing documentation, or just compile it and check immediately. Well, assuming compilation is fast anyways.

I'm a really big fan of reading the docs (or, where the docs are insufficient, the source), and will always have docs.rs open alongside my editor. While the examples you provide are easily validated by testing (and I'd probably use `evalr` in `##rust`, or some similar thing, for them), many subtleties can exist in more complex functions, so not reading the docs/source for unfamiliar functions feels like programming-by-guessing to me.

Perhaps my examples were a little too trivial. I do a decent amount of game/graphics coding, so there's a lot of "hmm, does this look good 20 pixels over? How about 18?" and I don't know how you'd get around that without recompiling.

(OK, you could read preferences from a file, but then you'd have to optimistically write every value you'd ever want to recompile to a file. I've tried this, but it's far too much overhead.)

> I do a decent amount of game/graphics coding, so there's a lot of "hmm, does this look good 20 pixels over? How about 18?" and I don't know how you'd get around that without recompiling.

I know exactly what you mean. Front-end development can be this way, too.

I think it's OK (and probably true) to say that you shouldn't use Rust for cases like this right now.

> I think it's OK (and probably true) to say that you shouldn't use Rust for cases like this right now.

I think that's true, but only because of the slow compile times. Which is why they're so frustrating. Rust would otherwise be an excellent language for these use-cases.

I see where you're coming from. The good news is that compile times are something we are certain will get better. Rust's maintainers know it's a high priority, but even if they didn't, we would still benefit from increasingly powerful machines used for graphics/gaming development.

Yeah. It's a bummer because Rust would be a fantastic language for gamedev otherwise, and a lot of people are interested in it for this reason. It's got everything else you'd want out of a good gamedev language - no GC, smart memory model, blazing perf, really expressive...

Yeah, for game/graphics stuff I can definitely see that.

FWIW, I am with you in the camp that cares about compile times. I use C++, I care deeply about compile-time correctness (and have "as close as I can get to rust as I can" abstractions for tons of things such a small locks, but then take advantage of the almost-dependent typing provided by C++ to go even further than you can in rust to prove correctness of my buffers), and I envy people who get to code in Haskell or Idris. I am not a "dynamic typing" addict by any means.

But I work on network protocols and file formats and parsers and video transformers and user interfaces (often command line or web) and a long time ago games ;P... I make a small change and then I want to see the behavior difference. I almost always type code that compiles, but that doesn't mean it did what I want when interacting over the network: rust doesn't provide anywhere near powerful enough type abstractions to actually prove my code is correct... it only is proving that my code can't crash and will avoid undefined behavior.

What is so frustrating is that there is nothing about Rust that makes it impossible to make fast. With C++ I get to manually make tradeoff in my code on a file-by-file basis with an assumption that my project will be built out of thousands of mostly-independent fragments that I am able to compile incrementally or in parallel. I can very rapidly isolate individual functions I am working on for fast iteration without having to restructure my project, I can tell the compiler to instantiate templates in different ways to reduce dependencies, and I have designed a system to let me do parallel compiles on AWS Lambda (I haven't yet gotten my build environment to be ready for a -j1000 parallel build, but I am somewhat close).

I have been integrating some rust libraries into my codebase (I haven't even gotten to the point of really coding in it omg) and Rust is just so painful and frustrating to work with... and it really does just seem to be, as you pointed out, a matter of priorities and interest: there is this myth that it is some kind of tradeoff on the type system, but it isn't; it is just that the people who work on rust seem to not work on the same kind of projects that we do, at least in the same way, and so have made a bunch of trade offs like "I would rather never have to type a prototype than save any time compiling" and "I would rather my build system never have to consider dependency management than save any time compiling" and "I would rather provide the highest possible quality resulting binary than save any time compiling" (which is at least one I can appreciate, but only once a month when you cut a release... not the hundreds of times a day that I recompile my C++).

> "I would rather never have to type a prototype than save any time compiling" and "I would rather my build system never have to consider dependency management than save any time compiling" and "I would rather provide the highest possible quality resulting binary than save any time compiling"

Rust outputs prototype information in .rmeta artifacts that are generated as one of the first steps in compilation, so this is not a compile-time issue. AFAICT, dependencies are also tracked, and debug vs. release switches are provided that also control things like binary optimization.

The real "problem" for compile times in Rust is that Rust makes it idiomatic to write code that's slower to compile. That's really all there is to it. If you were to literally write Rust like it's C, you'd find that there's no real overhead introduced by Rust per se.

(This is not to say that improvement is not possible, of course. Even what's "idiomatic" can be tweaked over time to reduce the amount of excessive, duplicated work that the build system has to do. Newer features like const generics will probably make this feasible in the future, and improvements in the compile workflow itself will do the rest.)

Yes, for example I can easily do multiple UI changes in UWP, with C++/WinRT or C++/CX, in a fraction of the time that it takes to build Rust applications.

I am quite curious how usable Rust/WinRT will turn out to be for WinUI work.

That’s the sort of thing where you often use another language suitable for hot reloading for such customisation or rapid-feedback alteration. As a couple of examples I’m aware of:

• The Azul GUI toolkit uses CSS for styling of its widgets, and hot-reloads stylesheets.

• The Mun programming language is designed for the sort of niche Lua is often used, with hot-reloading scripting-like functionality to augment your Rust code. (Well, Rust is the main host language at present, anyway.)

Unity build times on a huge project aren't hot, either; particularly when you must build a client to test.

Why not have controls in your program to do these immediate, non-logic changing modifications? It can report the ideal value through a debug interface. No recompiles needed.

I'd also recommend getting used to serialisation/deserialisation. Serde for Rust makes this remarkably easy. Writing every setting to a file is simple if the compiler can do it for you, rather than you walking the long way around.

When you're doing any sort of non-trivial gamedev, graphics, or physics simulation work, there are so many instances when you have to get a bunch of magic numbers by trial and error, and it's usually all over your code. If you try to "refactor" these cleanly into a separate JSON file (hint: it NEVER is that clean), it still takes time and effort away from you to by writing boilerplate code, which seriously kills your momentum for experimenting and iterating with your code. It's kind of a niche domain-specific thing which most gamedevs and graphics programmers would sympathize with.

Also there are also a shit-ton of minor logic-changing modifications when you're writing prototype gamedev code, (for example, moving an if statement here or there to tweak the physics of your platforming). These cannot be easily represented in config files, and this is why people attach lightweight scripting languages like Lua to their game engines (so that you don't have to wait for those atrocious C++ compile times when tweaking your gameplay code).

(Ironically, serde is known for its atrocious compile times, which really makes the situation even worse. Because of this some frustrated Rust gamedevs wrote their own serialization libraries such as nanoserde (https://github.com/not-fl3/nanoserde)... but you get the point.)

If you have an editor with syntax checking such as VS Code with rust-analyzer, it checks syntax in the background as you type, saving you a lot of compile cycles. It doesn't yet scale very well to huge projects but getting better every week - rust-analyzer is under very heavy development.

Rust has a testing facility that can be used for these things. By default, all "example" code that's included as part of a doc comment ends up in the test suite. And because test cases are small and self-contained, they're also very quick to compile.

I've to say, I really hate this way of working, which might be the reason why I prefer statically typed languages like Rust.

I think the main reason why I dislike working with dynamically typed languages is that most of them make the reasoning of code a lot harder. If you're able to reason about the code at hand, then there's a lot less need to run the code for every small change.

> is substring() exclusive on the second parameter

I can’t imagine not looking up the documentation to do this.

If a language had a REPL I may then confirm it in the REPL, but almost certainly would pull up the docs first.

Assuming you take ~4 seconds from wanting to compile til you have your answer, that’s 60 minutes a day for a thousand compiles. An hour. Doesn’t seem very efficient to me.

Not OP, but these things don't have to be synchronous. I sometimes have entr running in a separate terminal, which tests and builds on every save. I don't wait for it to happen, but I do see it if it errs.

As one more datapoint, I do this (=barely ever "compile" / run) even in dynamically typed languages. My primary is Python.

Definitely a leftover from when I was a kid, in the early 90s, without ready access to computers. I remember lying at a hospital bed and filling pages and pages with C64 programs, using pen and paper.

This kinda forced me into the paradigm of "think through invariants and structure first". To this day, typing code out on a computer (incl. compilation) is almost mechanical, not a vital part of the design process.

+1 for that data point. The type system allows me to be much more explicit with regard to what I expect my code to do. And Rust-analyzer helps me spot those parts that don't fit together. But I typically turn it off, until I am actually done with defining all data types.

I also use assertions and unit tests, because the type system still has its limitations (or some things would be too awkward to express), but I can move forward a long way without actually compiling a project.

That's spot on. I mostly work with C#, F# in a day to day job and I build my code only a few times. This is also true when I work with Java, Angular and TypeScript. When I pick a new feature to implement I design that on paper with pencil and then mostly translate that to code. Mostly I can code for hours without compiling since this is where Typed Languages have strength.

Try to do design GUIs without compiling. :)

I agree that whenever I've to "adjust" something in HTML, CSS, its always a struggle with multiple tries and write-run-write-run cycle. But again, this has nothing to do with how you design and write code in a static language.

Sure it does, for example in SSR frameworks, you want the HTML template engine or UI designer to see those components.

I guess it depends what you're working on.

I mostly work with C#, and occasionally I might only end up compiling the project a couple of times in a day, but I'll probably be building a test project several times in the meantime (e.g. after adding each test).

Alternatively, if I'm building a web GUI, I'll probably be building quite frequently, making sure that data is bound correctly and that the UI looks as expected.

That's very interesting. I can never work that way. I compile constantly (C++)

I York in C#, Java, and Go and I mostly use a combination of these modes. I will usually take some time to design a feature and write it out almost entirely before even the first compilation. Then, I will usually start a compile-run-debug-edit cycle to fix all of the off-by-one type errors, cover missed cases, the occasional wrong assumption etc.

I don't think typed vs untyped languages really makes a huge difference if you're designing code this way. The difference comes when the compiler can actually verify your design, if you don't compile it doesn't really matter what the compiler can check.

That doesn't work for GUIs, which in this case would be SSR.

As a counterpoint, I'm mostly working in typed, compiled languages, and I compile and debug-step through my changes in much smaller increments (usually a couple of minutes). But this only works because part of the work is to always fight 'compile time bloat'.

It is easy to let a project slowly slide into a state where this workflow is no longer possible, especially in high-level languages like modern C++ or Rust, when even incremental builds take so long that it throws you out of "flow".

But anyway, I think this sort of working style doesn't have to do with a language's type system, but is a personal choice and one isn't necessarily better than the other, but certain personalities might be attracted to certain language communities, and thus directly influence priorities (e.g. a large part of the 'modern C++' community seems to think that compilation time and good runtime performance in debug builds are not high priorities, which from my point-of-view is entirely irrational).

I am in a completely different environment than you, but for desktop dev, I need to recompile constantly to verify alignment of usercontrols and such.

So, for my workflow relatively fast compile times are mandatory.

(Altough, I really wanna get out of desktop dev.)

I have seen few, often genius programmers do that. but not everyone can have a mental map of the code like that. we just need to run and fix part by part.. may be it's matter of practice, but that's the way several programmers workflows are.

> I keep reading in Rust surveys that Rustaceans just don't care that much about compile times enough to prioritize improving them.

Confusing since this is, to my knowledge, a top 3 issue just about every year.

That said, I think Rust programmers dislike compromise (maybe to a fault). Rust is naturally a 'have your cake and eat it to' language and the community very much likes to be best-in-class, so compromises on runtime performance to improve compile time (which is one way you can go today) are often not seen as viable by a large part of the community.

For what it's worth, I think I've called out compile times as probably one of my top issues with Rust, working on a fairly large and quite dependency heavy codebase. It isn't a deal breaker for me by any means, but it's a pain.

>compromises on runtime performance to improve compile time (which is one way you can go today) are often not seen as viable by a large part of the community.

Typically this tension would be resolved with o-level flags (O1, O2, O3...).

Rust has those, though most people interact with them through cargo (with --release corresponding to O3 and not passing it to O0.)

Sometimes, non-release builds are too slow to meaningfully run. It is not uncommon for release builds to be extremely faster than debug builds.

Might we get an -O2?

It exists as well, and if you want to use it, it's a short "throw the option in your cargo config and call it a day."

That being said, I'm not aware of it making any meaningful difference.

I think the tricks are more like "use dynamic dispatch instead of static dispatch".

O1 vs O3 is probably a fair way to do things. Some people will do that for debug builds, to get a mix of reasonable performance (for tests) and reasonable compile times. I'm not sure how meaningful the difference is going to be between O2 and O3, it's been a long time since I'd looked into it, and back then O3 wasn't really a thing people did.

> I'm the kind of guy that likes to re-run his code continually to see if it validates to what I expect it to be doing.

I used to be the same way, but the more I practiced holding the state in my head while I worked, the better I got at it.

> One group loves fast compile times and quickly validating hypotheses.

You just don't need it. As you make changes, the delta between expected behavior and actual behavior continues to grow. You begin to develop an intuition for what kind of things might not work as expected, and you can conceptually model around those things and continue to build your logic and make your changes.

An IDE helps immensely with type error minutiae. I'm using CLion and it's pretty great. For the few cases it can't figure out the types for you, you can run "cargo check".

I'm confident that Rust has made me a better engineer. I don't need to continually save and evaluate and I can do deeper work with more uninterrupted flow.

Give it a try! I think you'll start to acclimate.

Edit: Why the downvotes? I stated my personal experience as it relates to OP's observations. I improved in how I approach problems after exposure to Rust.

>I used to be the same way, but the more I practiced holding the state in my head while I worked, the better I got at it.

Doesn't that partially defeat the point of having a powerful compiler? The more work the compiler does, the less we have to keep track of in our head (and conversely, much of the pain of coding in a language like Python is the amount of stuff we need to mentally keep track of).

The compiler makes sure we're not making mistakes, and it keeps the code safe from humans.

I think this is somewhat orthogonal.

> The more work the compiler does, the less we have to keep track of in our head

There’s two sides to this: on the one hand, you don’t have to keep as much info in your head because the compiler will tell you if you ask it. On the other hand, when you do try to keep state in your head, the compiler is able to double-check that for you so that you don’t have to do it perfectly.

With a language like Python, you’re working without a safety net, so you make small, cautious, steps in order to not fall. A strongly-typed language like Rust enables you to make larger, bolder, changes in one go, confident that the little mistakes will get caught.

In a modern, well-supported programming language's arsenal, there are many tools that work to take some of the pains of coding away. The compiler is but one of them.

Unexpected behaviour and errors can be caught by means other than constant recompilation, and tools exists to do just that. In IDEs, these tools tend to become invisible, seamless, and can be relied upon without much configuration; for those accustomed to less integrated environments, the manual configuration required to get these tools up and running becomes a hassle.

I suppose using those tools efficiently and constant recompiling are different ways to solve the same problem, but I wouldn't say it's solely the compiler's job even in the latter case. For languages that aren't super-fast for compiling like Rust, Swift, etc. there may be much more reliance on those other tools.

I've always wondered if the difference is the quality of work that we do. For instance, I do a lot of graphical/games stuff, and there's no resolution in my head high enough to know that 200 pixels to the right is too far (or not) without recompiling the app and actually looking at it. Or if that shade of blue is the right one.

Still, I appreciate your optimism. I'll give it a shot! Especially for things that aren't graphical.

I think the difference is that you're using the language as a prototyping/design language: there, shortening the feedback loop is absolutely critical. There are lots of things that are not prototyping though - when I touch a graphical project I typically am working from a diagram that specifies all the color values and has a layout labeled with dimensions.

For a contrast, I don't notice compile times at all in just about any language for the most part: when you reach the "few million lines of code" size, there's no language that is going to be instant; and for embedded/systems work, committing a change can involve things like creating builds for N different architectures and running a test suite that may have to control hardware [run times of the test suite are measured in hours to days]. At this scale, anything that the compiler catches, even if it takes an hour to compile, saves an order of magnitude more time later in the process.

It's legitimately a hard problem to design a language that works well for both projects in the few tens of thousands of lines of code size -- i.e. tossing together a quick prototype -- and scales to millions of lines of code or larger.

> I've always wondered if the difference is the quality of work that we do. For instance, I do a lot of graphical/games stuff, and there's no resolution in my head high enough to know that 200 pixels to the right is too far (or not) without recompiling the app and actually looking at it. Or if that shade of blue is the right one.

I get that there're some differences in the games domain, but I don't quite get your examples, because changing the position or color of objects seems like a data and not a code change. If you have these properties as data you might be even able to change them on the fly, in the running game, which will increase your iteration times quite a bit more than any faster compile times.

Using Rust heavily for ~4 years here. I usually compile a few times a day, so while I do hear people talk about compile times a lot, it's just never really been a problem for me. I'll often write hundreds of lines of code, and sometimes build the "outline" of a whole app or library, before compiling. I haven't developed that workflow in response to slow compile times, it just feels natural to me.

People seem desperate for one language to rule them all. If you don't need a binary, blazing fast multi-threaded speed, and memory safety then you probably don't need Rust. "Need" being the big thing here. Do you need these things or are they just nice to haves in your head. A scripting language and a web browser can solve a surprising amount of application requirements these days, and its only getting better with time.

Yes, you need memory safety, everyone needs memory safety.

And if you can write program in very fast language, why not? There doesn’t have to be need. Just no reason not to

If you can afford a garbage collector, then you can also just use something like Haskell or OCaml or Python, which also gets you memory safety. No need to think about lifetimes or different types of smart pointers. Not saying that it’s a lot of mental overhead, but it’s definitely a trade-off.

Agreed. I am not saying that rust is best for everything. I think, that languages are just tools, and you should use the best tool for the job, there should not be fanboyism in this. The bigger your toolbox the better.

I just don't agree with statements about memory safety and speed. The thing is much more complex. I think simply stating "Use the best tool for the job" is much better than showing bad examples.

Because everybody needs memory safety and wants speed. Nobody wants to write unsafe slow programs (Well, I HOPE). Nobody wants to drops either of those requirements. When you drop those requirements, it's because of tradeoffs (I think memory safety shouldn't ever be dropped, yes use GC lang if you want to, but in 2020 memory safety should be a very hard requirement)

Well, I like an instantaneous edit-compile loop too, bit I was never bothered by rust compile times.

Once you get your cache warm, it's pretty much instant. If not, run `cargo check` instead of `cargo run`. You can also use rust-analyser for an in-editor <1s feedback loop.

Copying this from someone else I replied to: No, it's an issue for warm caches as well. I had a 10 second compilation cycle to add a comment to a file in a project with a couple hundred lines of code and like 4 lines in my cargo.toml. 10 seconds! For a few hundred lines! Maybe that doesn't sound insane, but extrapolating out, that's at least 100x worse than the languages that I'm used to.

If you were using `cargo run` or `cargo build` instead of `cargo check`, these 10 seconds could be spent in linking the final binary and not running the compiler frontend. for that matter 10 secs is not unheard of for large libraries with a lot of debug symbols.

That's why you should use `cargo check` instead : it will only run the rust compiler frontend, but not the LLVM linker.

Cargo check does not help with what the parent is talking about, which is a edit-compile-run loop.

Static checking is just a part of correctness verification (pretty large chunk but not enough).

It can't catch many logic bugs, eg forgetting to update a variable's value. The type system can't help without non-straightforward techniques, and at that point it is diminishing returns.

A powerful type system shouldn't be an excuse for not being able to iterate fast.

Disclaimer: I’m only a casual Rust user.

> One group loves fast compile times and quickly validating hypotheses

In Rust, it’s sufficient to type check (if it type/borrow checks, it will probably work) and Rust can type check in real time via rust-analyzer. This is much faster feedback than running your program or even its tests.

Of course, Rust’s type/borrow checker is also choosier than many others, and you still spend more time fighting with errors that don’t actually improve your code’s correctness (e.g., borrow checker errors are rarely indicative of a bug in a single-threaded context). So Rust’s iteration loop is quite fast but it’s development velocity is still relatively low (even when adjusting for quality), but it’s improving all the time.

On the other hand, I've seen a few Java applications that leaked memory (and one case of leaking file descriptors) because developers had mostly gotten away with not thinking about resource ownership. Removing data races isn't the only advantage of refusing to generate binaries when the programmer appears to need to think a bit more about ownership.

As someone who regularly uses Delphi, famous for its compile speed, I can totally see where you're coming from. Rust looks really interesting to me, but I've been holding off getting into it, because I would likely end up feeling the exact same way.

I don't use Rust (super interested in rectifying that someday though, especially to replace the ruby we use in our server) but I have the same compile time issue with bytecode on Android.

I used to be the kind of dev who compiles every tens minutes. The thing is, on Android compilation time are just getting larger and larger. Anecdotally, this is not because the tooling team is not interested in build performances, on the contrary they continuously work on it. However they are currently losing the battle : the median app complexity is growing way faster than they are improving the build times.

I mostly got used to it. I can write code for a whole day and only compile once or twice. The more I am accustomed to our ecosystem and codebase, the less I feel the need to compile frequently.

The only exception is for graphics code. The only way to know if something looks correct and good is often to compile. For that reason, while I still love writing polished animations, I dread having to compile 10 times in a row to get it just right.

`lld` is incredibly fast and allows medium crates to compile in under a few seconds for me. For people who don't know, if you're on linux put this in the `~/.cargo/config` file, and install the LLVM linker on your system.

```

[target.x86_64-unknown-linux-gnu]

rustflags = [ "-C", "link-arg=-fuse-ld=lld" ]

```

`-Clinker=clang` also works. I think you need a recent `gcc` (8 or newer) for `-fuse-ld=lld`. For `linker=clang` you probably need `clang` installed.

Permalink: https://reddit.com/r/rust/comments/dsfi5m/rust_2020_are_we_c...

While the initial compile time might be slow because of dependencies, subsequent runs are incremental and maybe take a second for me.

Why don't you try D if type-and-compile is what you enjoy?

Could someone who is familiar with Rust clarify something for me? If I am using an IDE such as IDEA's Rust plugin, and I write some function which contains a type error, do I have to compile in order for the IDE to tell me there is a type error, or can I rely on automatic type-checking like I can in e.g. Java? In other words, is Rust slow to validate code, or is simply slow to compile code into a runnable binary? If it is the former then I can totally understand why Rust would turn certain programmers away. If it is only the latter, then I find it slightly harder to understand.

> In other words, is Rust slow to validate code, or is simply slow to compile code into a runnable binary?

The latter. Validation/type checking is super quick. It might slow down a little bit if you do a lot of compile-time processing via macros, etc. IDE support is also improving a lot, and many Rust devs use an experimental component known as rust-analyzer to do the IDE-based validation you're talking about.

Something like aforementioned rust-analyzer will catch errors like that within a second of you writing it, there's no need for recompilation.

It's interesting - i very frequently recompile, running tests, etc - and i just don't have a problem with Rusts compile times. Maybe you want it more immediate than i do?

The project i'm working on now takes ~8s to compile. Perhaps too slow, but i guess it just doesn't bother me. Though i definitely want to see it improve for wider adoption, as it's clearly an issue for many people - I just have difficulty feeling the pain in this case, i guess.

edit: I imagine i compile once every 5 min of code writing. Varies by problem solving of course.

Yes 8s would me too slow for me. I'd usually set up a fullstack front+backend dev that hot reloads both parts an 8s delay interrupts flow. Compare that with 1s (or less) for Go or even Java (with a lightweight framework).

> I'm the kind of guy that likes to re-run his code continually to see if it validates to what I expect it to be doing. In Rust, this kind of workflow just doesn't work at all.

Interestingly, my case is the exact opposite. When I am coding in Typescript or Python I'm out of place, since I got used to first write the types to make sure everything is aligned, _and then_, start writing logic...

Even in Typescript this workflow is not easy to do, since its compiler is nowhere as powerful.

Can you share how long your compile times are? And what you feel is are "usable" compile times?

I see comments a lot about "this is too slow" but rarely are numbers provided, neither the actual times nor the expected times.

You may have something setup wrong and are seeing unusually long compile times. Or your expectations may not be realistic. Or you're just an outlier whos work triggers some pathological compile issues.

But without data, we can't know what's going on.

Sure. In an empty project, I saw around 0.7s compile times. This is ideal. But I kept developing and added around 300 lines of code and a few (3?) dependencies to my cargo.toml, and I was seeing compilation times that were exceeding 10 seconds to, say, add a dbg! message.

10 seconds is basically as slow as I'd accept. I wouldn't love it, but I'd suffer through it if I had to. But what I really didn't like was that my feeling was it wasn't the bottom - adding more deps or more lines of code looked like it would continue to increase the time without bounds.

I like doing a lot of game dev and graphical work, and it often requires really rapid iteration to test small changes. (How fast should the AI walk? Should he turn around at this point? Does this logic "feel right" like this, or do I need to trigger it conditionally?)

Glad I'm not alone. This frustrated me completely.

But if their use case is twice a day or similar it makes sense. Why care about compilation time at all if its seen as that rare?

Other opinions exist.

Man... I hear you, but this is only a problem compiling from a cold cache. From a warm cache, it really isn't a problem anymore.

No, it's an issue for warm caches as well. I had a 10 second compilation cycle to add a comment to a file in a project with a couple hundred lines of code and like 4 lines in my cargo.toml. 10 seconds! For a few hundred lines! Maybe that doesn't sound insane, but extrapolating out, that's at least 100x worse than the languages that I'm used to.

(I know that compilation speed is a Hard Problem, I know that I'm comparing apples to oranges, I know that Rust does fancy magic that other languages could only dream of. But everything that slow compiles buy me won't get bring me back flow state.)

If it is a project you’ve recently built, it shouldn’t matter what’s in your cargo file, since none of that will change from build to build. I wonder what’s broken. How long does it take to build a new empty project?

One think that’s helped me stay “in the flow” is switching to rust-analyzer instead of the current official RLS. Much faster, I leave format on save turned on, so `cargo check` output is usually ready in about a quarter of a second after save.

A new empty project compiles in under a second. However, adding dependencies will add some arbitrary number to this. Additionally, every hundred lines of code seems to add some amount of time between half a second and a whole second. I did some reading and read that generics are particularly expensive to compile, so I wonder if that accounts for the variance. I can't explain why cargo deps add time, though.

I LOVE rust-analyzer. It's actually what got me to reconsider Rust after I tried a year or two ago, and it is SO good.

Let me put it a stronger way: if you're seeing your cargo dependencies recompile every time, it is a bug. Please file one upstream. These bugs do happen, but they are bugs.

I don't literally see my deps compile. It's just that compile time gets slower. (I wonder if it's related to the linker?) Is that still a bug? Would be happy to report it if so.

Ahh.

I am less sure, but I would think that's expected, given that it has to link everything together into the final binary. You're gonna end up giving the linker more work to do, as you suspected.

If the slowless you're seeing is caused by the linker, which can very well be the case, consider using LLD as you can see significant speed improvements to the linking step.

https://github.com/rust-lang/rust/issues/39915#issuecomment-...

https://doc.rust-lang.org/1.22.0/unstable-book/compiler-flag...

If installed, you can run

    RUSTFLAGS="-Clink-arg=-fuse-ld=lld" cargo build --release

Looked into this :) unfortunately I run Mac so there's nothing I can do here. Tempted to dual boot Ubuntu, though.

It's a shame. I'm on the same boat and not being able to use lld adds a literal minute to my builds :-/

> I had a 10 second compilation cycle to add a comment to a file in a project with a couple hundred lines of code and like 4 lines in my cargo.toml.

Why compile again after adding a comment?

Build systems usually don't care what you added. Modification of source means rebuild.

Yes, but the programmer knows what they added, and I was asking why they wanted to build again if all they added was a comment? If this was in a CI context then 10 seconds seems unimportant; compile times of 10 seconds are usually only complained about in the context of programmers who've gotten used to tiny edit-compile-test cycles.

In order to ensure the next rebuild on an actual code change doesn't need to compile this comment-changed file, I guess.

In fast-compiling languages, it's viable to have recompile-on-file-save or even continuous recompilation. Modern (and they aren't that modern anymore) IDE's will show red squiggles under code with compilation errors without requiring any action at all.

That's already provided by other tools than the compiler like rust analyzer.

This was meant as an example, not something I'd literally do.

The most common trivial change would be to add a dbg! statement.

What? I have a ~1k LOC program which consists of 4 modules, 3 of them all importing the 4th and in total ~200 dependencies. With a warm cache my program takes ~2s to compile. Cold-cache is about 18s

Interesting! I wonder if I was hitting some pathological case with my dependency tree.

Rust compilation times as they stand today are actually worse than C++. C++ also offers flexibility to an engineer to reduce compilation times significantly via use of techniques like shared headers, etc.

"there must be two groups of engineers" -- possibly, but I'm both groups - with Go i'm in the obsessive build group, to the point that people hate pair programming with me, and with Rust I compile less, review more. I'm certainly not driven away.

About long compile time, I recommend using sccache. It saved a lot of compile time for me.

You can find how to install and use it here: https://github.com/mozilla/sccache

Is there interest in a rust interpreter? Would it be too slow to be useful?

I find that the strong type system and editor plugins like Rust Analyzer have me covered for “does this do what I expect?”, which means I do way less write-run-check than I would I say, Python.

UI code absolutely requires fast compile times, ideally hot reload, but it wouldn't hurt to have a compiler that compiles code on background and executes unit tests for it.

I hardly know Rust. What about using many small .rs files so the compilation units are quicker. For a change of one line of code only that .rs needs to be compiled.

Rust's unit of compilation isn't a file, but a crate. (this is ignoring incremental compilation, of course.)

Furthermore, most libraries make the stylistic decision of using generics and trait bounds instead of trait objects, which potentially generates faster code at the cost of slower compilation. This also has the consequence of requiring a recompilation of every dependant if that item: if you modify a root item that uses generics you will get a nice recompilation of your entire tree. Edit: working on dependency leaves though is mostly painless. If you don't work on fundamental libraries or frameworks of your system the experience becomes much better, although linking can take quite a while depending on your project.

Wouldn't a Rust interpreter solve this issue?

Does Rust have anything that prevents it from being run interpreted?

> I keep reading in Rust surveys that Rustaceans just don't care that much about compile times enough to prioritize improving them. I've often wondered how this can be possible

Well, there's a simple answer... https://xkcd.com/303/

Is this not something you can just throw more hardware at?

Other languages are able to compile much faster than Rust on the same hardware.

So while adding hardware helps (up to a point), Rust is definitely an outlier when it comes to compilation speed.

This really isn't true compared to C++. Also Rust is doing more than basically every other language, so it's provably slower.

I don't have a good idea about the compilation speeds of C++, so I don't doubt you on that point.

That's hardly the only other AOT language competing with Rust though, and while some of them are simpler on a language level (i.e. C) the compilers do a fair share of work in the optimizing stage of those simpler languages. There's also several languages that do quite a bit of heavy lifting during compilation, like Zig and Nim have extensive compile time features for example. And Nim does two passes since it compiles to C first (by default) and then that's compiled to machine code.

On balance, I don't think you can wriggle out from the fact that Rust compiles slowly compared to its competitors.

Even the Rust team admits this and are working on improving it.

If you want to use rust, and can achieve fast enough performance by simply buying some newfangled threadripper machine with a boat load of ram, what difference does it make?

The OP sounded like they wanted to use rust except for this one issue of compilation being too slow for their development style.

How fast is fast enough and is that achievable just by throwing some money at the machine?

Perfect is the enemy of good enough as they say.

> I'm the kind of guy that likes to re-run his code continually to see if it validates to what I expect it to be doing

This honestly is a bad habit. Thought it does depend quite a bit on the type of work you are doing. For some things it is necessary especially if it is inherently fibbly.

Rust is a language to which the programmer must adapt his way of working and thinking. If the programmer is too set in his way, his Rust journey will be unsuccessful. If the programmer is adaptable, he will come out in the end a better programmer, because the Rust way is actually the right way.

I think I actually went a couple of weeks once before trying out my program for the first time and there was no big deal to get it to actually work in the end.

> because the Rust way is actually the right way.

[Citation needed]

> This honestly is a bad habit.

I'd like to hear some justification for this rather than a blanket assertion. Just because our work styles differ doesn't mean that my style is necessarily wrong.

> Rust is a language to which the programmer must adapt his way of working and thinking.

I mean, Rust is actively attempting to improve compile times. It's not like devs made them intentionally long to cultivate good programming habits or something. So I'm not sure how this is relevant.

The most time wasteful part of programming is debugging. Writing slowly and thinking through your options and double checking what you wrote saves time. Especially since you are doing this while writing and you have the complete picture in your head. Obviously it does not catch everything. But one should strive to minimize detective work.

After I've been programming for an entire day I will rely on the compile to tell me when I'm wrong with an assumption. I'm honestly trying to conserve mental energy so I've learned that it's better to do it from the start and avoid keeping track of as much stuff as possible in my head. The compile tells me something's wrong somewhere and I go fix it and move on. That's not detective work, at least it doesn't feel like it to me since it's so quick.

You are talking about compiling he is talking about running. Finding issues from running results in detective work.

Turning off parts of your brain is generally not a great idea when the goal is to write code that works. A better way to conserve mental energy would be to take a break, go for a walk, or just context switch for a while.

Reply on news.ycombinator.com