11 ms·

IMHO a similar point could be made about the C++ language spec, sadly.

BulgarianIdiot 3y ago
Same point can be made about anything. Never breaking BC is easier, and more comfortable, but in the end it's slow and inevitable death. If C++ would have cleaned up legacy, Rust wouldn't need to exist for ex. Java has long had a policy of never breaking BC, but few years ago they started marking packages deprecated for removal. They're very slow and systematic about it, as they should be, but the point is, eventually those packages will be removed. And that's good. It means Java has a future.
- stjohnswarts 3y ago
  Rust is still in the noise vs the amount of market share that C++ has. That said I love it as a language but it's hardly "taking over", I have tried to push it at my company a bit for command line utilities.
delta_p_delta_x 3y ago
There are similar efforts to revamp C++ or replace it with another language, too. Rust is a famous example; there's also Carbon[1] and cppfront[2]. Even so, this may be a controversial opinion, but with C++20, it has become fairly straightforward to program relatively safely and avoid some old footguns. [1]: https://github.com/carbon-language/carbon-lang https://github.com/carbon-language/carbon-lang [2]: https://github.com/hsutter/cppfront https://github.com/hsutter/cppfront
- FpUser 3y ago
  I use "modern C++" (a subset of it that suits my goals) and do not really have any real problems during last 3 years. My backend C++ application servers are running along just fine.
  - fwsgonzo 3y ago
    I have the same experience. All the tools at my disposal including mutrace for measuring contention, I just feel like C++ is a solid language. Sure, I wish there was more compile-time stuff, like the ability to force a function argument to be compile-time, but in my experience, modern compilers often have surprisingly deep reach, and you can expect much of your code to just be compiled away if written a certain way. I recently wrote a server-client framework from scratch and used protobuf for messaging. The server is heavily multi-threaded with a lot of complex asynchronous rules, and there are no issues. If anything, I would hope for more concurrency primitives, as the C++ standard library is very high quality, and I would like concurrent hash maps and such.
ilyt 3y ago
Yup, it's absolutely true, navigating to the "good parts" is a nightmare
FpUser 3y ago
Just don't use "legacy parts" and be happy. Backwards compatibility is a great asset. Alternatively do something like Google's Carbon. Seems like a great product. Just do not call it C++. If it gets accepted by wider community you would know you are on the right path.
- deleted 3y ago
  [deleted]
- CoastalCoder 3y ago
  > Just don't use "legacy parts" and be happy. Maybe that works for some new codebases. When you need to integrate with other code, you can't necessarily understand the code semantics without knowing a lot more of the spec. Also, I challenge any normal programmer to remember all of the "good" C++ rules regarding overload resolution in an arbitrary context.
  - FpUser 3y ago
    >"When you need to integrate with other code, you can't necessarily understand the code semantics without knowing a lot more of the spec." I mostly design and create new products but on some occasions I've had situations like this. There was not a single time that quick Google search and now ChatGPT did not shed the light. >"Also, I challenge any normal programmer to remember all of the "good" C++ rules regarding overload resolution in an arbitrary context." Knowing / remembering every nook and cranny does not make for a good programmer (except language experts who write standard libraries and design / implement language itself of course). There are way more important things to consider.
  - stjohnswarts 3y ago
    Luckily I'm only working on those code bases so I don't care if it causes other programmers' heartache. If you don't like your code base, then I swear it's never been easier to find a job on newer code bases.

Same point can be made about anything. Never breaking BC is easier, and more comfortable, but in the end it's slow and inevitable death. If C++ would have cleaned up legacy, Rust wouldn't need to exist for ex. Java has long had a policy of never breaking BC, but few years ago they started marking packages deprecated for removal. They're very slow and systematic about it, as they should be, but the point is, eventually those packages will be removed. And that's good. It means Java has a future.

stjohnswarts 3y ago
Rust is still in the noise vs the amount of market share that C++ has. That said I love it as a language but it's hardly "taking over", I have tried to push it at my company a bit for command line utilities.

delta_p_delta_x 3y ago

There are similar efforts to revamp C++ or replace it with another language, too. Rust is a famous example; there's also Carbon[1] and cppfront[2]. Even so, this may be a controversial opinion, but with C++20, it has become fairly straightforward to program relatively safely and avoid some old footguns. [1]: https://github.com/carbon-language/carbon-lang https://github.com/carbon-language/carbon-lang [2]: https://github.com/hsutter/cppfront https://github.com/hsutter/cppfront

FpUser 3y ago
I use "modern C++" (a subset of it that suits my goals) and do not really have any real problems during last 3 years. My backend C++ application servers are running along just fine.
- fwsgonzo 3y ago
  I have the same experience. All the tools at my disposal including mutrace for measuring contention, I just feel like C++ is a solid language. Sure, I wish there was more compile-time stuff, like the ability to force a function argument to be compile-time, but in my experience, modern compilers often have surprisingly deep reach, and you can expect much of your code to just be compiled away if written a certain way. I recently wrote a server-client framework from scratch and used protobuf for messaging. The server is heavily multi-threaded with a lot of complex asynchronous rules, and there are no issues. If anything, I would hope for more concurrency primitives, as the C++ standard library is very high quality, and I would like concurrent hash maps and such.

ilyt 3y ago

Yup, it's absolutely true, navigating to the "good parts" is a nightmare

FpUser 3y ago

Just don't use "legacy parts" and be happy. Backwards compatibility is a great asset. Alternatively do something like Google's Carbon. Seems like a great product. Just do not call it C++. If it gets accepted by wider community you would know you are on the right path.

deleted 3y ago
[deleted]
CoastalCoder 3y ago
> Just don't use "legacy parts" and be happy. Maybe that works for some new codebases. When you need to integrate with other code, you can't necessarily understand the code semantics without knowing a lot more of the spec. Also, I challenge any normal programmer to remember all of the "good" C++ rules regarding overload resolution in an arbitrary context.
- FpUser 3y ago
  >"When you need to integrate with other code, you can't necessarily understand the code semantics without knowing a lot more of the spec." I mostly design and create new products but on some occasions I've had situations like this. There was not a single time that quick Google search and now ChatGPT did not shed the light. >"Also, I challenge any normal programmer to remember all of the "good" C++ rules regarding overload resolution in an arbitrary context." Knowing / remembering every nook and cranny does not make for a good programmer (except language experts who write standard libraries and design / implement language itself of course). There are way more important things to consider.
- stjohnswarts 3y ago
  Luckily I'm only working on those code bases so I don't care if it causes other programmers' heartache. If you don't like your code base, then I swear it's never been easier to find a job on newer code bases.