8 ms·

Because, little by little, C++ became "unlearnable". Long ago C++ made C a little bit more complex. Because there were already lots of C programmers that wasn'

Because, little by little, C++ became "unlearnable". Long ago C++ made C a little bit more complex. Because there were already lots of C programmers that wasn't a big deal. But then it didn't stop. Little by little C++ grew into a monstrosity. A lot of people went along. I gave up. For new programmers to climb in 2-3 years a mountain that seasoned programmers took 15-20 years to climb is asking too much.

everyone 4y ago
Just cus they add a feature to a language doesnt mean u have to use it. Though it does seem very few programmers are smart enough to stick to the most basic features whenever possible.
- AtlasBarfed 4y ago
  C++ the "language culture" unfortunately has a lot of gatekeeping as well. The fact that the gatekeeping generally revolves around "replace feature from n-5 years with the newer feature in the latest 0x00x release" is a bit tiresome. Yes, I'm exaggerating, a bit. As for the Microsoft whomever-he-is: I agree in theory, I disagree in practice. If there are a lot of C++ devs writing important code, then let them continue to do so in their prime language that they've invested decades of hard work keeping up with the feature treadmill. New devs? Only if you have to.
  - einpoklum 4y ago
    > "replace feature from n-5 years with the newer feature in the latest 0x00x release" Let me put a more pro-C++ spin on that sentiment. C++ is a language that's under long-term development. It might sound weird, but only with C++20 Bjarne Stroustrup felt that his vision for the language was now mostly-realized - and he had worked on it since the 1980s. With other languages, there's a lot of clearing-of-the-desk and starting things anew, while C++ has opted for incremental changes with backwards compatibility to before it existed (i.e. C). But, looking back, we get the sentiment you describe. Which, rephrased, sounds like this: "Remember that annoying and ugly hack you had to use so far to get [complex thing] to work? Well, that finally got fixed. Now there's a shiny new language feature / standard library construct which does that more nicely. But your existing code will also work."
    - pjmlp 4y ago
      A vision that ironically is only fulfilled by Visual C++, and who knows when GCC and clang will manage to reach it, specially in what concerns modules.
    - the_arcadian 4y ago
      Agree 100%. The C++ language and ecosystem shouldn't feel dynamic, given its age and the installed base, and yet it really does. I remember when c++11 came out and all the crazy typedefs I had to type out just disappeared overnight, and I was able to write statements like "using Elem = uint64_t; using Node = MyClass::Node<Elem>;" which were so much more straightforward. Function pointers disappeared too and were replaced by lambdas so I could write my own "each_node" functions and actually have them be really useful. Then we had concurrency primitives, and now apparently there's a module system in c++20 which should be interesting. C++ clearly has no plans to bow out gracefully or otherwise go quietly into the night, which is fine by me since I still think it's the language which gives me, as a developer, the most freedom and control over the system.
    - AtlasBarfed 4y ago
      "but only with C++20 Bjarne Stroustrup felt that his vision for the language was now mostly-realized" So... let me ask you given this statement. Let's say there is an uber smart super productive programmer who states: I can rewrite the entirety of the ecosystem of one language in 1 year.... Would you tell them to rewrite all C/C++ in C++20 or Rewrite it in Rust? C++'s only real advantage in the current language marketplace is an installed library base. But how much of that is C++0x2020? Is the barrier to entry of a new programmer in C++ not just 40 years of language revisions, but a massive massive map of libraries where JSON library uses features from v2016, while XML library uses v2005, while some multithreading thing uses v2020... And then there's the STL, and mixed-in-C standard library, ye gods. Will Rust turn into that? Well, I think it kind of will to some degree as they try to find dialects that perfectly describe borrower checker semantics. Rust is a syntax soup almost on par with C++, but I guess we'll see.
      - einpoklum 4y ago
        > Would you tell them to rewrite all C/C++ in C++20 or Rewrite it in Rust? Neither. 1. I wouldn't trust a person who says something like that. It takes a programming luminary several years to write a good (non-trivial, not-tiny) library the community can get behind, and even that usually involves iterations of use, feedback and partial rewriting/redesign. 2. Why would we want a "rewrite of the entire ecosystem" (whatever that ecosystem may be) all at once? That's a fiasco waiting to happen. 3. An "ecosystem" very often needs to be at least somewhat backwards-compatible, so I wouldn't want it written in something that's just out of the nylons. Probably best to let that smart programmer write some decent foundational libraries which we can adopt one at a time, with increasing benefit of synergy. > C++'s only real advantage in the current language marketplace is an installed library base That seems untrue. C++ has various capabilities in different usage scenarios which other languages do not. But more importantly - programming languages don't all compete: They typically have different combinations of design goals. That's specifically true of C++ vs Rust. > But how much of that is C++0x2020? That doesn't matter much. For you, anything that's not written in the latest version of a language may be irrelevant/unusable. Not for the users of backwards (and forwards-) compatible languages like C, C++ and various others. > Is the barrier to entry of a new programmer in C++ not just 40 years of language revisions No, 40 years of revisions is not a barrier to entry. Your saying that makes it sound like you are not very familiar with the language. > mixed-in-C standard library, ye gods. double x = sqrt(x_squared); ... oh, the humanity! Who would ever write something like this? It's a non-polymorphic function and its symbol doesn't get mangled! Ye gods!
- atomicnumber3 4y ago
  One problem here is that everyone ends up with their own little niches of the language that they like, and nobody's code looks like anyone else's, and suddenly to read a codebase you do need to know huge swathes of the sprawling language. At lastjob, we did a lot of C++, and I could tell whose code I was reading without checking blame because I knew who liked what idioms and features.
  - girvo 4y ago
    > One problem here is that everyone ends up with their own little niches of the language that they like Amusingly, this was always the criticism I've seen leveled at Lisps over the years. It's just as true in C++ for sure.
  - pmontra 4y ago
    This is so true. Two examples. 1. I got a couple of downvotes a few days ago because I commented that I don't like the &s of Elixir (kind of shortcuts for 'fn x ->') and I prefer to write the full form as it's easier to read for everyone no matter how proficient in the language (zero to expert.) I also don't like and almost don't use the & shortcuts in Ruby (positional arguments.) 2. I got a customer recently with the lead developer fond of each_with_object. I never saw that in 17 years of Ruby and I had to check the reference. It's probably faster than the naive implementation (more time inside the C implementation doing real work vs inside the C parser?) but the naive one is immediately readable by anyone.
  - GoblinSlayer 4y ago
    Wouldn't that mean there should be no competing crates, because people should write the same code for the same task?
- girvo 4y ago
  > Just cus they add a feature to a language doesnt mean u have to use it While I absolutely agree with this in general, in practice with C++ if you're trying to use it safely you do in fact need to use those new features. But the old features are all still around too. It's a very, very large language in terms of mental space required these days.
ephimetheus 4y ago
In what world is C++ harder to learn than Rust?
- rufius 4y ago
  This world - the one you exist in right now. I say that as someone that wrote C++ for 10 years before moving to Rust. Rust was by far easier. That said - that’s an extremely biased statement and I recognize that. I think it was largely the compiler that helped make it easier.
  - juiiiced 4y ago
    I think have 10 more years of programming experience probably makes it easier to pick up a new language
  - Ygg2 4y ago
    I'd argue that your parent is right. In the superficial sense, of learn the syntax and can spit out code. That said code in C++ would just vomit cryptic messages about templates and SEGFAULT nearly all the time. What I'm trying to say skill floor - minimum skill/time needed to learn something to do it however in Rust is higher than C++. Although not in the sense of you must be this smart to enter, but you need this much time to learn it. If I can learn it, and I'm a mediocre programmer it's not an issue of skill. That said skill ceiling - skill needed to do it efficiently and without error is much higher in C++ than in Rust.
    - jamincan 4y ago
      Speaking as someone for whom programming is only ancillary to my job and who previously use python as my primary language, I wouldn't touch C/C++ with a 10-foot pole simply because I don't trust my own abilities to not screw it up and don't have the time to put into learning them to a level where I know I'm not. Things that Rust does that makes things easy for me as a less-experienced non-systems programmer: - very good documentation and compiler errors - cargo makes dependency management and distribution a breeze (big plus over python) - footguns are easily recognizable and avoided (unsafe) - strong typing allows me to express more invariants in the type system which makes my code easier to reason about (another big plus over python) The borrow checker can be an impediment at times and I'm probably leaving some performance at the door by generally avoiding references in data structures. I've found that this is less of a problem over time. It can also be way more verbose. But I have way more confidence that things will work at the end of the day, which makes it worthwhile for me, even if on the surface it is take longer and be harder to write than python.
fathrowaway12 4y ago
It's not _that_ complicated these days. structs, classes strings, vectors, hash maps, unique_ptr, references, non-owning pointers where it makes sense, basic templates. Boom. You also need basics like ownership, order of construction/destruction, value categories, move semantics, special member functions, RAII, etc. All the fancy perfect forwarding and template magic are wrapped up in libraries most don't need to think to hard about. Most people rarely write code that actually manages resource lifecycle directly. It's all wrapped up in RAII. If you read the whole spec, it looks super complicated. But getting to a mental model that works in 99% of cases is not _that_ hard.

everyone 4y ago

Just cus they add a feature to a language doesnt mean u have to use it. Though it does seem very few programmers are smart enough to stick to the most basic features whenever possible.

AtlasBarfed 4y ago
C++ the "language culture" unfortunately has a lot of gatekeeping as well. The fact that the gatekeeping generally revolves around "replace feature from n-5 years with the newer feature in the latest 0x00x release" is a bit tiresome. Yes, I'm exaggerating, a bit. As for the Microsoft whomever-he-is: I agree in theory, I disagree in practice. If there are a lot of C++ devs writing important code, then let them continue to do so in their prime language that they've invested decades of hard work keeping up with the feature treadmill. New devs? Only if you have to.
- einpoklum 4y ago
  > "replace feature from n-5 years with the newer feature in the latest 0x00x release" Let me put a more pro-C++ spin on that sentiment. C++ is a language that's under long-term development. It might sound weird, but only with C++20 Bjarne Stroustrup felt that his vision for the language was now mostly-realized - and he had worked on it since the 1980s. With other languages, there's a lot of clearing-of-the-desk and starting things anew, while C++ has opted for incremental changes with backwards compatibility to before it existed (i.e. C). But, looking back, we get the sentiment you describe. Which, rephrased, sounds like this: "Remember that annoying and ugly hack you had to use so far to get [complex thing] to work? Well, that finally got fixed. Now there's a shiny new language feature / standard library construct which does that more nicely. But your existing code will also work."
  - pjmlp 4y ago
    A vision that ironically is only fulfilled by Visual C++, and who knows when GCC and clang will manage to reach it, specially in what concerns modules.
  - the_arcadian 4y ago
    Agree 100%. The C++ language and ecosystem shouldn't feel dynamic, given its age and the installed base, and yet it really does. I remember when c++11 came out and all the crazy typedefs I had to type out just disappeared overnight, and I was able to write statements like "using Elem = uint64_t; using Node = MyClass::Node<Elem>;" which were so much more straightforward. Function pointers disappeared too and were replaced by lambdas so I could write my own "each_node" functions and actually have them be really useful. Then we had concurrency primitives, and now apparently there's a module system in c++20 which should be interesting. C++ clearly has no plans to bow out gracefully or otherwise go quietly into the night, which is fine by me since I still think it's the language which gives me, as a developer, the most freedom and control over the system.
  - AtlasBarfed 4y ago
    "but only with C++20 Bjarne Stroustrup felt that his vision for the language was now mostly-realized" So... let me ask you given this statement. Let's say there is an uber smart super productive programmer who states: I can rewrite the entirety of the ecosystem of one language in 1 year.... Would you tell them to rewrite all C/C++ in C++20 or Rewrite it in Rust? C++'s only real advantage in the current language marketplace is an installed library base. But how much of that is C++0x2020? Is the barrier to entry of a new programmer in C++ not just 40 years of language revisions, but a massive massive map of libraries where JSON library uses features from v2016, while XML library uses v2005, while some multithreading thing uses v2020... And then there's the STL, and mixed-in-C standard library, ye gods. Will Rust turn into that? Well, I think it kind of will to some degree as they try to find dialects that perfectly describe borrower checker semantics. Rust is a syntax soup almost on par with C++, but I guess we'll see.
    - einpoklum 4y ago
      > Would you tell them to rewrite all C/C++ in C++20 or Rewrite it in Rust? Neither. 1. I wouldn't trust a person who says something like that. It takes a programming luminary several years to write a good (non-trivial, not-tiny) library the community can get behind, and even that usually involves iterations of use, feedback and partial rewriting/redesign. 2. Why would we want a "rewrite of the entire ecosystem" (whatever that ecosystem may be) all at once? That's a fiasco waiting to happen. 3. An "ecosystem" very often needs to be at least somewhat backwards-compatible, so I wouldn't want it written in something that's just out of the nylons. Probably best to let that smart programmer write some decent foundational libraries which we can adopt one at a time, with increasing benefit of synergy. > C++'s only real advantage in the current language marketplace is an installed library base That seems untrue. C++ has various capabilities in different usage scenarios which other languages do not. But more importantly - programming languages don't all compete: They typically have different combinations of design goals. That's specifically true of C++ vs Rust. > But how much of that is C++0x2020? That doesn't matter much. For you, anything that's not written in the latest version of a language may be irrelevant/unusable. Not for the users of backwards (and forwards-) compatible languages like C, C++ and various others. > Is the barrier to entry of a new programmer in C++ not just 40 years of language revisions No, 40 years of revisions is not a barrier to entry. Your saying that makes it sound like you are not very familiar with the language. > mixed-in-C standard library, ye gods. double x = sqrt(x_squared); ... oh, the humanity! Who would ever write something like this? It's a non-polymorphic function and its symbol doesn't get mangled! Ye gods!
atomicnumber3 4y ago
One problem here is that everyone ends up with their own little niches of the language that they like, and nobody's code looks like anyone else's, and suddenly to read a codebase you do need to know huge swathes of the sprawling language. At lastjob, we did a lot of C++, and I could tell whose code I was reading without checking blame because I knew who liked what idioms and features.
- girvo 4y ago
  > One problem here is that everyone ends up with their own little niches of the language that they like Amusingly, this was always the criticism I've seen leveled at Lisps over the years. It's just as true in C++ for sure.
- pmontra 4y ago
  This is so true. Two examples. 1. I got a couple of downvotes a few days ago because I commented that I don't like the &s of Elixir (kind of shortcuts for 'fn x ->') and I prefer to write the full form as it's easier to read for everyone no matter how proficient in the language (zero to expert.) I also don't like and almost don't use the & shortcuts in Ruby (positional arguments.) 2. I got a customer recently with the lead developer fond of each_with_object. I never saw that in 17 years of Ruby and I had to check the reference. It's probably faster than the naive implementation (more time inside the C implementation doing real work vs inside the C parser?) but the naive one is immediately readable by anyone.
- GoblinSlayer 4y ago
  Wouldn't that mean there should be no competing crates, because people should write the same code for the same task?
girvo 4y ago
> Just cus they add a feature to a language doesnt mean u have to use it While I absolutely agree with this in general, in practice with C++ if you're trying to use it safely you do in fact need to use those new features. But the old features are all still around too. It's a very, very large language in terms of mental space required these days.

ephimetheus 4y ago

In what world is C++ harder to learn than Rust?

rufius 4y ago
This world - the one you exist in right now. I say that as someone that wrote C++ for 10 years before moving to Rust. Rust was by far easier. That said - that’s an extremely biased statement and I recognize that. I think it was largely the compiler that helped make it easier.
- juiiiced 4y ago
  I think have 10 more years of programming experience probably makes it easier to pick up a new language
- Ygg2 4y ago
  I'd argue that your parent is right. In the superficial sense, of learn the syntax and can spit out code. That said code in C++ would just vomit cryptic messages about templates and SEGFAULT nearly all the time. What I'm trying to say skill floor - minimum skill/time needed to learn something to do it however in Rust is higher than C++. Although not in the sense of you must be this smart to enter, but you need this much time to learn it. If I can learn it, and I'm a mediocre programmer it's not an issue of skill. That said skill ceiling - skill needed to do it efficiently and without error is much higher in C++ than in Rust.
  - jamincan 4y ago
    Speaking as someone for whom programming is only ancillary to my job and who previously use python as my primary language, I wouldn't touch C/C++ with a 10-foot pole simply because I don't trust my own abilities to not screw it up and don't have the time to put into learning them to a level where I know I'm not. Things that Rust does that makes things easy for me as a less-experienced non-systems programmer: - very good documentation and compiler errors - cargo makes dependency management and distribution a breeze (big plus over python) - footguns are easily recognizable and avoided (unsafe) - strong typing allows me to express more invariants in the type system which makes my code easier to reason about (another big plus over python) The borrow checker can be an impediment at times and I'm probably leaving some performance at the door by generally avoiding references in data structures. I've found that this is less of a problem over time. It can also be way more verbose. But I have way more confidence that things will work at the end of the day, which makes it worthwhile for me, even if on the surface it is take longer and be harder to write than python.

fathrowaway12 4y ago

It's not _that_ complicated these days. structs, classes strings, vectors, hash maps, unique_ptr, references, non-owning pointers where it makes sense, basic templates. Boom. You also need basics like ownership, order of construction/destruction, value categories, move semantics, special member functions, RAII, etc. All the fancy perfect forwarding and template magic are wrapped up in libraries most don't need to think to hard about. Most people rarely write code that actually manages resource lifecycle directly. It's all wrapped up in RAII. If you read the whole spec, it looks super complicated. But getting to a mental model that works in 99% of cases is not _that_ hard.