4 ms·

> In my experience, it's usually the opposite. Obviously your experience doesn't involve budgeting or hiring developers. Your subjective feelings about how ni

> 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.
lpapez 5y ago
> The original poster claimed that Rust can save money by letting managers hire junior devs to replace senior C++ developers. This is not at all what I said, nor meant. I never said anything about the hiring market, but merely stated a personal observation why I think Senior C++ devs often dislike Rust.
- ncmncm 5y ago
  You were wrong about that, too: Senior C++ developers are not impressed with Rust because it doesn't solve any problem they have. Switching to Rust would make them markedly less productive, with no corresponding benefit. The drain comes from slow compilation and from excess design overhead, the need to distort a simpler architecture to satisfy the borrow checker. Put simply, the extra work to satisfy the borrow checker prevents errors they do not make. This contradicts Rust propaganda, where a few CVE numbers are cited over and over, echo-chamber style. What these citations never mention is that they are for bugs in mostly very old code. We just don't need to write code that way anymore. It is not just error-prone, it is more work, so there is simply no temptation to write it that way. I do hear of programmers who have elected to stop learning, and (proudly!) admit continuing to write C++98 or even "C-like C++". We used to say "you can write FORTRAN in any language"; there is no eliminating bad programmers, but plenty of reasons to avoid their product. What conclusions can we make about Rust from its worst adherents?
  - tialaramex 5y ago
    > What these citations never mention is that they are for bugs in mostly very old code. It is unavoidably true that grave security holes get found only in existing code and not hypothetical future code written with a later language revision and whatever new features will definitely avoid those "errors they do not make". That's time's arrow for you. Can you name a few of these "Senior C++ developers" and point us to, say, a few years of their work? Is there a specific vintage of C++ where you feel like, at last, unlike C++ 98 you "don't need to write code that way" and so Senior C++ developers won't make these errors? C++ 11 maybe?
  - kobebrookskC3 5y ago

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.

lpapez 5y ago

> The original poster claimed that Rust can save money by letting managers hire junior devs to replace senior C++ developers. This is not at all what I said, nor meant. I never said anything about the hiring market, but merely stated a personal observation why I think Senior C++ devs often dislike Rust.

ncmncm 5y ago
You were wrong about that, too: Senior C++ developers are not impressed with Rust because it doesn't solve any problem they have. Switching to Rust would make them markedly less productive, with no corresponding benefit. The drain comes from slow compilation and from excess design overhead, the need to distort a simpler architecture to satisfy the borrow checker. Put simply, the extra work to satisfy the borrow checker prevents errors they do not make. This contradicts Rust propaganda, where a few CVE numbers are cited over and over, echo-chamber style. What these citations never mention is that they are for bugs in mostly very old code. We just don't need to write code that way anymore. It is not just error-prone, it is more work, so there is simply no temptation to write it that way. I do hear of programmers who have elected to stop learning, and (proudly!) admit continuing to write C++98 or even "C-like C++". We used to say "you can write FORTRAN in any language"; there is no eliminating bad programmers, but plenty of reasons to avoid their product. What conclusions can we make about Rust from its worst adherents?
- tialaramex 5y ago
  > What these citations never mention is that they are for bugs in mostly very old code. It is unavoidably true that grave security holes get found only in existing code and not hypothetical future code written with a later language revision and whatever new features will definitely avoid those "errors they do not make". That's time's arrow for you. Can you name a few of these "Senior C++ developers" and point us to, say, a few years of their work? Is there a specific vintage of C++ where you feel like, at last, unlike C++ 98 you "don't need to write code that way" and so Senior C++ developers won't make these errors? C++ 11 maybe?
- kobebrookskC3 5y ago