9 ms·

It's really crazy how much C++ has already evolved since the start of my career (with C++98). C++ has been the millennium falcon of languages; creaky and old, n

It's really crazy how much C++ has already evolved since the start of my career (with C++98). C++ has been the millennium falcon of languages; creaky and old, not pretty to look at, but still good where it counts. That said, I completely switched over to rust many months ago and rarely look back. Rust is a tribute to C++, an incorporation of lessons learned that sheds all of the baggage C++ will never be rid of. Rust also has less of learning curve than C++ (although both are quite high), simply because C++ has so many odds and ends to keep track of these days. Rust has also made me realize how bad class based OO is as an abstraction. OO glues together operator overloading, methods, inheritance, all into one package. Rust breaks those concepts into component parts that provide much better abstractions with less keywords and jargon to worry about.

kbwt 8y ago
I've personally been watching Rust from the sidelines. I am still waiting for a language to tackle excessive compile and link times.
- monetus 8y ago
  I've not used it for anything too big, but D compiles incredibly fast.
  - kbwt 8y ago
    Recent article regarding D compile times: https://blog.thecybershadow.net/2018/11/18/d-compilation-is-too-slow-and-i-am-forking-the-compiler/ https://blog.thecybershadow.net/2018/11/18/d-compilation-is-...
  - gmueckl 8y ago
    It is very fast for certain projects, but link times on some can make up for that. I have a toy program using vibe.d that takes around 1s to compile and 10s to link. I could probably make that faster by switching to gold, but I didn't yet.
    - e12e 8y ago
      I'm not sure how anything over 100ms could be considered "fast compile" for a toy program... Basically Pascal, or simple c compilers like tcc should be the benchmark imnho. That's not to say I don't allow for trade-offs.. I gladly trade some milliseconds (or, grudgingly seconds) for features.
      - gmueckl 8y ago
        Most of the compile time of that particular program is spent parsing HTML templates and converting them to D code. This is all done by D code provided by a library that runs at compile time as part of a template function instantiation in my code. So the compile time is inflated a bit in this case.
  - kbwt 8y ago
    On big projects, linking times are really the bottleneck. Sure, incremental linkers exist [1], but all of them tend to do O(n) work on every invocation. Source control software, even developed explicitly to scale [2], behaves the same way. Makefiles as well; Tup [3] tries to solve this, in vain since the linking step is still holding everything up. There is so much inherent inability to scale built into our tools. So on big projects everything grinds to a halt as you cannot buy enough developers and hardware to keep up with O(n^2) forever. [1] MSVC cl, GNU gold [2] git: http://lkml.iu.edu/hypermail/linux/kernel/0504.0/2022.html http://lkml.iu.edu/hypermail/linux/kernel/0504.0/2022.html [3] tup: http://gittup.org/tup/manual.html http://gittup.org/tup/manual.html
    - earenndil 8y ago
      This can be solved by putting individual components into shared libraries.
      - kbwt 8y ago
        But then you pay the cost every single time on startup, unless your components barely interact.
- Jach 8y ago
  Nim compiles to C, so can at least make use of fast C compilers. But the solution really seems to be to just use a fully dynamic language like Common Lisp that can compile, load, and redefine (hotswap) everything incrementally so you're not having to start from nothing all the time.
  - jstimpfle 8y ago
    Compiling to C is not a compile performance advantage. If anything it slows you down as described in the article (header files). It's just not as bad as C++.
- e12e 8y ago
  Object Pascal? I guess Ada also has pretty good compile times - but I'm not sure if the Pascal heritage stretches to modules/compilation.
ThrowawayR2 8y ago
I cut my teeth writing very C-ish C++98 for an embedded system in the '90s and the C++20 ranges example code from the blog might as well have been in an entirely different language. Sadly, I may have to stop listing C++ as a language I'm familiar with on my resume.
- Jach 8y ago
  I changed my resume to list "C++98" instead of "C++" a few years ago. But I could probably just leave it off entirely as I endeavor to write as little C++ as possible... JavaScript is getting the same way.
- gnulinux 8y ago
  I write very C-ish C++17, that is, C + constexpr + a very restricted subset of templates (you can only use integral types as arguments). No template metaprogramming, ever. By extension you're also not allowed to use _Generic macro of the new C standard, if you absolutely absolutely must use it, then use C++ template. Metaprogramming with constexpr, static if etc is fair game. No class methods, just use C style POD with functions. You cannot use references (just pointers). You're not allowed to use any C++ library, but any C library is fair game. This works really well in practice for us. We use GCC to compile.
  - taneq 8y ago
    After a foray into C++-ish C++ I also write fairly C-ish C++. I see it as being like walking into an armoury and being able to choose anything you want. Chances are, if you want to resolve a domestic dispute, you don't want a claymore. Or a Howitzer. Or an aircraft carrier, or a lump of unshielded semi-critical plutonium. But that's OK, you don't have to choose them. You can walk right past those shelves to the shelf with the megaphone and the padded vest, and just take those. That's how you program with C++.
    - blattimwind 8y ago
      > I see it as being like walking into an armoury and being able to choose anything you want. Chances are, if you want to resolve a domestic dispute, you don't want a claymore. Or a Howitzer. Or an aircraft carrier, or a lump of unshielded semi-critical plutonium. But that's OK, you don't have to choose them. You can walk right past those shelves to the shelf with the megaphone and the padded vest, and just take those. Is this an Ammu-Nation ad? :)
hliyan 8y ago
I too started my career with C++ (and spent 10 years using it almost exclusively, before moving to JS some time back). The first code block in the article made my jaw drop, and my first thought was "what the hell has happened to C++? I was only away for 5 years". Then I saw the "simple style" example and breathed a sigh of relief. That is the C/C++ I recognize. Even the third example with structs is not necessary. The author is right. Sometimes reusability is overrated. Duplication is better than the wrong abstraction.
- SolarNet 8y ago
  Yea, but the struct example delivers on the idea of reusability (where the pythagorean triples algorithm is a stand in for some complicated algorithm) in any situation where this might apply. It's a useful answer to the point: Well what if it was 15 for loops with a bunch of esoteric function calls. The struct example would still be better.
auxym 8y ago
I'm not sure why anyone today would start a greenfield project in C++ instead of D, rust or Nim. Maybe in niches where C++ is deeply rooted, like games.
- 21 8y ago
  For one thing, there are many more C++ programmers out thare than D or Rust. And nobody heard of Nim.
- throwawaymath 8y ago
  I've never heard of Nim. Is this it: https://nim-lang.org https://nim-lang.org? Why would you choose Nim over C++?
- shaklee3 8y ago
  In many ways, it's about being the first to do something. I write a lot of code around DPDK for packet processing. It's a pure C library. I know rust has good C bindings, but I heard Go did as well. I started a project in go using cgo for the dpdk parts. What a nightmare. I spent more time figuring out the idiosyncrasies of cgo than actually writing useful code. And in many cases, cgo couldn't actually do what I needed to do. I had to write some functions and see inside of the .go file. I'm sure rust would have been easier to call C with since the languages bare inherently more compatible, but I don't want to go down that path again right now.
  - nickpsecurity 8y ago
    The Go language has weak, C interoperability. The parents are strong in it. You wouldnt be going down same path. More like the opposite one that is closer to your actual goals. I recommend Rust or D for your next try since compiler quality is best for those. D will be easiest to learn. You can always use unsafe in either if memory management gets in way.
- FartyMcFarter 8y ago
  Because C++ is a stable, reliable and well supported (read: production-ready) language that works on many platforms. Last I heard D was definitely not all of those (it doesn't even have a straight story on garbage collection, as its creator said himself! [1]), and I'm not sure about Rust or Nim. [1] https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Andrei-Alexandrescu https://www.quora.com/Which-language-has-the-brightest-futur...
zozbot123 8y ago
I don't think Rust has anything comparable to implementation inheritance like C++ has? Getting implementation inheritance from pure composition is essentially a "tying the knot" exercise, where you must ensure that "virtual" method calls are always dispatched on through something like an existential type, so that they can reach the right implementation for the actual "child" object. (The right question to ask is "when do we actually need this, ffs?" Almost never, as it turns out - it's just needless complexity. Hence, "prefer composition over inheritance!")
notacoward 8y ago
> It's really crazy how much C++ has already evolved To borrow an old bit of snark: I don't know what the "default" programming language of 2025 will look like, but I know it will be called C++. Like Ethernet (the original subject of that snark), C++ has evolved into a form unrecognizable to those who saw its birth. Unlike Ethernet, the older forms haven't gone away. They still reappear often in large/old/important codebases, keeping compiler writers busy and everyone else less productive. I'm generally the last person to suggest replacing things that already work, but C++ really does just need to get paved over.
- blub 8y ago
  OP has been proselytizing Rust on HN like it's the new coming of the Messiah. This kind of language advertising where one can't even bother mentioning one negative thing about the product is sad but effective, because people want to believe that there's a perfect language out there...
  - aldanor 8y ago
    My personal view: C++ has issues and problems because it's too old and it's not going to get rid of the old baggage, hence it will have to carry it forward while adding new stuff on top (concepts, ranges...). Those issues are not going away, they will only get worse over time. Rust has different kinds of issues and problems because it's still relatively young. For instance, pretty bad compile times (even compared to C++ with heavy templates use). But that's solvable, it will just take time. Most issues with the language itself that I've personally encountered were of the kind "it's not stabilized yet" or "it's not fully implemented yet".
  - notacoward 8y ago
    > OP has been proselytizing Rust on HN like it's the new coming of the Messiah. That doesn't even come close to being relevant. Address the argument, not the person.
    - blub 8y ago
      Correcting the same misleading statements over and over again is a chat bot's job and not an enjoyable task for a human being. I was just pointing out that you're probably wasting your time, but you're of course free to discuss the finer points of class-based OO or Rust's learning curve for the Nth time, if you're so inclined.

kbwt 8y ago

I've personally been watching Rust from the sidelines. I am still waiting for a language to tackle excessive compile and link times.

monetus 8y ago
I've not used it for anything too big, but D compiles incredibly fast.
- kbwt 8y ago
  Recent article regarding D compile times: https://blog.thecybershadow.net/2018/11/18/d-compilation-is-too-slow-and-i-am-forking-the-compiler/ https://blog.thecybershadow.net/2018/11/18/d-compilation-is-...
- gmueckl 8y ago
  It is very fast for certain projects, but link times on some can make up for that. I have a toy program using vibe.d that takes around 1s to compile and 10s to link. I could probably make that faster by switching to gold, but I didn't yet.
  - e12e 8y ago
    I'm not sure how anything over 100ms could be considered "fast compile" for a toy program... Basically Pascal, or simple c compilers like tcc should be the benchmark imnho. That's not to say I don't allow for trade-offs.. I gladly trade some milliseconds (or, grudgingly seconds) for features.
    - gmueckl 8y ago
      Most of the compile time of that particular program is spent parsing HTML templates and converting them to D code. This is all done by D code provided by a library that runs at compile time as part of a template function instantiation in my code. So the compile time is inflated a bit in this case.
- kbwt 8y ago
  On big projects, linking times are really the bottleneck. Sure, incremental linkers exist [1], but all of them tend to do O(n) work on every invocation. Source control software, even developed explicitly to scale [2], behaves the same way. Makefiles as well; Tup [3] tries to solve this, in vain since the linking step is still holding everything up. There is so much inherent inability to scale built into our tools. So on big projects everything grinds to a halt as you cannot buy enough developers and hardware to keep up with O(n^2) forever. [1] MSVC cl, GNU gold [2] git: http://lkml.iu.edu/hypermail/linux/kernel/0504.0/2022.html http://lkml.iu.edu/hypermail/linux/kernel/0504.0/2022.html [3] tup: http://gittup.org/tup/manual.html http://gittup.org/tup/manual.html
  - earenndil 8y ago
    This can be solved by putting individual components into shared libraries.
    - kbwt 8y ago
      But then you pay the cost every single time on startup, unless your components barely interact.
Jach 8y ago
Nim compiles to C, so can at least make use of fast C compilers. But the solution really seems to be to just use a fully dynamic language like Common Lisp that can compile, load, and redefine (hotswap) everything incrementally so you're not having to start from nothing all the time.
- jstimpfle 8y ago
  Compiling to C is not a compile performance advantage. If anything it slows you down as described in the article (header files). It's just not as bad as C++.
e12e 8y ago
Object Pascal? I guess Ada also has pretty good compile times - but I'm not sure if the Pascal heritage stretches to modules/compilation.

ThrowawayR2 8y ago

I cut my teeth writing very C-ish C++98 for an embedded system in the '90s and the C++20 ranges example code from the blog might as well have been in an entirely different language. Sadly, I may have to stop listing C++ as a language I'm familiar with on my resume.

Jach 8y ago
I changed my resume to list "C++98" instead of "C++" a few years ago. But I could probably just leave it off entirely as I endeavor to write as little C++ as possible... JavaScript is getting the same way.
gnulinux 8y ago
I write very C-ish C++17, that is, C + constexpr + a very restricted subset of templates (you can only use integral types as arguments). No template metaprogramming, ever. By extension you're also not allowed to use _Generic macro of the new C standard, if you absolutely absolutely must use it, then use C++ template. Metaprogramming with constexpr, static if etc is fair game. No class methods, just use C style POD with functions. You cannot use references (just pointers). You're not allowed to use any C++ library, but any C library is fair game. This works really well in practice for us. We use GCC to compile.
- taneq 8y ago
  After a foray into C++-ish C++ I also write fairly C-ish C++. I see it as being like walking into an armoury and being able to choose anything you want. Chances are, if you want to resolve a domestic dispute, you don't want a claymore. Or a Howitzer. Or an aircraft carrier, or a lump of unshielded semi-critical plutonium. But that's OK, you don't have to choose them. You can walk right past those shelves to the shelf with the megaphone and the padded vest, and just take those. That's how you program with C++.
  - blattimwind 8y ago
    > I see it as being like walking into an armoury and being able to choose anything you want. Chances are, if you want to resolve a domestic dispute, you don't want a claymore. Or a Howitzer. Or an aircraft carrier, or a lump of unshielded semi-critical plutonium. But that's OK, you don't have to choose them. You can walk right past those shelves to the shelf with the megaphone and the padded vest, and just take those. Is this an Ammu-Nation ad? :)

hliyan 8y ago

I too started my career with C++ (and spent 10 years using it almost exclusively, before moving to JS some time back). The first code block in the article made my jaw drop, and my first thought was "what the hell has happened to C++? I was only away for 5 years". Then I saw the "simple style" example and breathed a sigh of relief. That is the C/C++ I recognize. Even the third example with structs is not necessary. The author is right. Sometimes reusability is overrated. Duplication is better than the wrong abstraction.

SolarNet 8y ago
Yea, but the struct example delivers on the idea of reusability (where the pythagorean triples algorithm is a stand in for some complicated algorithm) in any situation where this might apply. It's a useful answer to the point: Well what if it was 15 for loops with a bunch of esoteric function calls. The struct example would still be better.

auxym 8y ago

I'm not sure why anyone today would start a greenfield project in C++ instead of D, rust or Nim. Maybe in niches where C++ is deeply rooted, like games.

21 8y ago
For one thing, there are many more C++ programmers out thare than D or Rust. And nobody heard of Nim.
throwawaymath 8y ago
I've never heard of Nim. Is this it: https://nim-lang.org https://nim-lang.org? Why would you choose Nim over C++?
shaklee3 8y ago
In many ways, it's about being the first to do something. I write a lot of code around DPDK for packet processing. It's a pure C library. I know rust has good C bindings, but I heard Go did as well. I started a project in go using cgo for the dpdk parts. What a nightmare. I spent more time figuring out the idiosyncrasies of cgo than actually writing useful code. And in many cases, cgo couldn't actually do what I needed to do. I had to write some functions and see inside of the .go file. I'm sure rust would have been easier to call C with since the languages bare inherently more compatible, but I don't want to go down that path again right now.
- nickpsecurity 8y ago
  The Go language has weak, C interoperability. The parents are strong in it. You wouldnt be going down same path. More like the opposite one that is closer to your actual goals. I recommend Rust or D for your next try since compiler quality is best for those. D will be easiest to learn. You can always use unsafe in either if memory management gets in way.
FartyMcFarter 8y ago
Because C++ is a stable, reliable and well supported (read: production-ready) language that works on many platforms. Last I heard D was definitely not all of those (it doesn't even have a straight story on garbage collection, as its creator said himself! [1]), and I'm not sure about Rust or Nim. [1] https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Andrei-Alexandrescu https://www.quora.com/Which-language-has-the-brightest-futur...

zozbot123 8y ago

I don't think Rust has anything comparable to implementation inheritance like C++ has? Getting implementation inheritance from pure composition is essentially a "tying the knot" exercise, where you must ensure that "virtual" method calls are always dispatched on through something like an existential type, so that they can reach the right implementation for the actual "child" object. (The right question to ask is "when do we actually need this, ffs?" Almost never, as it turns out - it's just needless complexity. Hence, "prefer composition over inheritance!")

notacoward 8y ago

> It's really crazy how much C++ has already evolved To borrow an old bit of snark: I don't know what the "default" programming language of 2025 will look like, but I know it will be called C++. Like Ethernet (the original subject of that snark), C++ has evolved into a form unrecognizable to those who saw its birth. Unlike Ethernet, the older forms haven't gone away. They still reappear often in large/old/important codebases, keeping compiler writers busy and everyone else less productive. I'm generally the last person to suggest replacing things that already work, but C++ really does just need to get paved over.

blub 8y ago
OP has been proselytizing Rust on HN like it's the new coming of the Messiah. This kind of language advertising where one can't even bother mentioning one negative thing about the product is sad but effective, because people want to believe that there's a perfect language out there...
- aldanor 8y ago
  My personal view: C++ has issues and problems because it's too old and it's not going to get rid of the old baggage, hence it will have to carry it forward while adding new stuff on top (concepts, ranges...). Those issues are not going away, they will only get worse over time. Rust has different kinds of issues and problems because it's still relatively young. For instance, pretty bad compile times (even compared to C++ with heavy templates use). But that's solvable, it will just take time. Most issues with the language itself that I've personally encountered were of the kind "it's not stabilized yet" or "it's not fully implemented yet".
- notacoward 8y ago
  > OP has been proselytizing Rust on HN like it's the new coming of the Messiah. That doesn't even come close to being relevant. Address the argument, not the person.
  - blub 8y ago
    Correcting the same misleading statements over and over again is a chat bot's job and not an enjoyable task for a human being. I was just pointing out that you're probably wasting your time, but you're of course free to discuss the finer points of class-based OO or Rust's learning curve for the Nth time, if you're so inclined.