5 ms·

For Complex Applications, Rust Is as Productive as Kotlin

83 points by quyleanh 6y ago

The_rationalist 6y ago
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.
- TheGoddessInari 6y ago
  Rust-analyzer uses libraries, so I'm not sure what your point is.
fulafel 6y ago
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.
Johanx64 6y ago
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.
- rsa25519 6y ago
  > 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.
pdimitar 6y ago
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.
- pjmlp 6y ago
  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.
  - avrionov 6y ago
    Interesting statistics. How big is the toy project? How many lines of C++ code vs Rust code? I expect to be fairly big project.
    - pjmlp 6y ago
      Nope, quite a toy. https://github.com/pjmlp/gwc-rs 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.
zcw100 6y ago
For everyone complaining about compile times I’d like to know how it compares to Scala.
- icedchai 6y ago
  I worked on a Scala project about 10 years ago. Compile times were atrocious.
  - vips7L 6y ago
    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).
- MHard 6y ago
  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.

83 points by quyleanh 6y ago

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.

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

fulafel 6y ago

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.

Johanx64 6y ago

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.

rsa25519 6y ago
> 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.

pdimitar 6y ago

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.

pjmlp 6y ago
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.
- avrionov 6y ago
  Interesting statistics. How big is the toy project? How many lines of C++ code vs Rust code? I expect to be fairly big project.
  - pjmlp 6y ago
    Nope, quite a toy. https://github.com/pjmlp/gwc-rs 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.

zcw100 6y ago

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

icedchai 6y ago
I worked on a Scala project about 10 years ago. Compile times were atrocious.
- vips7L 6y ago
  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).
MHard 6y ago
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.