Comment

Comment on is Rust really that powerful / intuitive?

With familiarity, can Rust’s intuitiveness match Python’s “from idea to deployment” speed?

Likely not at the start. Rust can take some time to learn to use it effectively it is not the fastest at throwing shit together quickly.

Or should I only learn Rust if I intend to create applications that need tight performance?

Also no. IMO rusts performance is only a nice by product of the language, yeah it encourages people to try it out, but they don’t stay for the speed. They stay for the tooling and the feeling that once it compiles it will likely just work they way you intended. Rust forces you to think more about correctness and edge cases of your code - which does slow down initial idea to working prototype a bit. But IMO it quickly pays back dividends when you get something into production and it just works with no random crashing in the middle of the night.

It also makes refactoring a joy to do, where I hate refactoring in languages like python as you never know what you might have broken - likely something that you will find out only after you have deployed to production. Instead the compiler catches basically every thing that you missed before it will even let you run the code - so those edge cases are taken care of when you are developing, not after it fails in production.

I also find it is very nice with data processing/transformation as it lets you use functional coding styles which tend to lean towards clearer/easier to read series of data transforms.

If you want to learn it I would recomend starting out with the offical book, but you might also find zero to production or datawithrust interesting reads as well.

source

Sort:hotnew top

TehPers@beehaw.org ⁨1⁩ ⁨year⁩ ago

Likely not at the start.

To add, Python lets you make a new file, write up a quick script, and start running it. You even have a REPL environment prepared for you to start throwing code at and see what happens. Rust is nothing like this (though some “script runners” exist for Rust). You’ll usually end up creating a new folder, creating a Cargo.toml, then a src directory and a main.rs file. Now you can start writing code, but the Python developer has already ran their code a few times and iterated on it a little.

For experienced users, development speed in Rust starts to pick up after the initial project setup and once the basic “boilerplate” (this depends per domain, could be arg parsing, reading a config file, setting up telemetry, etc) for their specific application type has been created, in my experience. For quickly throwing together a small script, a developer equivalently experienced in Python and Rust will likely find Python faster to use, but when looking at mid to large sized codebases, that could flip due to how strict Rust is and how that prevents problems over the long term.

source
- 5C5C5C@programming.dev ⁨1⁩ ⁨year⁩ ago
  It only took me ~2 weeks of playing with Rust before it became my scripting language of choice over Python (which I had been using casually for ~5 years by that point).
  
  The initial setup for Rust can be whipped up with $ cargo init. You’re right that there’s more setup boilerplate because of the mandatory Cargo.toml and directory structure, but cargo init will provide all that in a snap.
  
  As for the domain specific boilerplate, I actually find that Rust is better at that than Python in almost all cases. I feel that Rust’s clap is much simpler, more reliable, and less boilerplate than Python’s argparse. Python might win in cases where there’s a very mature domain specific package that you need which isn’t available in the Rust ecosystem, but that’s becoming rare as crates.io grows.
  
  And then when it comes to the actual “scripting”, very often my IDE’s intellisense can practically fill in the Rust code for me. One keystroke per word and it knows what function I want, or I can quickly scroll through the recommendations until I find what I’m looking for. Meanwhile with Python I always have to consult docs to find any API that isn’t part of the basic standard library. As a result I’ll often get the scripting done faster in Rust than in Python.
  
  It does absolutely take some time to reach that point, though. Most programmers will definitely feel significant discomfort with Rust initially, but that’s just because you need to deprogram your brain from the bad habits that other languages encourage. There’s a tipping point in that deprogramming where all the other languages start to feel uncomfortable because you know it won’t let you write as good quality of code as Rust would.
  
  source
  - Sigmatics@lemmy.ca ⁨1⁩ ⁨year⁩ ago
    I can’t confirm the point about autocompletion with Python. When using strictly typed Python (mypy), the suggestions are just as good
    
    source
    5C5C5C@programming.dev ⁨1⁩ ⁨year⁩ ago
    Using visual studio code this only happens if the library has thorough type annotation. While that’s becoming more popular, it’s not enforced at the language level so lots of libraries have enormous gaps in the autocomplete.
    
    source
    -> View More Comments
- nous@programming.dev ⁨1⁩ ⁨year⁩ ago
  
  For quickly throwing together a small script, a developer equivalently experienced in Python and Rust will likely find Python faster to use
  
  I am not sure about that. I have written a few scripts in rust that I managed to do quite quickly. Once you have a project similar to what you have done before setup time is not that long and the more examples of things you have done before lets you get going quite quickly - this is true of any language really. The slowest part I tend to find is learning the libraries you need to use for a given script or doing something you have not quite done before. Which I think in rust it can take a bit longer for these parts - but once you have overcome that hurdle similar scripts are easier to write in the future. Python might win out if you constantly need to write things from scratch with no past examples and always needing to use new unfamiliar libraries. But I find that is not often the case and over time becomes less and less the case.
  
  And for those cases where you can just adapt something you have written before rusts very easy refactoring actually adds a lot of value and helps to speed things up quite a bit.
  
  source
- thisisnotgoingwell@programming.dev ⁨1⁩ ⁨year⁩ ago
  yes, I’ve seen how mangled python code can be, some of the code that our automation team uses barely makes use of functions or classes, which has made working on other people’s python code a nightmare. There’s one application that is thousands of lines long that I’m pretty sure I could condense into a few hundred lines.
  
  Perhaps that’s a drawback of people who use python, they are not typically focused on the scalability of their code until it is actually used in prod. I believe for this reason, I would prefer a language that is compiled.
  
  Last question, is using Rust on Windows as difficult as it seems at face value? It looked like to me that for using rust, it’s preferable to use linux or mac, as they don’t require you to install a compiler. For some reason, my org requires me to submit an exception for being able to install rust on my work computer. Is there anything that is inherently risky about using Rust, or is it because once the code is compiled, it cannot be reverse engineered?
  
  source
  - nous@programming.dev ⁨1⁩ ⁨year⁩ ago
    I don’t think it is any more risky than using python. All crates are compiled from source locally, nothing is run when you download a crate. So there is an option to inspect things before you run them (but lets face it - almost no one does this in rust or python or any other language). I would guess that the issue you work has is simply that rust is new to them and they are wary of anything that is new.
    
    source
thisisnotgoingwell@programming.dev ⁨1⁩ ⁨year⁩ ago
wow, great response. thank you. I’ll give it a shot!

source