5 ms·

Fully agree that the language is very taxing on the braincells and I think this is the main reason why Senior C++ Wizards tend to hate Rust. Imagine spending 10

by lpapez 5y ago

Fully agree that the language is very taxing on the braincells and I think this is the main reason why Senior C++ Wizards tend to hate Rust. Imagine spending 10 years learning the little details about lifetimes, thread safety, million different UB cases etc. and then seeing a kid fresh out of college fearlessly writing performant code by leveraging the amazing Rust compiler. I bet it must be an infuriating feeling which is why I'm glad that I bailed out on C++ early in my carreer.

deeringc 5y ago
I'm not sure about that. I've spent 18 years programming in C++, for much of that time in a senior professional capacity and am excited to learn Rust for whatever my next project will be. Most of my colleagues and peers feel the same. I think the person you are characterising is quite rare. I like C++ but don't love all of the baggage and am delighted that things are moving forward.
- spoiler 5y ago
  > I think the person you are characterising is quite rare. You could be right... I hope you are right, but I'm afraid you're not... > I'm not sure about that. I've spent 18 years programming in C++, for much of that time in a senior professional capacity and am excited to learn Rust for whatever my next project will be. Most of my colleagues and peers feel the same. [...] I like C++ but don't love all of the baggage and am delighted that things are moving forward. I don't know what the "split" is regarding mentality, and I've definitely seen a lot of experienced C++ devs in Rust communities, but then there's also a lot of people in "Rust bad"[1] circles (you see them on Reddit and HN). I think it might be an even split (as with most polarised opinions), but I don't think that either sort is rate. [1]: I don't blame these people, btw. If you're in a senior or leadership position and you choose C++ for a new project, because C++ is your strong suit. Then you read online "C++ bad" comments that glorify Rust. It's hard to not take these things personally, when it might be affecting your livelihood. Especially if semi-technical management "drinks the Rust Kool-Aid" (for a lack of better expression) and grills you over your decision. It's not a very disheartening situation to be in, and that frustration can fester into contempt, and so on.
  - deeringc 5y ago
    I think maybe you're paying too much heed to what you see in concentrated and very self selecting online communities. A lot of professional C++ programmers are more focussed on particular industries, and the domain problems to solve and less so on the language or specific tools. It just so happens that C++ has been the only game in town in a lot of industries until quite recently. At work we've been looking into trying out Rust in some modules where it would make sense. There has been zero objection based on it being Rust, from a team of senior C++ devs. Quite the opposite, most are keen to try it out. But those people don't spent their time on language message boards. Sure, you will find the type of person that you describe. They definitely exist. But it's not the typical case of senior C++ developer, in my experience. Most of us are domain experts in something (automotive, security, medical devices, games, OSes, networking, etc...) and the language comes secondary. If we can better solve our primary goals with a different language then we'd be fools not to have an open mind.
    - spoiler 5y ago
      > I think maybe you're paying too much heed to what you see in concentrated and very self selecting online communities. That's a good point. In the domain specific communities, I've not not really seen language flamingo.
    - mbrodersen 5y ago
      Senior C++ developer here and I totally agree. Anything that can improve productivity/quality while maintaining high performance is very much welcome. Obviously!
codeflo 5y ago
“Wizard” is the right way to put it. There’s a certain kind of “experienced” developer who enjoys being the local guru way too much. Even regardless of technology, their projects are invariably set up in such a way that no one can do anything without them. C++ seems perfect for these people because there are so many little traps and arbitrary rules to remember. “Ha ha, you wrote for (const auto x: y) instead of for (const auto& x: y)? Stupid fool!” (Or is it auto&& now? decltype(auto)? I honestly don’t remember and don’t really care.) I’m not remotely suggesting all or even most C++ experts are like this, but anecdotally, their share is higher than among, say, Python programmers. It’s not like Rust is particularly easy to learn. On a conceptual level, it’s probably harder than C++ (traits, generics, lifetimes). It’s just so much less arcane.
- lpapez 5y ago
  Both are wrong, east-const is the one true way!
  - tialaramex 5y ago
    I sympathise with East Const, but immediately I am just reminded of another problem with C++ The defaults are wrong. Const should have been the default. Whereupon "East Const" doesn't matter, all the variables which are mutated get labelled. Similarly "explicit" should be the default (nobody wants your random single parameter constructor to be implicitly called, stop that) and "override" shouldn't be (If I name my method foo why is it my responsibility to first check whether some other bozo named a method foo so that I don't "override" it ? The compiler can and should tell me this won't end well†) † Rust brought me around to the idea that some other bozo's quack() method has no business sharing a namespace with mine just because we're both Ducks, if I wanted to override the shared method I'd have re-implemented Duck::quack() not added my own quack() method. But in the C++ world I'll stick to just saying override shouldn't silently be the default.
    - jcelerier 5y ago
      > The defaults are wrong. Const should have been the default. yeah no. struct foo { int x; }; would not be compatible with C because the int would be const, that would have made the language particularly useless.
pjmlp 5y ago
They hate everything that takes 1us from them, following on the C culture. The nice C++ frameworks from the 90's all used bounds checking enabled by default, what does ISO C++? Bounds checking disabled by default and it is up to the compiler vendors to do as they please, hence FORTIFY and _ITERATOR_DEBUG_LEVEL. If you read how magnificent C++ is on the HILO tutorial or C++/WinRT ones, it is quite clear how WinDev sees these nasty folks doing stuff in .NET at DevDiv. Joe Duffy on his Midori talk at RustConf mentions that even with Midori being available to WinDev they were asserting it wasn't possible.
otabdeveloper4 5y ago
> 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!
will4274 5y ago
In my experience, the problem with juniors and performant code has little to do with lifetimes. The issues I see are as easy in C#, Java, or Rust as C++ - e.g. repeatedly using string appends rather than building up a list and doing a single allocation, or holding a lock for the duration of a reload and parse instead of just the reference swap, etc. Thread safety, more often than not, isn't that hard - just do the work on one thread (I work on a web service with thread-per-request). I'm optimistic about Rust but realistic (I think) about how much inertia the common project (C++) really has. I'm also decidedly skeptical about Rust's cure-all possibilities - while I've seen a dozen or so real lifetime bugs in a decade, about half of them were caused by a developer misusing an API, deliberately calling a method that is for transferring lifetimes, and then not assigning the reference to a new object. In my experience, most bugs are just badly written code, not the sort of problem your compiler can fix.
- pjmlp 5y ago
  Here is another example, using a for loop instead of an intrinsic like System.arrayCopy().
- tialaramex 5y ago
  > repeatedly using string appends rather than building up a list and doing a single allocation I think this "make a list" idea performs best where you know exactly how many things will be in the "list" but have little idea how long the concatenated String might be, so you can keep the "list" as a local array (no allocation) and do a single String::with_capacity (one allocation) and then push all the references onto it. Otherwise, obviously we're not going to go around assembling a LinkedList since this is the 21st century and we're not crazy, so let's assume if we don't know how long that "list" is we're accumulating references in a Vec<&str>. We don't know how big to make the Vec either, and so that will grow as we push items onto it. Rust's Strings are - under the hood - basically a Vec<u8> that promises to be valid UTF-8. So we're playing with the exact same allocation algorithm and same amortized costs in String and Vec<&str>. If we're appending very few Strings in the typical case, the "list" approach costs extra because we're doing a bunch more allocations + copies to make the Vec<&str> that we're throwing away shortly afterwards. Likewise if the strings are very short. And after all that it's more complicated, which counts against it unless performance was critical. If I saw a junior reflexively doing this (with a Vec or some other "list" structure) in code I was reviewing, I'd ask them why. If their answer is "performance" I'd remind them: If we aren't measuring it then it isn't performance it's just wanking. So, where's the measurement?
mbrodersen 5y ago
I have been programming in C++ for a very long time (25+ years career). And no I don’t hate Rust at all. I welcome any attempt to make better, safer language that are still fast. I actually wish that Rust had gone one step further and implemented Dependent Types and Refinement Types. It would allow you to prove code correct in Rust. Which is even better than the current Rust guarantees. Having said that, there are about 5 million C++ users out there writing C++ software every day. So it will take a loooooooooong time before Rust usage catches up. If it ever will.

by lpapez 5y ago

deeringc 5y ago

I'm not sure about that. I've spent 18 years programming in C++, for much of that time in a senior professional capacity and am excited to learn Rust for whatever my next project will be. Most of my colleagues and peers feel the same. I think the person you are characterising is quite rare. I like C++ but don't love all of the baggage and am delighted that things are moving forward.

spoiler 5y ago
> I think the person you are characterising is quite rare. You could be right... I hope you are right, but I'm afraid you're not... > I'm not sure about that. I've spent 18 years programming in C++, for much of that time in a senior professional capacity and am excited to learn Rust for whatever my next project will be. Most of my colleagues and peers feel the same. [...] I like C++ but don't love all of the baggage and am delighted that things are moving forward. I don't know what the "split" is regarding mentality, and I've definitely seen a lot of experienced C++ devs in Rust communities, but then there's also a lot of people in "Rust bad"[1] circles (you see them on Reddit and HN). I think it might be an even split (as with most polarised opinions), but I don't think that either sort is rate. [1]: I don't blame these people, btw. If you're in a senior or leadership position and you choose C++ for a new project, because C++ is your strong suit. Then you read online "C++ bad" comments that glorify Rust. It's hard to not take these things personally, when it might be affecting your livelihood. Especially if semi-technical management "drinks the Rust Kool-Aid" (for a lack of better expression) and grills you over your decision. It's not a very disheartening situation to be in, and that frustration can fester into contempt, and so on.
- deeringc 5y ago
  I think maybe you're paying too much heed to what you see in concentrated and very self selecting online communities. A lot of professional C++ programmers are more focussed on particular industries, and the domain problems to solve and less so on the language or specific tools. It just so happens that C++ has been the only game in town in a lot of industries until quite recently. At work we've been looking into trying out Rust in some modules where it would make sense. There has been zero objection based on it being Rust, from a team of senior C++ devs. Quite the opposite, most are keen to try it out. But those people don't spent their time on language message boards. Sure, you will find the type of person that you describe. They definitely exist. But it's not the typical case of senior C++ developer, in my experience. Most of us are domain experts in something (automotive, security, medical devices, games, OSes, networking, etc...) and the language comes secondary. If we can better solve our primary goals with a different language then we'd be fools not to have an open mind.
  - spoiler 5y ago
    > I think maybe you're paying too much heed to what you see in concentrated and very self selecting online communities. That's a good point. In the domain specific communities, I've not not really seen language flamingo.
  - mbrodersen 5y ago
    Senior C++ developer here and I totally agree. Anything that can improve productivity/quality while maintaining high performance is very much welcome. Obviously!

codeflo 5y ago

“Wizard” is the right way to put it. There’s a certain kind of “experienced” developer who enjoys being the local guru way too much. Even regardless of technology, their projects are invariably set up in such a way that no one can do anything without them. C++ seems perfect for these people because there are so many little traps and arbitrary rules to remember. “Ha ha, you wrote for (const auto x: y) instead of for (const auto& x: y)? Stupid fool!” (Or is it auto&& now? decltype(auto)? I honestly don’t remember and don’t really care.) I’m not remotely suggesting all or even most C++ experts are like this, but anecdotally, their share is higher than among, say, Python programmers. It’s not like Rust is particularly easy to learn. On a conceptual level, it’s probably harder than C++ (traits, generics, lifetimes). It’s just so much less arcane.

lpapez 5y ago
Both are wrong, east-const is the one true way!
- tialaramex 5y ago
  I sympathise with East Const, but immediately I am just reminded of another problem with C++ The defaults are wrong. Const should have been the default. Whereupon "East Const" doesn't matter, all the variables which are mutated get labelled. Similarly "explicit" should be the default (nobody wants your random single parameter constructor to be implicitly called, stop that) and "override" shouldn't be (If I name my method foo why is it my responsibility to first check whether some other bozo named a method foo so that I don't "override" it ? The compiler can and should tell me this won't end well†) † Rust brought me around to the idea that some other bozo's quack() method has no business sharing a namespace with mine just because we're both Ducks, if I wanted to override the shared method I'd have re-implemented Duck::quack() not added my own quack() method. But in the C++ world I'll stick to just saying override shouldn't silently be the default.
  - jcelerier 5y ago
    > The defaults are wrong. Const should have been the default. yeah no. struct foo { int x; }; would not be compatible with C because the int would be const, that would have made the language particularly useless.

pjmlp 5y ago

They hate everything that takes 1us from them, following on the C culture. The nice C++ frameworks from the 90's all used bounds checking enabled by default, what does ISO C++? Bounds checking disabled by default and it is up to the compiler vendors to do as they please, hence FORTIFY and _ITERATOR_DEBUG_LEVEL. If you read how magnificent C++ is on the HILO tutorial or C++/WinRT ones, it is quite clear how WinDev sees these nasty folks doing stuff in .NET at DevDiv. Joe Duffy on his Midori talk at RustConf mentions that even with Midori being available to WinDev they were asserting it wasn't possible.

otabdeveloper4 5y ago

> 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!

will4274 5y ago

In my experience, the problem with juniors and performant code has little to do with lifetimes. The issues I see are as easy in C#, Java, or Rust as C++ - e.g. repeatedly using string appends rather than building up a list and doing a single allocation, or holding a lock for the duration of a reload and parse instead of just the reference swap, etc. Thread safety, more often than not, isn't that hard - just do the work on one thread (I work on a web service with thread-per-request). I'm optimistic about Rust but realistic (I think) about how much inertia the common project (C++) really has. I'm also decidedly skeptical about Rust's cure-all possibilities - while I've seen a dozen or so real lifetime bugs in a decade, about half of them were caused by a developer misusing an API, deliberately calling a method that is for transferring lifetimes, and then not assigning the reference to a new object. In my experience, most bugs are just badly written code, not the sort of problem your compiler can fix.

pjmlp 5y ago
Here is another example, using a for loop instead of an intrinsic like System.arrayCopy().
tialaramex 5y ago
> repeatedly using string appends rather than building up a list and doing a single allocation I think this "make a list" idea performs best where you know exactly how many things will be in the "list" but have little idea how long the concatenated String might be, so you can keep the "list" as a local array (no allocation) and do a single String::with_capacity (one allocation) and then push all the references onto it. Otherwise, obviously we're not going to go around assembling a LinkedList since this is the 21st century and we're not crazy, so let's assume if we don't know how long that "list" is we're accumulating references in a Vec<&str>. We don't know how big to make the Vec either, and so that will grow as we push items onto it. Rust's Strings are - under the hood - basically a Vec<u8> that promises to be valid UTF-8. So we're playing with the exact same allocation algorithm and same amortized costs in String and Vec<&str>. If we're appending very few Strings in the typical case, the "list" approach costs extra because we're doing a bunch more allocations + copies to make the Vec<&str> that we're throwing away shortly afterwards. Likewise if the strings are very short. And after all that it's more complicated, which counts against it unless performance was critical. If I saw a junior reflexively doing this (with a Vec or some other "list" structure) in code I was reviewing, I'd ask them why. If their answer is "performance" I'd remind them: If we aren't measuring it then it isn't performance it's just wanking. So, where's the measurement?

mbrodersen 5y ago

I have been programming in C++ for a very long time (25+ years career). And no I don’t hate Rust at all. I welcome any attempt to make better, safer language that are still fast. I actually wish that Rust had gone one step further and implemented Dependent Types and Refinement Types. It would allow you to prove code correct in Rust. Which is even better than the current Rust guarantees. Having said that, there are about 5 million C++ users out there writing C++ software every day. So it will take a loooooooooong time before Rust usage catches up. If it ever will.