For Complex Applications, Rust Is as Productive as Kotlin | Hacker News Reader

For Complex Applications, Rust Is as Productive as Kotlin

ferrous-systems.com

83 pointsquyleanh22 comments

While I really like Rust, the compiler / linker performance has ways to go still. As somebody else here said, daily productivity is hugely important -- it's not all about the virtues of the language and/or the runtime.

Ever since I started using a language server on my Emacs (plus `rust-analyzer`) my flow has improved because I can almost immediately see compiler errors or warnings but `cargo run` and `cargo build` are still slower than they should be. Seems like no matter how strong your machine is, those final steps can never go below 6-7s. (I have a fairly modern Xeon workstation)

Those 7s of delay sound funny for many and I've been made fun of for mentioning it but I'll stand behind my statement: when you're in the productive speedy flow state, you need instant feedback. If you don't have it, you lose your motivation to iterate rapidly.

Even though I believe Rust to be the future of low-level and mega-fast computing, it still has nothing on the Go and OCaml compilers/linkers, sadly. Even Elixir -- a dynamic but compiled language -- feels near-instant when you use LSP.

Hence why I use a core duo with 8 GB, SSD to test Rust compiler improvements, using a toy project I ported from C++ into Rust.

C++ version, with binary dependencies, a couple of minutes, not longer than 5.

Rust version, as if has to compile the whole world, 16 minutes currently.

My measurement is against .NET Native, D, Delphi on similar hardware.

On positive note, Cranelift just got merged, that will certainly improve compile times.

Interesting statistics. How big is the toy project? How many lines of C++ code vs Rust code?

I expect to be fairly big project.

Nope, quite a toy.

https://github.com/pjmlp/gwc-rs

About 80% of the time is spent compiling Gtk-rs, which I avoid in C++ thanks to OS package manager and pkg-config.

Also note that the original C++ Gtkmm version was already quite fast to compile in 2002 hardware, when I submitted the article to "The C/C++ Users Journal".

When cargo finally handles binary libraries, instead of stuff like scache, I expect a similar experience to C++ with binary libraries and modules.

What is your experience with D vs Rust?

D compiles quite fast, and fits my preference for systems programming languages with some of GC built in, which also provide the necessary features to go as low level as one wishes.

Unfortunately it suffers from a small community, so it is only appealing to devs that enjoy getting their hands dirty to implement missing libraries, or contribute to the existing compilers/libraries.

I keep around a reasonably midrange laptop (2nd/3rd gen i5 CPU, 8GB RAM, relatively okay SSD) to periodically test my stuff on and it has been a sanity saver on a few occasions, for the exact same reason as you. :)

Maybe it's just because I'm not regularly re-building Rust projects with enormous changes, but I very rarely experience the compile time in Rust to be an issue compared with a language like C++ or even a Jupyter notebook that's re-evaluating a cell. I usually code with a bottle of water or cup of coffee nearby, and when I hit 'enter' on the 'cargo build/run' command, I often pick up my cup and take a sip. By the time I've put the mug back down, the compilation is usually over. So I guess the quantum of time when I'm coding is a sip of coffee, and anything less than the time it takes to do that feels functionally the same to me.

Granted, first-time compilation takes a while, but once that's taken care of, I don't update my toolchain often enough for it to have a noticeable impact on my workflow. I guess if you're getting a new nightly build every day and re-compiling everything, that might be a pain, but that doesn't seem to be the root of most people's complaints.

I am only talking about the "change a line -> recompile -> run -> inspect -> change a line ..." workflow.

As mentioned in my comment above, for most people waiting a few seconds is a funny non-issue but it directly affects my motivation to rapidly iterate.

The "take a sip" brain hack might work, I'll try it. :) But I try to follow rules for proper hydration which means that you shouldn't sip water every other minute -- there have to be pauses.

It's a good advice regardless. I'll see if I can adopt a variation of it.

Seven seconds sounds like a long time. What dependencies are you using when you see this? If there's a lot of macro expansion going on that could explain some of it.

I don't have much influence on the deps just yet, I am a noob in the company's stack still. I might be able to minimize them in the future but for now we have no small amount of proc-macro libraries.

Plus, I am talking about a company-issued laptop. It's quite the fast and strong cute little thing but we all know even the strongest mobile CPUs can't measure up to desktop CPUs, especially when it comes to compilation.

There's a saying about Rust that it takes more effort to get a Rust program to compile without errors, but once it does, chances are it will work correctly. This seems counter-intuitive coming from other languages, but has been borne out by my experience. The strong typing and compiler guarantees push most run-time errors or unintended behavior to compile-time.

As a result, a lot of the iteration that happens is between me and `rust-analyzer` and `cargo check`, which, as you note, is much faster than a compilation pass with codegen and link.

That used to be a Haskell saying, and I suspect it's still more true there...

None of these articles ever come to mention compile times, which are crucial for productivity on both large and complicated projects, and those are absolutely attrocious for Rust.

Which is why I would avoid rust for anything where productivity is crucial.

> Which is why I would avoid rust for anything where productivity is crucial.

Surely we can be more nuanced than this? Compile times vary greatly between different projects and dependencies.

For everyone complaining about compile times I’d like to know how it compares to Scala.

I worked on a Scala project about 10 years ago. Compile times were atrocious.

They still are. My project is mostly Java and the scala part takes up most of the compilation. It might just be because javac isn't an optimizing compiler so it's fast (I'm not sure about scalac).

It depends on your project. As soon as you add too many dependencies to rust with lots of macros, compile times tend to increase a lot for rust projects because it creates a fat binary, whereas it works fine for a mountain of dependencies in Scala for me.

On the other hand if you just need compiler errors, cargo check runs almost instantly for incremental checks.

Interesting report. One thing possibly limiting applicability of the lesson is that applications are very regular and closed systems and free from having to adapt to arbitrary irregularities of the real world.

The title is misleading at best, utterly wrong at worst. This single biased (he's working on rust LSP and is part of ferrous system (their business model depend on rust adoption)) opinion has an insanely huge disclaimer: the productivity claim only stand for complex applications that does not depend on libraries... Large, complex app and building everything yourself is such a niche use I didn't knew it existed.

Rust-analyzer uses libraries, so I'm not sure what your point is.

Reply on news.ycombinator.com