Ask HN: Going All-In on Rust
9 comments
I worked fulltime in Python (Deep Learning and web services for around 10 years) and used Go for some projects in past.
I recently introduced Rust as a language for some server side logic and desktop app. Some observations:
1. Rust coding takes time. Something you would write in an hour in Python would take a day in Rust.
2. Rust code is almost always faster.
3. Rust almost will never cause an exception in production if you are not just doing unwraps and expects everywhere. This sometimes feels a lot of work while coding. In python, I almost always end up solving some production exceptions despite of writing tests. Not a fault with Python btw, you could always write better tests.
4. Writing Python is more enjoyable. However, you know you will never be able to write stuff in Python that you can in Rust. I think of Rust as a good compromise for a Python programmer to write low level code without learning C++. Being productive in C++ will take years, being productive in Rust takes a few months. Rust is like C++ but written with high level language features.
5. There are other fast languages which would be better for a Python developer like Nim, but they have no library ecosystem. Rust has almost got a good library for everything I need it for (just like Python).
Thanks for a detailed summary. This was really helpful.
Why make the transition so dramatic? Write one project in Rust, see how it feels. How much did you learn, from which challenges? Complete a competition with your solution in Rust. How was your performance, what benefits did the language offer in your solution? I think if you tackle those two things you can answer your question about the rest of your work better than any HN comment.
Maybe I was hoping to find someone who has already made such a transition.
What kind of competitive coding ? If it's the kind where the first to code a working solution to a relatively small problem wins I don't think I would choose Rust for that.
Mostly around time + space optimization rather than being first.
In the case of the problems I've done that were like that what mattered was finding an asymptotically efficient algorithm. For example there might be a fairly obvious exponential time algorithm but it won't meet the execution time constraints, so you need to find a much less obvious linear or quadratic time algorithm. For problems like that constant factors (like Rust being 2-5x faster than Python) typically wouldn't matter.
For that type of problem: ie. it's more finding the algorithm than the code itself that matters, the solution will probably be less than 1000 lines of code and there's only one person working on it, I think it's hard to beat Python. Worrying about static typing let alone memory management will probably only slow you down and maybe even interfere with the thought processes needed to find the right algorithm.
I say that despite actually not liking Python very much and this advice is the exact opposite of what I would give someone looking for a language to use on a large code base that needs to be maintained over time by multiple developers.
For that type of problem: ie. it's more finding the algorithm than the code itself that matters, the solution will probably be less than 1000 lines of code and there's only one person working on it, I think it's hard to beat Python. Worrying about static typing let alone memory management will probably only slow you down and maybe even interfere with the thought processes needed to find the right algorithm.
I say that despite actually not liking Python very much and this advice is the exact opposite of what I would give someone looking for a language to use on a large code base that needs to be maintained over time by multiple developers.
for what you describe i would actually pick common lisp (sbcl). you can get c-like speed. plus there is a good new book on algorithms and ds using common lisp
https://www.amazon.com/Programming-Algorithms-Lisp-Efficient...
https://www.amazon.com/Programming-Algorithms-Lisp-Efficient...
Thank you. This is a very helpful suggestion.
Read the whole book, cover yo cover. That’s about it.
I adopted rust a while back and have since ported basically everything to it, even at work. It’s my new best friend, for sure.
The best advice is just to keep going.
I adopted rust a while back and have since ported basically everything to it, even at work. It’s my new best friend, for sure.
The best advice is just to keep going.
I have a feeling writing something in Rust takes whole day, while writing same code in Python is less than 1 hour.
Keep in mind reasons why you want to move away from Java/Python.
Perhaps there is a different language that can fit the bill.
Perhaps there is a different language that can fit the bill.
Work. You want to check you can be employed with it if you go all-in.
I am skeptical of job opportunities for Rust in my country. However, I get a sense the language appeals to a specific audience (and company), and most of the companies here are only building SaaS applications so it might not benefit them to transition their codebase.
if you want to learn low level programming learn C and C++
I am looking to transition to Rust for all my side projects (and possibly everywhere in the near future). I don't have any specific reason for this transition other than to move away from Java / Python.
I want to continue my competitive coding practice and my side projects that are mostly low-level systems. I am looking to build a niche for myself and see Rust as an escape (something I can explore and grow with). I might be overplaying my hand here, any suggestions would be helpful.
Is there anything to keep in mind before I take this plunge?