6 ms·

> seeing a kid fresh out of college fearlessly writing performant code by leveraging the amazing Rust compiler A nice (and very ridiculous) fantasy, but no. A

> seeing a kid fresh out of college fearlessly writing performant code by leveraging the amazing Rust compiler A nice (and very ridiculous) fantasy, but no. As a person who hires developers to write performant code, I'd love it if there were these magical junior Rust developers who can write performant code. But as the market exists right now, Rust developers are twice as expensive and the product they deliver is twice as bad. The only way I can justify Rust to higher management is selling it as a vanity PR project.

spoiler 5y ago
> But as the market exists right now, Rust developers are twice as expensive and the product they deliver is twice as bad. It's interesting how we have different experiences regarding this. In my experience, it's usually the opposite. And I believe it's mostly because Rust lets you focus more on the problem you're solving, rather than thinking about dos and don'ts of the language. For example, most Rust projects (or products) seem to have much more polish than equivalent C++ projects (even for ones with years head start). By polish I mean both user experience and the developer experience when one works on the project. Also, adding user-facing (i.e. UX) polish to Rust projects requires less ahead-of-time planning in my experience. One reason is that when introducing new Rust code, there's less performance gotchas, and Rust code seems to compose more ergonomically than C++ code... Most of the time at least; there were times that Rust was frustrating. But I think less often probably, _and_ the frustration is compile-time, rather than runtime. Also Rust has a shorter feedback loop due to Rust's incremental compilation really helps mitigate the frustration, so you can iterate faster. And another is because I've always felt like refactoring Rust code (even with C++ experience than Rust) tends to be easier, and faster to refactor, and I feel bolder while doing it, if that makes sense? Simply because the compiler thinks about various categories of problem domains instead of me, and it tells me about them. Of course, it's never black and white with any of the above things I mentioned; the situation is grey in both ecosystems. But I think it's a much lighter shade of grey in the Rust space than in the C++ space. And as always, there's always exceptions on either side, too. EDIT: I quoted OP's full sentence, but then only addressed the last bit. I hopefully clarified in comments below that I wasn't talking about the first part. Sorry about that!
- otabdeveloper4 5y ago
  > In my experience, it's usually the opposite. Obviously your experience doesn't involve budgeting or hiring developers. Your subjective feelings about how nice or fast it is to write Rust code isn't what we're talking about here. The original poster claimed that Rust can save money by letting managers hire junior devs to replace senior C++ developers. This isn't true. Rust developers are much more expensive than C++ developers, and have vastly lower productivity. (No doubt because of their vastly inflated expectations; any Go/Python/PHP developer who upgrades to Rust suddenly thinks they are elite 10x programmers because they have a clue about performance now.)
  - spoiler 5y ago
    > Obviously your experience doesn't involve budgeting or hiring developers. Ah, that is very true! :) I forgot to make clear in my comment that I wasn't referring to that bit at all. I only participated in the hiring/interview process, but that's as far as my hiring experience goes. > The original poster claimed that Rust can save money by letting managers hire junior devs to replace senior C++ developers. Ah, I didn't interpret it that way. I thought the point they wanted to get across was that it's easier to get the same for less—not in terms of monetary cost, but in terms of less mental effort with regards to context/knowledge about the language itself. But, the hiring point you're addressing can be inferred from their comment, too. I think I agree with you on that... It probably is "easier" to hire C++ developers, since there's an older and bigger market for them. I think Rust developers are in an interesting position right now that they're not as abundant as other developers, since Rust is probably still in "early adoption" stage. So they can use that as leverage in salary negotiations, maybe? But it also comes at a cost of a much smaller job market for them, too.
    - fisf 5y ago
      > I think Rust developers are in an interesting position right now that they're not as abundant as other developers, since Rust is probably still in "early adoption" stage. So they can use that as leverage in salary negotiations, maybe? But it also comes at a cost of a much smaller job market for them, too. No, you are viewing that from a technological perspective - what you assume only holds if "Rust" was a requirement. If staffing a project is much harder (and maybe more expensive) when using Rust as language, then Rust will not be chosen if C++ is an option.
dureuill 5y ago
> But as the market exists right now, Rust developers are twice as expensive and the product they deliver is twice as bad. What? Why? I've been developing C++ for 10 years and seen firsthand the problems it causes and that are addressed by Rust. If I start writing Rust I'm going to be more productive (from build system to maintenance), write more performant and reliable code faster, so I don't see how the delivered product would be worse, as I'd have more time to iterate. About the rate, maybe that would be more expensive, but I'd say it's still worth it. Anyway, it's not like getting competent C++ developers is cheap either. As for GP's message, I agree it looks unrealistic that "kid fresh out of college" would magically write performant code because they're writing rust. There is more to performance than the language, and it is particularly easy to write bad performance code in rust (and in C++ I must add). That being said, I'd still be less anxious to have a junior in a rust codebase than near a C++ one.
- otabdeveloper4 5y ago
  > If I start writing Rust I'm going to be more productive (from build system to maintenance), write more performant and reliable code faster, so I don't see how the delivered product would be worse, as I'd have more time to iterate. Maybe it's true for you, but I can hire a competent C++ programmer to deliver code faster for less than what you'd ask. Also, if a programmer is spending time "iterating" on a performance problem, he's already underperforming. That's okay for less experienced developers as part of the learning process, but expecting it to be the norm? No. > About the rate, maybe that would be more expensive, but I'd say it's still worth it. Real-world metrics do not agree.
  - spoiler 5y ago
    > Also, if a programmer is spending time "iterating" on a performance problem, he's already underperforming. That's okay for less experienced developers as part of the learning process, but expecting it to be the norm? No. I don't think the OP meant iterating on performance problems specifically, just generally iterating on code as one does when they write it. Also, every programmer at some point iterates about performance problems, not matter their experience, or language (or implementation), or runtime that's being used. I think the original "uni grad can write better Rust code than experience C++ dev can write C++" is a hyperbole. I don't think they meant better, but the Rust developer will need less context to implement the same feature. The spirit of that sentence was probably "it's simpler to write performant and safe code in Rust than C++". But again, without really agreeing what "performance" means here, it's a bit silly to discuss. Performance is such a complex that can mean so many things depending on the problem. So, I we're all nit-picking about something without even agreeing what they're specifically nit-picking about. The default IO mode in C/C++ is buffered. Rust requires you to wrap it in `BufWriter`. For most network (or general IO, really) workloads you want buffered IO. So sure: We could say that writing performant IO code in Rust is more difficult, if we hyper-focus on this one specific detail. FWIW (and people who're unfamiliar with this): I think switching to buffered IO in Rust is absolutely trivial, and very well documented (in multiple places where it's relevant). In fact more so than it is to switch to unbuffered IO in C++, because you have to call `setbuf` with "special" values to disable buffering. We can then argue that experience/wisdom diminishes most of these arguments about performance, but it diminishes them on both sides.
zozbot234 5y ago
The main point of Rust is correctness, not performance. Performant code is a nice to have - but when the two are in conflict, correct code wins every time. How can one ever be confident that your Senior C++ devs are writing code that is free of subtle bugs? Are you going to look for professional Haskell or Ocaml devs too, for a proper comparison? Those folks ain't cheap, either.
- mbrodersen 5y ago
  I maintain large scale C++ code that hasn’t had a bug in production for 5+ years. I do it using lots of system level tests. So it is very much doable. It has nothing to do with the programming language. Yes some languages (Haskell for example) completely eliminate a large class of bugs, and I would prefer to use languages like that, however the world runs on C/C++. So having solid C++ skills is great for your career.

spoiler 5y ago

> But as the market exists right now, Rust developers are twice as expensive and the product they deliver is twice as bad. It's interesting how we have different experiences regarding this. In my experience, it's usually the opposite. And I believe it's mostly because Rust lets you focus more on the problem you're solving, rather than thinking about dos and don'ts of the language. For example, most Rust projects (or products) seem to have much more polish than equivalent C++ projects (even for ones with years head start). By polish I mean both user experience and the developer experience when one works on the project. Also, adding user-facing (i.e. UX) polish to Rust projects requires less ahead-of-time planning in my experience. One reason is that when introducing new Rust code, there's less performance gotchas, and Rust code seems to compose more ergonomically than C++ code... Most of the time at least; there were times that Rust was frustrating. But I think less often probably, _and_ the frustration is compile-time, rather than runtime. Also Rust has a shorter feedback loop due to Rust's incremental compilation really helps mitigate the frustration, so you can iterate faster. And another is because I've always felt like refactoring Rust code (even with C++ experience than Rust) tends to be easier, and faster to refactor, and I feel bolder while doing it, if that makes sense? Simply because the compiler thinks about various categories of problem domains instead of me, and it tells me about them. Of course, it's never black and white with any of the above things I mentioned; the situation is grey in both ecosystems. But I think it's a much lighter shade of grey in the Rust space than in the C++ space. And as always, there's always exceptions on either side, too. EDIT: I quoted OP's full sentence, but then only addressed the last bit. I hopefully clarified in comments below that I wasn't talking about the first part. Sorry about that!

otabdeveloper4 5y ago
> In my experience, it's usually the opposite. Obviously your experience doesn't involve budgeting or hiring developers. Your subjective feelings about how nice or fast it is to write Rust code isn't what we're talking about here. The original poster claimed that Rust can save money by letting managers hire junior devs to replace senior C++ developers. This isn't true. Rust developers are much more expensive than C++ developers, and have vastly lower productivity. (No doubt because of their vastly inflated expectations; any Go/Python/PHP developer who upgrades to Rust suddenly thinks they are elite 10x programmers because they have a clue about performance now.)
- spoiler 5y ago
  > Obviously your experience doesn't involve budgeting or hiring developers. Ah, that is very true! :) I forgot to make clear in my comment that I wasn't referring to that bit at all. I only participated in the hiring/interview process, but that's as far as my hiring experience goes. > The original poster claimed that Rust can save money by letting managers hire junior devs to replace senior C++ developers. Ah, I didn't interpret it that way. I thought the point they wanted to get across was that it's easier to get the same for less—not in terms of monetary cost, but in terms of less mental effort with regards to context/knowledge about the language itself. But, the hiring point you're addressing can be inferred from their comment, too. I think I agree with you on that... It probably is "easier" to hire C++ developers, since there's an older and bigger market for them. I think Rust developers are in an interesting position right now that they're not as abundant as other developers, since Rust is probably still in "early adoption" stage. So they can use that as leverage in salary negotiations, maybe? But it also comes at a cost of a much smaller job market for them, too.
  - fisf 5y ago
    > I think Rust developers are in an interesting position right now that they're not as abundant as other developers, since Rust is probably still in "early adoption" stage. So they can use that as leverage in salary negotiations, maybe? But it also comes at a cost of a much smaller job market for them, too. No, you are viewing that from a technological perspective - what you assume only holds if "Rust" was a requirement. If staffing a project is much harder (and maybe more expensive) when using Rust as language, then Rust will not be chosen if C++ is an option.

dureuill 5y ago

> But as the market exists right now, Rust developers are twice as expensive and the product they deliver is twice as bad. What? Why? I've been developing C++ for 10 years and seen firsthand the problems it causes and that are addressed by Rust. If I start writing Rust I'm going to be more productive (from build system to maintenance), write more performant and reliable code faster, so I don't see how the delivered product would be worse, as I'd have more time to iterate. About the rate, maybe that would be more expensive, but I'd say it's still worth it. Anyway, it's not like getting competent C++ developers is cheap either. As for GP's message, I agree it looks unrealistic that "kid fresh out of college" would magically write performant code because they're writing rust. There is more to performance than the language, and it is particularly easy to write bad performance code in rust (and in C++ I must add). That being said, I'd still be less anxious to have a junior in a rust codebase than near a C++ one.

otabdeveloper4 5y ago
> If I start writing Rust I'm going to be more productive (from build system to maintenance), write more performant and reliable code faster, so I don't see how the delivered product would be worse, as I'd have more time to iterate. Maybe it's true for you, but I can hire a competent C++ programmer to deliver code faster for less than what you'd ask. Also, if a programmer is spending time "iterating" on a performance problem, he's already underperforming. That's okay for less experienced developers as part of the learning process, but expecting it to be the norm? No. > About the rate, maybe that would be more expensive, but I'd say it's still worth it. Real-world metrics do not agree.
- spoiler 5y ago
  > Also, if a programmer is spending time "iterating" on a performance problem, he's already underperforming. That's okay for less experienced developers as part of the learning process, but expecting it to be the norm? No. I don't think the OP meant iterating on performance problems specifically, just generally iterating on code as one does when they write it. Also, every programmer at some point iterates about performance problems, not matter their experience, or language (or implementation), or runtime that's being used. I think the original "uni grad can write better Rust code than experience C++ dev can write C++" is a hyperbole. I don't think they meant better, but the Rust developer will need less context to implement the same feature. The spirit of that sentence was probably "it's simpler to write performant and safe code in Rust than C++". But again, without really agreeing what "performance" means here, it's a bit silly to discuss. Performance is such a complex that can mean so many things depending on the problem. So, I we're all nit-picking about something without even agreeing what they're specifically nit-picking about. The default IO mode in C/C++ is buffered. Rust requires you to wrap it in `BufWriter`. For most network (or general IO, really) workloads you want buffered IO. So sure: We could say that writing performant IO code in Rust is more difficult, if we hyper-focus on this one specific detail. FWIW (and people who're unfamiliar with this): I think switching to buffered IO in Rust is absolutely trivial, and very well documented (in multiple places where it's relevant). In fact more so than it is to switch to unbuffered IO in C++, because you have to call `setbuf` with "special" values to disable buffering. We can then argue that experience/wisdom diminishes most of these arguments about performance, but it diminishes them on both sides.

zozbot234 5y ago

The main point of Rust is correctness, not performance. Performant code is a nice to have - but when the two are in conflict, correct code wins every time. How can one ever be confident that your Senior C++ devs are writing code that is free of subtle bugs? Are you going to look for professional Haskell or Ocaml devs too, for a proper comparison? Those folks ain't cheap, either.

mbrodersen 5y ago
I maintain large scale C++ code that hasn’t had a bug in production for 5+ years. I do it using lots of system level tests. So it is very much doable. It has nothing to do with the programming language. Yes some languages (Haskell for example) completely eliminate a large class of bugs, and I would prefer to use languages like that, however the world runs on C/C++. So having solid C++ skills is great for your career.