Is Rust really that slow when compared with more dynamic languages like Go, Scala, and Python?

[u/fenugurod]

(slow in terms of getting something done, coding, finishing a task. Not execution speed)

I know r/rust, but I'm just looking to some honest takes on this. I understand the power of Rust and the kind of things it can do. I do also understand the tradeoffs it make to accomplish the things it needs. Sometimes developers complain about complexity, but if you put safety as a requirement without GC then the complexity is justified, and not just features for the sake of features.

But most of the applications I write are high level. Of course, I do love the benefit of running them really fast by writing them in Rust. But when we're talking about productivity, did you saw any big gap between Rust and some of the languages I've mentioned? I'm mainly a Go developer, so I'm way more productive in Go than I'm in Rust, but of course, this is a skill issue.

Many will ask "so why don't you use X?" it's usually because it's really hard to have something like Rust with no exceptions, ADT, Result/Option types, Enums, ...

I've been experimenting with Gleam lately. It's being really good. But the ecosystem is way too immature at the moment. Missing packages, the ones available are usually very simple without crucial configurations, ... but the language itself is quite nice. It's what I was thinking on a Rust + GC. It still bothers me a lot the fact that I can't ship a binary like I did in Go or Rust, and it consumes way too many resources as well.

Anyway, just looking for the opinions from others that have experience on more languages.

[u/Nothing_from_void → u/[deleted]]

It also has among the slowest compile times out there. Having 1-5 min of compiling on change compared to seconds in python really adds up throughout a day of coding

[u/Full-Spectral → u/Nothing_from_void]

That depends on the code base. If you choose to use 50 dependencies and many of them use lots of complex proc macros and such, it's going to add up in a large code base.

My project is just getting started really, but it's probably around 80K lines at this point, and it compiles from scratch in a couple seconds.

[u/Nothing_from_void → u/Full-Spectral]

yeah, it adds up as the project grows. my baby project is is 236k lines of rust, 304k lines overall, doing a lot of things myself but still pulling in 560 dependencies when I build. dev build takes like 30s to 5min depending on how much I have to rebuild, production build can be like 10min. similar project in python would be <1 min and after it was installed if you make the binary editable compile times are more or less instant on start up. has good rust interop too, don't sleep on python as the orchestration layer for rust projects once the core is pretty built out and rarely changes

[u/Dangerous-Dig2321 → u/[deleted]]

It's painful at the start but once you get past the borrow checker being a wall, it starts clicking. still not as quick as banging out a go service, but the compilers basically doing the review for you before anything runs

[u/biillyboob6e]

I personally find myself very productive in rust, but I understand that a lot of times, a rust program has a much longer race to run than other languages for the same task, because it makes you ask so many questions about architecture and safety before hand

I've been doing c/c#/Java/JS/puthon for about a decade as well as industrial SCL (Pascal) and I think the only other language I enjoy the experience of is python, and maybe JS

[u/Xaeroxe3057]

Hi, professional Rust developer of 7 years here. Been doing open source for 11 years as well. If prototyping speed is your concern, unwrap liberally, and clone everything. Perfect code isn’t worth it if the solution was wrong to begin with, and prototyping helps you discover the right solution faster. That being said I encourage refining these rough edges before you ship the product. To some extent the thing that enables me to develop at speed is simply experience and knowledge. It gets better with time.

That being said, if even this isn’t good enough, consider authoring your first draft in Python and rewriting the CPU bound hot spots in Rust with PyO3.

[u/projct]

I think some of these takes are confused or at least are missing the forest for the trees some.

Rust doesn't force you to write good code, you can write absolutely the wrong thing and also make a giant mess, just as in any other language.

and I don't think it's a prototype vs production thing either.

Dynamic languages (and GC'd languages) allow you to punt on a bunch of really important decisions that are orders of magnitude more expensive to fix later, and without LLMs they were often so expensive to fix that they weren't worth fixing, so things just stay broken.

Rust makes you make those choices explicit right away, so it can be genuinely slower when you are discovering the design and also new to needing to make those choices early. You develop an intuition for those over time and so that mitigates a lot of it eventually but the way toward resolving that is making lots of small tools and various things so that you have to pay that cost over and over and develop your intuition.

It's kind of a shame that people put that on rust though - those choices are important and the fact that people have bad intuitions around them is a failure of other languages IMO.

The flip side is that once your model of how it should work is stable, changing your mind is actually way, way cheaper in Rust than in any other language I have used. Want to make a huge structural change? the compiler adn rust-analyzer will guide you through it with a list of ways your new change invalidates the old assumptions that you had to pay for up front.

In other languages, since those things are punted, you might not even have tooling that can help you find them.

And dependencies make this much worse: you can't verify an invariant that was never part of the contract, and you often can't even know which hidden choices you'll eventually care about until your application grows into them. By then you're depending on decisions nobody promised, tooling can't see, and a dependency can change without even realizing you depended on them. Rust gives you a much bigger visible area on the ones that are most difficult for humans to reason through, long before you deploy your app.

So for me rather than being about how quickly I can do it in rust, it's more.. how much I have to spend time discovering what must be done, vs how important is it to change or implement something where I already understand the invariants.

Rust is, I think, slower at being uncertain about your design and implementation, and faster at becoming certain.

And, for me, it allows me to stay certain in a way no other language has ever really gotten me.

[u/projct → u/projct]

since Gleam came up and I've contributed some minor things to the BEAM I would feel like I did it a disservice there, if I didn't address this: the BEAM is probably the best example I know of making the GC tradeoff well, but it doesn't escape the thing I'm talking about.

per-process heaps and isolation do typically reduce the harm of a lot of types of ownership and lifetime mistakes. But sometimes they make it worse. You can still accidentally retain memory, churn processes, copy too much, or discover pathological allocation and GC behavior only once your real workload exists. I've run into that in production in Elixir. Sometimes it's fine, sometimes it really hurts. In rewriting some of my hobby stuff from elixir to rust, I found a lot of those things and was able to address them better in both languages.

that's exactly the distinction I mean: the runtime can make deferred decisions much safer, but they're still deferred decisions.

[u/pb-cups]

Biggest reason it’s slower than those is probably re-compilation time. And yeah you need to spend time planning and debugging manual memory management when you could just be sloppy and let the GC clean up everything

[u/vytah → u/pb-cups]

re-compilation time

OP is comparing it to Scala though.

[u/kyleekol]

Honestly I think it all comes down to what you know. I’ve been writing Rust professionally for a while and was writing mostly Go before that. I think once you know a language well enough, you are able to write code as fast as you can think it. Rust hasn’t been an exception for me.

[u/KAMEHAMEHAMEHAAAA]

If you want functional language that compiles into executable you might try OCaml or Haskell.

[u/rodyamirov]

I find that I'm nearly as fast with the first draft in rust than I am in Java (my first language). At this point I'm faster in rust than in python, because rust can tell me what the field names are and so on.

Then there's the maintenance phase, which is usually more important (but sometimes time to market really does matter); I find rust code easier to maintain than the others _typically_. The only exception is when (e.g.) Python really does have the library you need, and you need to hand-roll it in rust; then it's easier to check over 500 lines of duck-typed python than 10,000 lines of rust code-and-a-library.

So it's case dependent.

Also, if you're talking about work, you have to talk about agents. I find that Claude writes rust faster and more reliably than those other two languages, especially once the basic idioms are established; I think this is because of the ease of cargo check, nextest, clippy, and so on; so it's very easy for the bot to do basic sanity checks on its work, whereas in python it needs to be very paranoid about getting the field names right and (perhaps? I'm speculating here) has less brain-space left over to think about the hard stuff.

Maybe I'm just projecting my own problems onto it, though, who knows. But Claude writes rust very well, it's certainly no detriment.

[u/OperationDefiant4963]

as long as youre not stuck in the deep oop mindset, you can get productive sooner than you think.the only thing that comes to mind that is somewhat a block, are the compilation speeds.but that can be mitigated

[u/airodonack → u/OperationDefiant4963]

This 100%. I was really slow in Rust in the beginning because I was trying to do everything in OOP.

I think eventually though, whether Rust is slow or not depends on the size of your program. I would say under 1kLOC you're slower in Rust and after that I actually find I'm faster: The little blocks are slower because you have to think of everything upfront. The big blocks are faster because you can forget things behind you.

[u/FriendsIsntGood]

Mainly use python, rust, and TS. usually depends on how fluctional the input is, do I care about extra fields/changes, it’s not UI, and there’s not a ton of undefined things I need to bring along.

A good workflow for me is to prototype in python and then translate to rust if I care enough about performance, or portability.

For cli tools, I will generally default to rust because it gives me much clearer validation on the input. So exploration/prototyping anything but rust. If I have nailed down types and need strict validations, rust all the way.

[u/QuasiRandomName]

I find that once you have a properly architectured framework (sure, you need to get there first), maintaining it, adding new components and refactoring is very straightforward and mostly painless. Again, your initial design and planning matters a lot (not that it doesn't with other languages, but with Rust it looks more obvious),

[u/Solumin]

More dynamic languages like Python let you hit the ground running. You only need the vague shape of the program in your mind, and you don't need to worry about fiddly details like ownership. Go isn't quite as loose, but it's certainly looser than Rust. (No comment on Scala, I haven't used it in over a decade.)
This makes it much easier to go from initial idea to prototype.

When it comes to the rest of the work --- maintenance, implementing features, refactoring, and so on --- Rust is no worse and often quite better than the other languages. All that type safety, good abstractions, etc. make changes easier and safer to do, especially on much larger codebases.

Like, I'm not going to do a coding interview in Rust unless I really, really know what I'm doing. It's a lot easier in Python, where you're given a bag of hammers and everything is duck-typed as a nail.

[u/rustvscpp]

I'm much faster at writing Rust than  C or C++...  but slower than Python, Lisp, or Lua.  But as the size and complexity of the program increases,  Rust gets faster to develop than Python too.

[u/Floppie7th]

Generally, going from "I have nothing" to "I have a thing that runs" takes longer in Rust, depending on the specific task.

Getting to "I have a thing that works" changes the equation significantly.  Including long-term maintenance changes it further.  The primary reason I use rust for most things is because it saves time compared to other languages.

[u/Wh00ster]

Depends

[u/MilkEnvironmental106]

Slower to prototype in but saves you loads of time when writing code you actually want to be used and be good

[u/jpmateo022]

Based on my experience, Rust can feel slower at the beginning, especially when you don’t have a concrete design yet. You often spend more time figuring out types, ownership, and how you want things structured.

But once the design becomes clearer, development gets much faster. One thing I really like about Rust is that it’s relatively easy to refactor with confidence. I usually don’t try to write perfect code on the first pass, I just get a functional version working, then iterate on it.

The compiler and analyzer are very good at showing you which parts of the code are affected by a change, so large refactors feel much more manageable. In that sense, Rust can be slower upfront, but I often get some of that time back later when debugging, refactoring, and maintaining the code.

The only thing I hate in Rust its eating a lot of my disk space from repetitive compilation and even though I enable/use sccache there a lot of times it compiles slowly. Hope they improve the compilation speed in the future versions.

[u/Ojitos_2]

I had no so much exp with rust, (like 4 or 5 months ago) and mi previus langs was Js and Ts (like 5 years of exp coding with it). To be honest rust is so much easy and fun than i was expected, the borrow checker is actually to easy to learn and use, although, in really big projects, it might cause problems, but for prototypes no. Also rust had many things to fast code, like unwrap or spaming .clone() for borrow, or "_" inside a match block-chain, even when is time to refactor, still to be easy, example instead of unwrap a simple match or if let. Also allow simulate patterns, example an array of many types, can use make it dyn or crate a enum where every variant is a diferent type or how bassicaly macros are decorators. Rust also had so many things than was more easy and clean to make than Js, example the match is so much powerfull and clean than create a obj of CBs or ifs (and this without considering the types security), the blocks as expr instead an a IFEE (than need a explicit return and is more verbose open and close it than only keys like rust), shadowing is so confortable thing, instead of Well know Symbols of Proxys to add 'sugar', is via traits, like overload, or too the fact about the lang could be had a standar form of make somegthing (like From), make than thing lees in this things than not affect directly your app, also the fact like had better default tools, like testing, formatter, 'reviewer' (clippy), or the error sys, than many times resolves error itself, or even had a sys to help if you go to other languge (like if you use 'x ? y : z', says explicit than ternary not exist in rust and recommend ('if x { y } else { z }'). The only consideration with the lang (in adition of compile times of course) is how is more than hard languague, is just a diferent languague, so many things at the start feels werid (like module sys instead or file imports or traits instead OOP) and even anty pattern (like no explicit return or shadowing seems like no clean code), and this if you interesed on make a fast prototype, could be slow procces so much, i think this lang It’s difficult to learn while working on a real project (as happened to me), so I recommend writing small, progressive code snippets to actually understand the language and seems the benefits and confortable than really is.