5 ms·

The trade-off in complexity and loss of productivity (particularly at prototype time) are just not worth it.

by toyg 3y ago

vgatherps 3y ago
This really depends on your use case for it, as all things - it’s hard to just make blanket statements like this
- toyg 3y ago
  On par with "Rust helps you write better code" in the parent comment.
  - insanitybit 3y ago
    Not at all. I added this context: > It also doesn't have some of the worst features of OOP, it also has a sane std library, it also has an expressive type system, etc. You made a baseless assertion, I at least gave examples of features/antifeatures that helped me draw my conclusion.
maxbond 3y ago
Personally I regard Rust as strictly less complex than most other languages (to use - not to learn). The space of programs you're searching through is smaller and more constrained (there are fewer valid Rust programs then valid Python programs, and we can make stronger statements about the behavior of a valid Rust program). Ergo, simpler. Internalizing those constraints so they aren't generally slowing you down takes an investment however. Recently I had a vexing silent bug in a prototype, where I was intermingling strings and ints as keys in a dictionary, and thus not writing to the correct keys. Normally I would be more careful than that, but it was a quick and dirty proof of concept. Because this involved JSON deserialization, Python's modest static type checking couldn't catch it. That just wouldn't have happened in Rust. (But of course, I wouldn't have had the particular ML libraries I needed, either, so Python remains the best option for this project.)
- pharmakom 3y ago
  There are infinitely many Rust and Python programs, just as there are infinitely many English sentences. Search is a really weird way to talk about programming.
  - maxbond 3y ago
    I'm gunnuh address this because I think these are interesting nitty gritty details, but note that these are metaphors expressed in a shared vocabulary that happens to be technical, let's not get too caught up in how many Rust programs there are, that's a more literal interpretation than I intended. If you cap the number of tokens, the are fewer Rust programs. If you prefer, things that may be done implicitly in Python must be done explicitly in Rust - there are fewer valid choices when constructing a program; or equivalently, as you write a Python program, the options for your to proceed fan out faster. Really we aren't searching the whole space of programs though. We understand that adding no-ops to a program doesn't move us out of the equivalency class of that program (unless we're actually using those for timing or another side effect, of course, but then they are no-ops in name only). We're only searching through programs that reasonably solve the problem at hand. Maybe that space is infinite, I don't think so. I think of programming as being a fuzzy beam search (among other ways I sometimes think about programming). Your salience may vary, feel free to drop in a metaphor of your choosing there.
    - pharmakom 3y ago
      We can model programming as search, but programming as humans do it is more like design than search. I mean this in the qualitative and experiential sense. I don’t sit in front of the screen as candidate programs flash by until I see the one that I want. I also don’t edit by AST transformations from one valid program to another, like edges in a graph. I really don’t see the possible program space as all that relevant.
      - maxbond 3y ago
        > I also don’t edit by AST transformations from one valid program to another, like edges in a graph. I don't really see how else you would edit a program? That's what you're doing when you type at your IDE, right? But I think you're understanding how I think of it, feel free to take it or leave it. I'm not gunnuh die on a hill of insisting my way of thinking of it is right, it's just right for me. > I really don’t see the possible program space as all that relevant. In my example, I fell into a silently invalid state. In a more constrained environment, I wouldn't have. It's easier to go bowling with the bumpers turned on, and if your goal was to make as many strikes as possible (rather than to be sporting), surely you'd only ever bowl with the bumpers. It's a Murphy's law thing. The more invalid states you have, the easier it is to get mired there.
wiz21c 3y ago
I've been using it for 2 years now and I can't see any loss in productivity. Once you get used to the patterns rust and the BC force upon you, it's just as productive as C++ (for me). But you have to get up to speed and that's a significant effort (took about 6-12 months for me). I can't say much about the ecosystem besides it lacks something in the desktop GUI department (I use egui, it's really good, but just it's not strong enough). So, yeah, sometimes you miss a library and that can hurt productivity. But the protections against memory and thread issues really help productivity though: I tend to make lots of mistake in these area and rust helps to to prevent many of them.
- kaba0 3y ago
  > Once you get used to the patterns rust and the BC force upon you, it's just as productive as C++ (for me) Well, it makes sense as both are low-level languages. Hell, one might even argue that Rust is “nothing more” than C++’s RAII made into a compiler-enforced primitive. But C++ is not considered a high-productivity language to begin with, at least not many would choose it for a regular old CRUD app.
- mmarq 3y ago
  > I've been using it for 2 years now and I can't see any loss in productivity While I am a big fan and all my personal projects are written in Rust, introducing Rust will likely paralyse entire teams for months, until they get used to the borrow checker. ORMs are quite clunky (at least Diesel) and web frameworks are not as user-friendly as ASP.NET MVC, and that’s 80% of what the average developer needs today.
  - wolletd 3y ago
    We made a short-term decision to develop a new project in Rust only three months ago. As we build vending machines and such things, our products usually contain multiple processors that communicate over various connections and there's a lot of interaction with real-world, physical things. Also, as there are a lot of microcontrollers involved, C and C++ are the dominant languages in our development. So, a lot of our development time actually goes into solving the general unpredictiveness of the real world and humans interacting with actual machines. Rust enables us to focus on solving those problems without getting held up by stupid memory issues. In our case, iterating over new software versions often is slow because it may involve restarting a big machine and doing actual user interaction with it – the time Rust takes before compiling is easily saved for us.
alpaca128 3y ago
There is no noteworthy loss of productivity after some practice in my experience, except when comparing with languages like Python. But among languages I would consider for serious projects Rust is simply difficult to compete against. In the end you always pay the price and often knowing it upfront can help. With prototyping it's a double-edged sword: it can be a bit more cumbersome to change types, but the same type-checks are helpful for pointing out details during refactoring. For me it helps keeping things simple at first, expanding types later on when needed is easy.
junon 3y ago
I'm creating an operating system in Rust and have had more productivity than ever before, especially when I started writing it in C. YMMV.
insanitybit 3y ago
I obviously disagree based on years of writing Rust services.

The trade-off in complexity and loss of productivity (particularly at prototype time) are just not worth it.

by toyg 3y ago

The trade-off in complexity and loss of productivity (particularly at prototype time) are just not worth it.

vgatherps 3y ago

This really depends on your use case for it, as all things - it’s hard to just make blanket statements like this

toyg 3y ago
On par with "Rust helps you write better code" in the parent comment.
- insanitybit 3y ago
  Not at all. I added this context: > It also doesn't have some of the worst features of OOP, it also has a sane std library, it also has an expressive type system, etc. You made a baseless assertion, I at least gave examples of features/antifeatures that helped me draw my conclusion.

maxbond 3y ago

Personally I regard Rust as strictly less complex than most other languages (to use - not to learn). The space of programs you're searching through is smaller and more constrained (there are fewer valid Rust programs then valid Python programs, and we can make stronger statements about the behavior of a valid Rust program). Ergo, simpler. Internalizing those constraints so they aren't generally slowing you down takes an investment however. Recently I had a vexing silent bug in a prototype, where I was intermingling strings and ints as keys in a dictionary, and thus not writing to the correct keys. Normally I would be more careful than that, but it was a quick and dirty proof of concept. Because this involved JSON deserialization, Python's modest static type checking couldn't catch it. That just wouldn't have happened in Rust. (But of course, I wouldn't have had the particular ML libraries I needed, either, so Python remains the best option for this project.)

pharmakom 3y ago
There are infinitely many Rust and Python programs, just as there are infinitely many English sentences. Search is a really weird way to talk about programming.
- maxbond 3y ago
  I'm gunnuh address this because I think these are interesting nitty gritty details, but note that these are metaphors expressed in a shared vocabulary that happens to be technical, let's not get too caught up in how many Rust programs there are, that's a more literal interpretation than I intended. If you cap the number of tokens, the are fewer Rust programs. If you prefer, things that may be done implicitly in Python must be done explicitly in Rust - there are fewer valid choices when constructing a program; or equivalently, as you write a Python program, the options for your to proceed fan out faster. Really we aren't searching the whole space of programs though. We understand that adding no-ops to a program doesn't move us out of the equivalency class of that program (unless we're actually using those for timing or another side effect, of course, but then they are no-ops in name only). We're only searching through programs that reasonably solve the problem at hand. Maybe that space is infinite, I don't think so. I think of programming as being a fuzzy beam search (among other ways I sometimes think about programming). Your salience may vary, feel free to drop in a metaphor of your choosing there.
  - pharmakom 3y ago
    We can model programming as search, but programming as humans do it is more like design than search. I mean this in the qualitative and experiential sense. I don’t sit in front of the screen as candidate programs flash by until I see the one that I want. I also don’t edit by AST transformations from one valid program to another, like edges in a graph. I really don’t see the possible program space as all that relevant.
    - maxbond 3y ago
      > I also don’t edit by AST transformations from one valid program to another, like edges in a graph. I don't really see how else you would edit a program? That's what you're doing when you type at your IDE, right? But I think you're understanding how I think of it, feel free to take it or leave it. I'm not gunnuh die on a hill of insisting my way of thinking of it is right, it's just right for me. > I really don’t see the possible program space as all that relevant. In my example, I fell into a silently invalid state. In a more constrained environment, I wouldn't have. It's easier to go bowling with the bumpers turned on, and if your goal was to make as many strikes as possible (rather than to be sporting), surely you'd only ever bowl with the bumpers. It's a Murphy's law thing. The more invalid states you have, the easier it is to get mired there.

wiz21c 3y ago

I've been using it for 2 years now and I can't see any loss in productivity. Once you get used to the patterns rust and the BC force upon you, it's just as productive as C++ (for me). But you have to get up to speed and that's a significant effort (took about 6-12 months for me). I can't say much about the ecosystem besides it lacks something in the desktop GUI department (I use egui, it's really good, but just it's not strong enough). So, yeah, sometimes you miss a library and that can hurt productivity. But the protections against memory and thread issues really help productivity though: I tend to make lots of mistake in these area and rust helps to to prevent many of them.

kaba0 3y ago
> Once you get used to the patterns rust and the BC force upon you, it's just as productive as C++ (for me) Well, it makes sense as both are low-level languages. Hell, one might even argue that Rust is “nothing more” than C++’s RAII made into a compiler-enforced primitive. But C++ is not considered a high-productivity language to begin with, at least not many would choose it for a regular old CRUD app.
mmarq 3y ago
> I've been using it for 2 years now and I can't see any loss in productivity While I am a big fan and all my personal projects are written in Rust, introducing Rust will likely paralyse entire teams for months, until they get used to the borrow checker. ORMs are quite clunky (at least Diesel) and web frameworks are not as user-friendly as ASP.NET MVC, and that’s 80% of what the average developer needs today.
- wolletd 3y ago
  We made a short-term decision to develop a new project in Rust only three months ago. As we build vending machines and such things, our products usually contain multiple processors that communicate over various connections and there's a lot of interaction with real-world, physical things. Also, as there are a lot of microcontrollers involved, C and C++ are the dominant languages in our development. So, a lot of our development time actually goes into solving the general unpredictiveness of the real world and humans interacting with actual machines. Rust enables us to focus on solving those problems without getting held up by stupid memory issues. In our case, iterating over new software versions often is slow because it may involve restarting a big machine and doing actual user interaction with it – the time Rust takes before compiling is easily saved for us.

alpaca128 3y ago

There is no noteworthy loss of productivity after some practice in my experience, except when comparing with languages like Python. But among languages I would consider for serious projects Rust is simply difficult to compete against. In the end you always pay the price and often knowing it upfront can help. With prototyping it's a double-edged sword: it can be a bit more cumbersome to change types, but the same type-checks are helpful for pointing out details during refactoring. For me it helps keeping things simple at first, expanding types later on when needed is easy.

junon 3y ago

I'm creating an operating system in Rust and have had more productivity than ever before, especially when I started writing it in C. YMMV.

insanitybit 3y ago

I obviously disagree based on years of writing Rust services.