5 ms·

I often feel that when C++ posts come up, the majority of commenters are people who haven't deeply worked with C++, and there's several things people always mis

by wsve 2y ago

I often feel that when C++ posts come up, the majority of commenters are people who haven't deeply worked with C++, and there's several things people always miss when talking about it: - If you're working in a large C++ code base, you are stuck working with C++. There is no migrating to something like Rust. The overhead of training your engineers in a new language, getting familiar with a new tool chain, working with a new library ecosystem, somehow finding a way to transition your code so it works with existing C++ code and isn't buggy and adapts to the new paradigms is all extremely expensive. It will grind your product's development to a buggy halt. It's a bad idea. - Every time a new set of features (e.g. reflection, concepts, modules, etc.) is released, people bemoan how complicated C++ continues getting. But the committee isn't adding features for the sake of adding features, they're adding features because people are asking for them, they're spending years of their lives writing papers for the committee trying to improve the language so everyone can write better code. What you find horrifying new syntax, I find a great way of fixing a problem I've been dealing with for years. - Yes, it's a gross homunculus of a language. If I could switch our team to Rust without issues, I would in a heartbeat. But this is the beast we married. It has many warts, but it's still an incredible tool, with an amazingly hard working community, and I'm proud of that.

nuancebydefault 2y ago
> What you find horrifying new syntax, I find a great way of fixing a problem I've been dealing with for years. To prove you are not 'boosting'... could you give a convincing example?
- wsve 2y ago
  Not familiar with "boosting", but I'm definitely a fan of concepts and reflection. Reflection is absolutely gonna feel completely alien to people for a while, but there's a lot of areas in our codebase where I wish I could simply describe a data layout and have the efficient code generated for me instead of writing tons of boilerplate. Take JSON serialization for example. Currently, you have to write your (de)serialization by hand, but with the new reflection stuff one could do it based on a struct's members, and with less error. It'll be wonderful for writing new libraries that will make our lives easier.
  - nuancebydefault 2y ago
    Thanks for your feedback! It would be great to have reflection in C++,I did not know it was on the radar! Is there a compiler that supports it currently?
  - jcelerier 2y ago
    Check out boost.pfr, it gets you there for a lot of cases. Here's a library I built with it: https://github.com/celtera/avendish https://github.com/celtera/avendish It's a proper quantum leap compared to pre-reflection
pjmlp 2y ago
Case in point, until Rust is fully bootstrapped, even in an ideal world C++ would still be around. Then there are all those industry standards whose definitions are only available in C, and eventually C++. Likewise when I need to plug into JVM, CLR, V8, ART runtimes, I am reaching for C++, no need to introduce another layer into the sandwich, in terms of build tools, IDE tooling and stuff to debug.
jvanderbot 2y ago
Another point is ecosystem. Imagine you trained your whole team on Rust and got the entire codebase scrapped. Now you have to actually go and rewrite all your upstream dependencies. Each library, infra integration, algorithm, data structure, etc. Then, you gotta hire new people when those leave, and the rust hiring ecosystem is also just not there yet. I worked mostly in robotics. Literally everything is cpp. All the grad students know it. Ros is there setting the mental models for better or worse. The list goes on.
- sqeaky 2y ago
  You have really strong points on hiring, but the notion that you need to rewrite all your dependencies pretty weak. Nearly every modern language includes facilities for writing findings and I do believe that there are Rust to C++ binding tools.
  - jvanderbot 2y ago
    This is true in theory, but in practice is a nightmare. YMMV, but even small bits of python, Go, or (yes) Rust that have crept into the robotics stacks at the various places I've worked have created problems for incoming new-hires, or for maintenance even for senior folks. Python less so than others, but python is challenging to deploy on vehicle, b/c of various hard and soft problems. In particular, Rust interop with CPP is poor. Should I recompile all ros packages to allow me to call a few things in Rust? Not at this time. I'm hopeful for the "Rust is robotics" movement, however https://robotics.rs/ https://robotics.rs/ The state of the field is so entrenched in CPP though there's more hope in embedded land with the widespread use of C.
    - leoh 2y ago
      imo the issue is that doing academic training in robotics means doing whatever your advisor tells you to do and playing the academic rat-race game OR working in industry churning out features as fast as possible to keep your company alive, which essentially means that you are not going to be able to spend any meaningful time learning how to do FFI in Rust or Python or whatever. I think that's the real reason robotics software is in the dark ages. But then again, I'm not in the field and this is an armchair take. So yeah.
Remnant44 2y ago
It's basically like clockwork - you can assume that any post about c++ language evolution is going to have a number of people saying one or all of the following : 1) "CPP keeps getting complex in useless ways. Just use C (maybe C with classes style)". This viewpoint is correct in the sense that modern CPP is essentially a different language than C++98. But I disagree with the rest incredibly strongly - modern C++ is more expressive, safer, and often more performant than the old-school style. Things like unique_ptr, string_view/spans, RAII, etc are very useful and reduce boilerplate code as well as manage complexity. 2) "CPP is garbage, use Rust instead". I have not personally written in Rust, but I do find it to be a very interesting language. I would consider very strongly writing a new project in Rust. But most C++ projects are not new, and although us nerds always love rewriting perfectly working code, it's a good way to shoot your business in the foot. 3) "The template system is obscene". I mean, this is true. :) I do occasionally sprinkle metaprogramming into my code, because it solves some problems incredibly well. But it is essentially a different language grafted on at compile time. if constexpr, concepts, etc help enormously with this problem. And yes, those have all been introduced very recently...

by wsve 2y ago

nuancebydefault 2y ago

> What you find horrifying new syntax, I find a great way of fixing a problem I've been dealing with for years. To prove you are not 'boosting'... could you give a convincing example?

wsve 2y ago
Not familiar with "boosting", but I'm definitely a fan of concepts and reflection. Reflection is absolutely gonna feel completely alien to people for a while, but there's a lot of areas in our codebase where I wish I could simply describe a data layout and have the efficient code generated for me instead of writing tons of boilerplate. Take JSON serialization for example. Currently, you have to write your (de)serialization by hand, but with the new reflection stuff one could do it based on a struct's members, and with less error. It'll be wonderful for writing new libraries that will make our lives easier.
- nuancebydefault 2y ago
  Thanks for your feedback! It would be great to have reflection in C++,I did not know it was on the radar! Is there a compiler that supports it currently?
- jcelerier 2y ago
  Check out boost.pfr, it gets you there for a lot of cases. Here's a library I built with it: https://github.com/celtera/avendish https://github.com/celtera/avendish It's a proper quantum leap compared to pre-reflection

pjmlp 2y ago

Case in point, until Rust is fully bootstrapped, even in an ideal world C++ would still be around. Then there are all those industry standards whose definitions are only available in C, and eventually C++. Likewise when I need to plug into JVM, CLR, V8, ART runtimes, I am reaching for C++, no need to introduce another layer into the sandwich, in terms of build tools, IDE tooling and stuff to debug.

jvanderbot 2y ago

Another point is ecosystem. Imagine you trained your whole team on Rust and got the entire codebase scrapped. Now you have to actually go and rewrite all your upstream dependencies. Each library, infra integration, algorithm, data structure, etc. Then, you gotta hire new people when those leave, and the rust hiring ecosystem is also just not there yet. I worked mostly in robotics. Literally everything is cpp. All the grad students know it. Ros is there setting the mental models for better or worse. The list goes on.

sqeaky 2y ago
You have really strong points on hiring, but the notion that you need to rewrite all your dependencies pretty weak. Nearly every modern language includes facilities for writing findings and I do believe that there are Rust to C++ binding tools.
- jvanderbot 2y ago
  This is true in theory, but in practice is a nightmare. YMMV, but even small bits of python, Go, or (yes) Rust that have crept into the robotics stacks at the various places I've worked have created problems for incoming new-hires, or for maintenance even for senior folks. Python less so than others, but python is challenging to deploy on vehicle, b/c of various hard and soft problems. In particular, Rust interop with CPP is poor. Should I recompile all ros packages to allow me to call a few things in Rust? Not at this time. I'm hopeful for the "Rust is robotics" movement, however https://robotics.rs/ https://robotics.rs/ The state of the field is so entrenched in CPP though there's more hope in embedded land with the widespread use of C.
  - leoh 2y ago
    imo the issue is that doing academic training in robotics means doing whatever your advisor tells you to do and playing the academic rat-race game OR working in industry churning out features as fast as possible to keep your company alive, which essentially means that you are not going to be able to spend any meaningful time learning how to do FFI in Rust or Python or whatever. I think that's the real reason robotics software is in the dark ages. But then again, I'm not in the field and this is an armchair take. So yeah.

Remnant44 2y ago

It's basically like clockwork - you can assume that any post about c++ language evolution is going to have a number of people saying one or all of the following : 1) "CPP keeps getting complex in useless ways. Just use C (maybe C with classes style)". This viewpoint is correct in the sense that modern CPP is essentially a different language than C++98. But I disagree with the rest incredibly strongly - modern C++ is more expressive, safer, and often more performant than the old-school style. Things like unique_ptr, string_view/spans, RAII, etc are very useful and reduce boilerplate code as well as manage complexity. 2) "CPP is garbage, use Rust instead". I have not personally written in Rust, but I do find it to be a very interesting language. I would consider very strongly writing a new project in Rust. But most C++ projects are not new, and although us nerds always love rewriting perfectly working code, it's a good way to shoot your business in the foot. 3) "The template system is obscene". I mean, this is true. :) I do occasionally sprinkle metaprogramming into my code, because it solves some problems incredibly well. But it is essentially a different language grafted on at compile time. if constexpr, concepts, etc help enormously with this problem. And yes, those have all been introduced very recently...