6 ms·

I started my first Rust project a month ago after working for years in Golang and before that Python (and before that Perl, C/C++ and Turbo Pascal). I really li

I started my first Rust project a month ago after working for years in Golang and before that Python (and before that Perl, C/C++ and Turbo Pascal). I really like the whole experience but I'm not sure if I'd recommend writing all your backend code in Rust as a startup. Rust definitely provides a pleasant experience and is very powerful. If you can stick to the standard library I think Rust is great, though the package ecosystem is still lacking in many respects and most packages seem immature and quite limited. So if you plan to build something that has sizeable external dependencies plan some time to either write that yourself or to spend a lot of time debugging and vetting external packages, many of which are maintained as side projects by single developers. Documentation often also seems to be subpar as compared to e.g. Python. I suppose that's due to the auto-generation of documentation which seems to lead to people mostly writing what I'd refer to as API documentation with very few tutorials. So is Rust worth it for a startup? Not so sure. I recently picked up Python again to write a simple REST API, and the process is just so much faster and (for me) enjoyable because of the "ad hocness" of the language and of course the great existing tooling around it (I still have to find an ORM as powerful as SQLAlchemy in Rust or Golang). And let's be honest it's also possible to write great scalable services in Python (or Ruby, or Javascript), as many scaleups still use these technologies. Onboarding of developers might be another issue: Yeah, everyone wants to be a Rust programmer, but for people that have little experience with systems programming the learning curve is quite steep, so you'll limit your candidate pool quite a bit and will need more time for hiring.

drogus 4y ago
> I recently picked up Python again to write a simple REST API, and the process is just so much faster For me it's much more important how will it work in the next few years, not how quickly you can write it. If I could, I would use Rust for pretty much everything just because I don't like getting paged in the middle of the night.
- mikevm 4y ago
  I agree. This typing velocity argument is really weak. It may be faster to start, but talk to me once the project reaches 10K+ lines of code and we'll see how you fare with your scripting language.
- ThePhysicist 4y ago
  I have both Python and Golang web services in production for years, none of them cause much headache. I'm not running a hyperscale startup though and server hosting is the smallest cost factor for running my products, so I don't worry about performance that much. Most workloads are IO-bound (database queries) in any case, so Python isn't too much at a disadvantage over Golang or Rust there. In terms of stability I never had any major issue with Python services, and when minor issues occured the logging and tracebacks were so good that it was easy to isolate and fix the problem (the same is also true for Golang). I guess the older you become the less you care about specific tools or languages, for me it's mostly the general architecture and operating principles of the software that determines if a system will be brittle or not.
- igouy 4y ago
  > … how will it work in the next few years… If we were talking about code, wouldn't that look a lot like premature optimization? Build one, throw it away…
mikevm 4y ago
I wouldn't touch Python with 10-foot pole for any serious project. People who're used to dynamic languages (e.g., JavaScript) are now starting to see how indispensable static typing is when they try out TypeScript and then never want to go back.
- ThePhysicist 4y ago
  I also write Python with type annotations and the type checker keeps getting better and better, though I find it's often not strictly necessary, at least for small projects. The most important thing is to keep the code simple to understand and follow, then you can write great software in dynamically typed languages as well. Also have Typescript experience but in general I'm not a big fan of gradually typed programming languages, static typing works best in languages that were designed for it from the ground up and that offer an expressive type system, e.g. C++ or Rust.
deepstack 4y ago
Deno could be a good alternative. It should hit GA 3 QT this year.
- 0des 4y ago
  I would not choose Deno for that considering how little there is for it currently and how much of what there is available that is plastered with all caps warnings to not use it in production.
mritchie712 4y ago
Two things I consider: 1. what languages does the team already know best? 2. are any languages dominant in the problem space? for us, I've used Python over 10 years and Python is the leader in data science / analytics. Some things might be a little faster if we used Rust, but compute is cheap. Go with what you know.
- pizza234 4y ago
  I agree that one doesn't necessarily need a fast language, but I think that the "hardware is cheap" idea is very misleading. Renting/owning 5x as much servers may be cheap, but maintaining them isn't.
  - mritchie712 4y ago
    check out https://cloud.google.com/run https://cloud.google.com/run. I've never had issues 5x-ing compute on it. All the other services that compute hits (e.g. Postgres) are a different story, but that doesn't really matter when picking a language.
- retcon 4y ago
  1 may be better asked as what aspects of your team understanding of any considered language apply to your problem space. How well can you port that knowledge to another model of expression. 2 is fine. the more significant question is often do you want to work with that talent pool and does the pool tell you more about the costs structure of your sector against which information you may prefer to tack against the prevailing winds and even more patiently attempt to trade actual equity for deep abilities and stuff what language is chosen if your stock has value. I don't understand how much attention individual languages receive. Plural understanding across your team and ability to transcribe the code into valid parseable docs against which APIs are easily written, is paramount in my mind. Corollary to my incredulity I have often thought that you emphasize the codebase language and dialects only to find you fuelled holy wars and dissipated your technical mission values. Which is disastrous for hiring the kind of colleagues we get up in the morning and forget about industry grief to share increasingly awful spaces with.
- 4y ago
throwaway0x7E6 4y ago
>Yeah, everyone wants to be a Rust programmer I understand why you might have got that impression, but that's a far cry from the reality
- amelius 4y ago
  It really puzzles me why smart people want to spend their time satisfying the borrow checker rather than inventing new and useful things.
  - sebzim4500 4y ago
    I don't remember the 'satisfying the borrow checker' phase lasting more than a few weeks. Once you internalize the rules the borrow checker gets out of your way and it's more of a sanity check. I think part of the issue is that it wasn't very well explained in the book at the time I started learning rust. This might have improved since.
    - amelius 4y ago
      The entire way of coding in Rust revolves around satisfying the borrow checker. At some point it may become second nature, but you are still jumping through Rust's hoops, which will make your code full of compromises that would otherwise not exist.
      - unrealhoang 4y ago
        So does the entire way of coding in any static-typed language, your code is full of compromises that would otherwise not exist in a dynamic-type language. Rust is just another layer of static typing.
        amelius 4y ago
        Yes. It's another level of the same problem. Rust is like a piano where certain keys have been removed so you never play out of key.
m_a_g 4y ago
I would like to add that async Rust still doesn't really work. That is a big negative for Rust.
- staticassertion 4y ago
  It definitely works just fine
  - m_a_g 4y ago
    You can find great examples of Rust async programming being "a disaster and a mess". You still can consider it is working just fine, but I disagree.
    - staticassertion 4y ago
      I don't really need to find those examples, I've written most of my company's product in Rust using async, for years, and it's never once been an issue. That's 100s of thousands of lines of rust written and 0 async issues.
      - clpm4j 4y ago
        Totally valid, but you could also say the same thing about C and C++, i.e. you can wield your tool with mastery, then that's awesome. But I think the average startup would likely struggle needlessly when they really just need to ship products that people want/need to use. Rust is likely not the smartest choice for the average startup.
        staticassertion 4y ago
        Only one person at the company had previous professional experience with Rust. The majority had 0 experience with it at all. We've had no trouble and it's actually been our most productive language - we're moving away from Python and Typescript where possible.

drogus 4y ago

> I recently picked up Python again to write a simple REST API, and the process is just so much faster For me it's much more important how will it work in the next few years, not how quickly you can write it. If I could, I would use Rust for pretty much everything just because I don't like getting paged in the middle of the night.

mikevm 4y ago
I agree. This typing velocity argument is really weak. It may be faster to start, but talk to me once the project reaches 10K+ lines of code and we'll see how you fare with your scripting language.
ThePhysicist 4y ago
I have both Python and Golang web services in production for years, none of them cause much headache. I'm not running a hyperscale startup though and server hosting is the smallest cost factor for running my products, so I don't worry about performance that much. Most workloads are IO-bound (database queries) in any case, so Python isn't too much at a disadvantage over Golang or Rust there. In terms of stability I never had any major issue with Python services, and when minor issues occured the logging and tracebacks were so good that it was easy to isolate and fix the problem (the same is also true for Golang). I guess the older you become the less you care about specific tools or languages, for me it's mostly the general architecture and operating principles of the software that determines if a system will be brittle or not.
igouy 4y ago
> … how will it work in the next few years… If we were talking about code, wouldn't that look a lot like premature optimization? Build one, throw it away…

mikevm 4y ago

I wouldn't touch Python with 10-foot pole for any serious project. People who're used to dynamic languages (e.g., JavaScript) are now starting to see how indispensable static typing is when they try out TypeScript and then never want to go back.

ThePhysicist 4y ago
I also write Python with type annotations and the type checker keeps getting better and better, though I find it's often not strictly necessary, at least for small projects. The most important thing is to keep the code simple to understand and follow, then you can write great software in dynamically typed languages as well. Also have Typescript experience but in general I'm not a big fan of gradually typed programming languages, static typing works best in languages that were designed for it from the ground up and that offer an expressive type system, e.g. C++ or Rust.

deepstack 4y ago

Deno could be a good alternative. It should hit GA 3 QT this year.

0des 4y ago
I would not choose Deno for that considering how little there is for it currently and how much of what there is available that is plastered with all caps warnings to not use it in production.

mritchie712 4y ago

Two things I consider: 1. what languages does the team already know best? 2. are any languages dominant in the problem space? for us, I've used Python over 10 years and Python is the leader in data science / analytics. Some things might be a little faster if we used Rust, but compute is cheap. Go with what you know.

pizza234 4y ago
I agree that one doesn't necessarily need a fast language, but I think that the "hardware is cheap" idea is very misleading. Renting/owning 5x as much servers may be cheap, but maintaining them isn't.
- mritchie712 4y ago
  check out https://cloud.google.com/run https://cloud.google.com/run. I've never had issues 5x-ing compute on it. All the other services that compute hits (e.g. Postgres) are a different story, but that doesn't really matter when picking a language.
retcon 4y ago
1 may be better asked as what aspects of your team understanding of any considered language apply to your problem space. How well can you port that knowledge to another model of expression. 2 is fine. the more significant question is often do you want to work with that talent pool and does the pool tell you more about the costs structure of your sector against which information you may prefer to tack against the prevailing winds and even more patiently attempt to trade actual equity for deep abilities and stuff what language is chosen if your stock has value. I don't understand how much attention individual languages receive. Plural understanding across your team and ability to transcribe the code into valid parseable docs against which APIs are easily written, is paramount in my mind. Corollary to my incredulity I have often thought that you emphasize the codebase language and dialects only to find you fuelled holy wars and dissipated your technical mission values. Which is disastrous for hiring the kind of colleagues we get up in the morning and forget about industry grief to share increasingly awful spaces with.
4y ago

throwaway0x7E6 4y ago

>Yeah, everyone wants to be a Rust programmer I understand why you might have got that impression, but that's a far cry from the reality

amelius 4y ago
It really puzzles me why smart people want to spend their time satisfying the borrow checker rather than inventing new and useful things.
- sebzim4500 4y ago
  I don't remember the 'satisfying the borrow checker' phase lasting more than a few weeks. Once you internalize the rules the borrow checker gets out of your way and it's more of a sanity check. I think part of the issue is that it wasn't very well explained in the book at the time I started learning rust. This might have improved since.
  - amelius 4y ago
    The entire way of coding in Rust revolves around satisfying the borrow checker. At some point it may become second nature, but you are still jumping through Rust's hoops, which will make your code full of compromises that would otherwise not exist.
    - unrealhoang 4y ago
      So does the entire way of coding in any static-typed language, your code is full of compromises that would otherwise not exist in a dynamic-type language. Rust is just another layer of static typing.
      - amelius 4y ago
        Yes. It's another level of the same problem. Rust is like a piano where certain keys have been removed so you never play out of key.

m_a_g 4y ago

I would like to add that async Rust still doesn't really work. That is a big negative for Rust.

staticassertion 4y ago
It definitely works just fine
- m_a_g 4y ago
  You can find great examples of Rust async programming being "a disaster and a mess". You still can consider it is working just fine, but I disagree.
  - staticassertion 4y ago
    I don't really need to find those examples, I've written most of my company's product in Rust using async, for years, and it's never once been an issue. That's 100s of thousands of lines of rust written and 0 async issues.
    - clpm4j 4y ago
      Totally valid, but you could also say the same thing about C and C++, i.e. you can wield your tool with mastery, then that's awesome. But I think the average startup would likely struggle needlessly when they really just need to ship products that people want/need to use. Rust is likely not the smartest choice for the average startup.
      - staticassertion 4y ago
        Only one person at the company had previous professional experience with Rust. The majority had 0 experience with it at all. We've had no trouble and it's actually been our most productive language - we're moving away from Python and Typescript where possible.