7 ms·

> It's been over 10 years since I last worked with C++ every day, and I'm nowhere near being a competent C++ programmer anymore. Part of that is because C++ has

by twsted 7y ago

> It's been over 10 years since I last worked with C++ every day, and I'm nowhere near being a competent C++ programmer anymore. Part of that is because C++ has evolved, which is a very good thing. Part of it is because C++ is huge. From a decade away, it seems hard to be a competent part-time C++ programmer: you need to be fully immersed, or you'll never fit the whole thing in your head. This is really true. I have worked with C++ for 15/20 years, reading and studying everything I could. I've reached a good competence but every time I stopped for a while I immediately fell behind. C++ is a difficult beast.

rtkaratekid 7y ago
This is so true for almost everyone I’ve talked with. It’s almost like each release is its own language too. I’ve been programming in Rust recently, and didn’t realize how much I love it till I tried doing something in C++ again. I will say I still really enjoy the simplicity of C, but the guarantees of Rust are really hard to beat.
- skocznymroczny 7y ago
  I am kind of in a similar camp with D. I just can't go back to C++, no matter what.
  - pjmlp 7y ago
    Me with managed compiled languages. Still need to go back to C++ every now and then, unfortunately not all interesting libraries have bindings available.
- BubRoss 7y ago
  C++11 you could say that about, but I don't think any other revision is anywhere close to needing that much work to get up to speed. Ownership semantics mean that many times there are much more elegant ways of doing almost everything. In later versions, not using the latest features is not such a big deal, you don't miss out on the same leap forward.
yaktubi 7y ago
I think to get good at a given systems language these days the effort is the same. For instance, concurrency still requires the same underlying ideas to be understood whether C++ or Rust. After all the machine underneath is the same. Rust has some nice-to-haves of course, but C++ has been able to grow up and evolve because of the rich feature-set the template meta-programming language has provided it. One can simply stick to C++11 or 14 and work with those features alone to make strides in development. Hell, people have used C++98 for decades. Personally, I think what C++ offers is the same as Rust. Both need a robust testing and code-coverage tools for correctness, but the end result requires simply good development practices and love for the work being done.
- quietbritishjim 7y ago
  > Personally, I think what C++ offers is the same as Rust. I think this dismisses incidental complexity that can certainly exist in general, and certainly does exist in C++. Just look at how complex move semantics are in C++: * you have & and && references, * there are all sorts of categories (e.g. glvalues), * in a template && means something different (but not always), * std::move by itself doesn't actually do anything (yes I know it's a cast but this is still confusing at least upfront), * even if you do pass the result of std::move (or otherwisie know you have an rvalue reference) to a constructor then it's still possible that the object will actually be copied with no error or even warning. In Rust, the difference is enormous: * When you move from a value, it's guaranteed that the old object's destructor will not be called, so you don't need a move constructor that hackily sets up an empty value so is destructor won't do anything; * Move is always a bitwise copy so it's easier for the caller to understand and free for the implementor to implement (this is enabled by the previous point) * Move is the default instead of copy which makes a million times more sense because you can just implement copy as a regular method that happens to return (move!) its result (whereas you could never implement move as something that returns its result by copying) and if you actually want to copy a value to a function you can just call the copy method and move that value to it. This final one is key is really, it's not possible because of C++'s history and backwards-compatibility requirements and that's why it had to come up with the crazy system it now has. Rust has many nice features but really the move vs copy stuff by itself is a huge saving in complexity, and the fact that Rust manages it at all proves that it is not intrinsic to the problem. (Disclaimer: I have worked with C++ on and off full time for more than 15 years, whereas I have only tinkered with Rust.)
vbezhenar 7y ago
Java become that beast. They released Java 1. Then nothing changed until Java 5 which was huge release in terms of changes. Then again nothing changed until Java 8 and since Java 8 every release brings some major changes. So you could basically learn Java 5 and use Java 6, Java 7 for 10 years with virtually no changes, but now there are some changes every year. I bet that many people won't like it and will stay on Java 7 forever.
- swsieber 7y ago
  While there are some changes every year, if you batch by LTS, the change window has shifted from 10 years down to 3. And I think it's a reasonable choice.
- p2detar 7y ago
  Not that many radical changes since Java 8 that I can think of. The language stays quite coherent so far. I find myself using “var” and switch with strings pretty often with Java 11.
FpUser 7y ago
I am competent programmer in a general sense (knowing how to architect the software anywhere from entreprise stuff down to a firmware). I also use C++ and the fact that I do not really know lots of things about it does not bother me in a slightest. I just use the subset that fulfills my particular needs and am ok with this. If I need some feature that I do not know how it implemented if at all in C++ Google will give me solution in a minute.
- tonyedgecombe 7y ago
  You can get away with that with some languages, C# for instance has very little to trip you up. C++ on the other hand has dark corners that will cause problems. For instance not knowing about the issues with virtual destructors could come back to bite you.
  - FpUser 7y ago
    It will but I happen to know about virtual destructors. I do some reading every once in a while to glance over the things. So some interesting pieces get stuck in my secondary RAM ;) But yes I know C++ could be a dangerous beast but so far it's been kind to me.
jkaptur 7y ago
Languages face enormous pressure to add features, just like any other product. There's a culture of picking languages by counting checkboxes - "if your language doesn't have X, it's Blub", where X can be anything from sum types to lazy evaluation - and little awareness that, like any other product, features have cost that's difficult to measure. I think there's space for a language that is less, and is "done". When it's announced on this website, the comments will be "so it's Rust without X, or Kotlin without Y", but those comments will be in the same vein as "why not use rsync" and "less space than a nomad".

by twsted 7y ago

rtkaratekid 7y ago

This is so true for almost everyone I’ve talked with. It’s almost like each release is its own language too. I’ve been programming in Rust recently, and didn’t realize how much I love it till I tried doing something in C++ again. I will say I still really enjoy the simplicity of C, but the guarantees of Rust are really hard to beat.

skocznymroczny 7y ago
I am kind of in a similar camp with D. I just can't go back to C++, no matter what.
- pjmlp 7y ago
  Me with managed compiled languages. Still need to go back to C++ every now and then, unfortunately not all interesting libraries have bindings available.
BubRoss 7y ago
C++11 you could say that about, but I don't think any other revision is anywhere close to needing that much work to get up to speed. Ownership semantics mean that many times there are much more elegant ways of doing almost everything. In later versions, not using the latest features is not such a big deal, you don't miss out on the same leap forward.

yaktubi 7y ago

I think to get good at a given systems language these days the effort is the same. For instance, concurrency still requires the same underlying ideas to be understood whether C++ or Rust. After all the machine underneath is the same. Rust has some nice-to-haves of course, but C++ has been able to grow up and evolve because of the rich feature-set the template meta-programming language has provided it. One can simply stick to C++11 or 14 and work with those features alone to make strides in development. Hell, people have used C++98 for decades. Personally, I think what C++ offers is the same as Rust. Both need a robust testing and code-coverage tools for correctness, but the end result requires simply good development practices and love for the work being done.

quietbritishjim 7y ago
> Personally, I think what C++ offers is the same as Rust. I think this dismisses incidental complexity that can certainly exist in general, and certainly does exist in C++. Just look at how complex move semantics are in C++: * you have & and && references, * there are all sorts of categories (e.g. glvalues), * in a template && means something different (but not always), * std::move by itself doesn't actually do anything (yes I know it's a cast but this is still confusing at least upfront), * even if you do pass the result of std::move (or otherwisie know you have an rvalue reference) to a constructor then it's still possible that the object will actually be copied with no error or even warning. In Rust, the difference is enormous: * When you move from a value, it's guaranteed that the old object's destructor will not be called, so you don't need a move constructor that hackily sets up an empty value so is destructor won't do anything; * Move is always a bitwise copy so it's easier for the caller to understand and free for the implementor to implement (this is enabled by the previous point) * Move is the default instead of copy which makes a million times more sense because you can just implement copy as a regular method that happens to return (move!) its result (whereas you could never implement move as something that returns its result by copying) and if you actually want to copy a value to a function you can just call the copy method and move that value to it. This final one is key is really, it's not possible because of C++'s history and backwards-compatibility requirements and that's why it had to come up with the crazy system it now has. Rust has many nice features but really the move vs copy stuff by itself is a huge saving in complexity, and the fact that Rust manages it at all proves that it is not intrinsic to the problem. (Disclaimer: I have worked with C++ on and off full time for more than 15 years, whereas I have only tinkered with Rust.)

vbezhenar 7y ago

Java become that beast. They released Java 1. Then nothing changed until Java 5 which was huge release in terms of changes. Then again nothing changed until Java 8 and since Java 8 every release brings some major changes. So you could basically learn Java 5 and use Java 6, Java 7 for 10 years with virtually no changes, but now there are some changes every year. I bet that many people won't like it and will stay on Java 7 forever.

swsieber 7y ago
While there are some changes every year, if you batch by LTS, the change window has shifted from 10 years down to 3. And I think it's a reasonable choice.
p2detar 7y ago
Not that many radical changes since Java 8 that I can think of. The language stays quite coherent so far. I find myself using “var” and switch with strings pretty often with Java 11.

FpUser 7y ago

I am competent programmer in a general sense (knowing how to architect the software anywhere from entreprise stuff down to a firmware). I also use C++ and the fact that I do not really know lots of things about it does not bother me in a slightest. I just use the subset that fulfills my particular needs and am ok with this. If I need some feature that I do not know how it implemented if at all in C++ Google will give me solution in a minute.

tonyedgecombe 7y ago
You can get away with that with some languages, C# for instance has very little to trip you up. C++ on the other hand has dark corners that will cause problems. For instance not knowing about the issues with virtual destructors could come back to bite you.
- FpUser 7y ago
  It will but I happen to know about virtual destructors. I do some reading every once in a while to glance over the things. So some interesting pieces get stuck in my secondary RAM ;) But yes I know C++ could be a dangerous beast but so far it's been kind to me.

jkaptur 7y ago

Languages face enormous pressure to add features, just like any other product. There's a culture of picking languages by counting checkboxes - "if your language doesn't have X, it's Blub", where X can be anything from sum types to lazy evaluation - and little awareness that, like any other product, features have cost that's difficult to measure. I think there's space for a language that is less, and is "done". When it's announced on this website, the comments will be "so it's Rust without X, or Kotlin without Y", but those comments will be in the same vein as "why not use rsync" and "less space than a nomad".