12 ms·

To the people who work on C++ standards: I approve of the current C++ trajectory and please ignore all of the online noise about "the future of C++." To anyone

To the people who work on C++ standards: I approve of the current C++ trajectory and please ignore all of the online noise about "the future of C++." To anyone that disagrees severely with the C++ trajectory as stated, please just consider another language, e.g. Rust. I don't want static lifetime checking in C++ and if you want static lifetime checking, please use Rust. I am not a government contractor, if you are a government contractor who must meet bureaucratic risk-averse government requirements, please use Rust. I have an existing development process that works for me and my customers, I have no significant demand for lifetime checking. If your development process is shiny and new and necessitates lifetime checking, then please use Rust. To Rust advocates, you can have the US government and big tech. You can even have Linux. Just leave my existing C++ process alone. It works and the trade offs we have chosen efficiently accomplish our goals.

lubesGordi 2y ago
I don't know enough about what it would take to implement static lifetime checking. Is that fundamentally impossible to do in a backwards compatible way?
- steveklabnik 2y ago
  It depends on what you mean by "backwards compatible," and what you mean by "static lifetime checking" :) The profiles proposal suggests adding static lifetime checking, "without viral annotations." I use quotations because I don't really agree with this framing, but whatever. The paper is here if you'd like to read it yourself: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3081r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p30... The core idea here is that you add annotations to opt in or out of certain checks. And opting in may be a compiler flag, requiring no changes to source code. So that would be "backwards compatibility" in that sense. Of course, code may fail these checks, so you'll have to add annotations to opt out, or re-write the code. We will see in practice how much change is required once implementations exist and are tried out. But the other part is, these profiles do not attempt to cover all valid cases. And what I mean by that is, there are some lifetime issues that this proposal does not attempt to analyze. And, where the analysis is similar, they offer a subset of what other proposals do. These decisions were made because the authors believe that they'll reduce a significant number of issues, and are easier to adopt. And that's worth it instead of going for more checks. The competing proposal, Safe C++, has you opt into safety checks on a file-per-file basis. So in that sense, it is also backwards compatible: all existing code compiles as-is. When you opt in to those checks, it adds new syntax, similar to Rust, to do the safety analysis checks. So you gain this benefit for only new code, but it also you get much more power. This syntax is necessary to communicate programmer intent to the checks, but is the "viral annotations" that the proponents of profiles don't like. So, basically, that's the thing: both are backwards compatible, but offer very different tradeoffs in the design space.
- aiono 2y ago
  If you want alias tracking and lifetime checking, yes they are backwards incompatible. They need "viral annotations" if we speak with the C++ committee terminology.
mempko 2y ago
This! The hardest part of making software is making something that works for people. What I love about C++ is multi-paradigm programming. I can express my ideas directly using the appropriate paradigms. Regarding safety, with modern C++ programming, it's not hard to write software that's correct. Safety is often never the first thing I worry about. If having strict safety means I can't express my mental models in code, I don't want it. It will slow me down. It will make it harder to write software that's useful. Remember people, we are here to make things that are useful to people. If safety gets in the way of that, then it's not worth it.
aiono 2y ago
You frame it like "Rust advocates" try to infiltrate into C++ language decision making and inject safety features into it. That's not the case at all. For years C++ committee simply ignored the need for safety and they didn't take Rust and lifetime analysis seriously. But now they themselves want it.
einpoklum 2y ago
> I approve of the current C++ trajectory But this isn't one thing. Part of the problem is contradictions even in the definition of this trajectory. An important example: Will it be "you don't pay for what you don't use", or will it be "stable ABI"? There are adopted papers which say both - as the linked article indicates. > please just consider another language, e.g. Rust I'm not one of those people necessarily, but - Rust has its own set of design goals and problems. It is legitimate to want C++ to go one way rather than another. > To Rust advocates, you can have the US government and big tech. Now you are kind of contradicting yourself, because wide applicability is definitely a goal for C++.
AlotOfReading 2y ago
C++ has lifetime rules just like Rust. They're simply implicit in the code and not enforced by the compiler. Do you prefer the uncertainty of silent miscompilations and undefined behavior to upfront compiler errors? You're already using a language with a strong type system, so it's confusing to me why you would choose to draw the line here.
- bagxrvxpepzn 2y ago
  > Do you prefer the uncertainty of silent miscompilations and undefined behavior to upfront compiler errors? Yes because then I don't have to spend hours writing esoteric spaghetti code to prove something to the compiler that is trivially known to be true. Your error is assuming static lifetime checking is free. As an engineer, I use judgement to make context-dependent trade offs. If you like playing the compiler olympics, or your employer forces you to, please use Rust.
  - zozbot234 2y ago
    "Trivially known to be true" until the code evolves making your unstated assumptions not hold and everything breaks, often in complex and unintuitive ways involving interactions across modules. This is why these automated soundness checks are valuable.
    - restalis 2y ago
      "until the code evolves [...]" That is already a desirable place to be, where you managed to get a working implementation ready to evolve. My issue with opinionated languages like Rust is that they make development more expensive. I then afford to pay the necessary work-effort for fewer projects than I otherwise could if I was to focus more on the problem(s) at hand instead of that and other mandatory constraints forced upon me by the compiler. I very much want my development tools to limit themselves on being tools, to assist me on the part of the problem I chose to focus on with little to no cost paid for their usage. I want to be able to focus on prototyping some working solution first, and only then, if the project's needs really warrant it, to switch on paying the development cost for other aspects, be it safety or whatnot.
diath 2y ago
On the contrary, why would I not want these things in C++ if I'm developing every project with -fsanitize=address,undefined to catch these types of errors anyway?
616c 2y ago
[flagged]
- AnimalMuppet 2y ago
  > But why say so under a pseudonym That's a rather odd complaint, coming from a pseudonym.
- School-Cotton 2y ago
  Please don't shame people for using pseudonyms on here, regardless of whether you disagree with their concrete point. It's nice to have a place where people don't have to think about how their friends, family or colleagues will react before posting something.
jandrewrogers 2y ago
The parts of the government that think everything should be written in a memory-safe language (like Rust) are the same parts that already write everything in Java. Most of the high-end systems work is in C++, and that is the type of software where lifetimes and ownership are frequently unknowable at compile-time, obviating Rust's main selling point.
- AlotOfReading 2y ago
  It's not a hard dichotomy. Almost all of the rules Rust imposes are also present in C++, enforcement is simply left up to the fallible human programmer. Frankly though, is it that big a deal whether we call it unique_ptr/shared_ptr or Box/Arc if a lifetime is truly unknowable? Rust shines in the other 95% of code. I spend some time every morning cleaning up the sorts of issues Rust prevents that my coworkers have managed to commit despite tooling safeguards. I try for 3 a day, the list is growing, and I don't have to dig deep to find them. My coworkers aren't stupid people, they're intelligent people making simple mistakes because they aren't computers. It won't matter how often I tell them "you made X mistake on Y line, which violates Z rule" because the issue is not their knowledge, it's the inherent inability of humans to follow onerous technical rules without mistakes.
  - galangalalgol 2y ago
    Yeah, I don't end up fighting rust very often, and when I do, it is right. And when I run into a case that it isnt, I have unsafe and the rustonimicon to help me. You can do anything in rust you can do in c++, it is just that rust defaults to safe instead of unsafe, and there is no single keyword to let you know the c++ you are looking at is safe.
feelamee 2y ago
Ok. Please, just use your current C++ standard. But we will go to use the new one with all features we want to use.
- blub 2y ago
  Who’s “we”? The C++ developers that like the “Safe C++” proposal which is tacking Rust on top of C++ are a tiny minority. It seems very fair to tell them to just use Rust and leave C++ alone.
  - pjmlp 2y ago
    Indeed, that is exactly what many FAANG companies are doing, have you noticed the slow down in velocity in major compilers regarding ISO C++ compliance?
    - blub 2y ago
      Nope, still using C++17 and not bothered by any slowdown. C++ has been moving too fast lately.
      - pjmlp 2y ago
        It is currently an open debate what will be the very last ISO version the world will care about, C++17 might be the one, or C++26, bets are open.
    - bobnamob 2y ago
      See Apple’s slowdown on clang development and subsequent advances in Swift<->C++ interop (even going as far as merging Swift code into FoundationDB) And ofc Google’s investment in Carbon
      - pjmlp 2y ago
        Or MSVC slow pace with C++23, after being the first to reach full C++20 support. Everyone else outside the big three, is somewhere between C++14 and C++17.
GrantMoyer 2y ago
While programming in Rust, I've never thought to myself, "man, this would be so much easier to express in C++". I've plenty of times thought the reverse while programming in C++ though. Edit: except when interfacing with C APIs.
- throwawayffffas 2y ago
  I have had the exact opposite experience.
- kkert 2y ago
  This is interesting because i'm writing quite a bit of embedded Rust, and i always run into limitations of very barebones const generics. I always wish they'd have half the expressiveness of C++ constexpr and templates. Win some, lose some though, as the overall development workflow is lightyears ahead of C++, mostly due to tooling
  - smilekzs 2y ago
    > as the overall development workflow is lightyears ahead of C++, mostly due to tooling My experience has been the other way around. Eclipse-based IDEs from NXP, TI, ST all have out-of-the-box usable tooling integration: - MCU pinout and configuration codegen - no need to manually fiddle with linker scripts - static stack and code size analyzers (very helpful for fitting stuff in low-cost MCUs) - stable JTAG-based debugging with: - peripheral registers view (with bitfield definitions) - RTOS threads view (run status, blocked on which resources, ...) And yes, these are important enough for me to put up with Eclipse and pre-modern C/C++. I really want to write Rust for embedded but struggling with the tooling all the time didn't help.
  - afdbcreid 2y ago
    That's actually quite interesting because this is not an inherent limitation of Rust, and it is definitely planned to be improved. And AFAIK, today (as opposed to last years) it is even being actively worked on!
  - badmintonbaseba 2y ago
Attrecomet 2y ago
What I don't understand is why you demand that C++ evolution be halted in a clearly suboptimal position so you don't need to change your processes. Just use the version of C++ that meets your needs, you clearly don't want nor need new developments. You are fine with being locked into bad designs for hash maps and unique ptr due to the (newly invented, in 2011/13) ABI stability being made inviolable, you clearly need no new developments in usability and security. So why not be honest and just use C++01, or 11, or whatever it is that works for you, and let the rest of the ecosystem actually evolve and keep the language we invested so much effort into as a viable alternative? There's zero benefit, except to MS who want to sell this year's Visual Studio to all the companies with 80's-era C++...
- bagxrvxpepzn 2y ago
  > What I don't understand is why you demand that C++ evolution be halted in a clearly suboptimal position so you don't need to change your processes. I don't demand that C++ evolution be halted. I support the current trajectory of not adding viral annotations for the sake of implementing static lifetime checking. I want C++ to evolve into a better version of itself, I don't want it to become something it's not. If you want static lifetime checking, please use Rust. It already exists and it's great for people who need static lifetime checking.
- liontwist 2y ago
  > evolution be halted in a clearly suboptimal position It’s clear it’s imperfect. But not clear there is an obvious path to a nearby local maxima. Design choices have tradeoffs. And even if that were true, who would take advantage of that “better” language in a purely abstract sense? New language standards primarily exist to benefit existing C++ code bases, and the cohort of engineers who work on them. You have to consider that social reality.
sumanthvepa 2y ago
Thank you for this. C++ should NOT try to be Rust. I find modern C++ really nice to program in, for the work I'm doing - 3D graphics. The combination of very powerful abstractions and excellent performance is what I'm looking for. I'm more than willing to endure percived lack of safety in the language.
- tsimionescu 2y ago
  The lack of safety is perceived because it is there. There is no proof that anyone can write a C++ program larger than, say, 100k lines of code that doesn't have memory safety issues.
  - logicchains 2y ago
    And that memory safety is completely not an issue if you're writing something like a game, trading system, simulation, internal application or science calculation where there's no potentially hostile users who could do real harm by hacking your code. It's just a class of bug that in modern C++ is generally far outnumbered by logic bugs.
    - zozbot234 2y ago
      The issue of memory safety goes well beyond adversaries "hacking your code". Without memory safety, your code doesn't even have any kind of well-defined semantics so it's not feasible to defend against even "logic" bugs by automated means. If you care about program correctness in any real sense, memory safety is table stakes.
      - uecker 2y ago
        No, this is not how it works. Even without memory safety, the code has well-defined semantics for correct input, i.e. input that does not trigger undefined behavior. And if you prove your program correct for all inputs, this then implies that it does not have undefined behavior for any input. Memory safety is not a prerequisite for applying formal methods to show correctness.
chlorion 2y ago
Imagine an engineer in any other field acting like this. "I don't want to install air bags and these shiny safety gadgets into my cars. We have been shipping cars without them for years and it works for us and our customers." The problem is that it doesn't actually work as well as you think, and you are putting people at risk without realizing it.
- bookspace 2y ago
  What if, bagxrv, is a Rust fan, just playing ya? Everyone knows Rust fans are the most vigorous developers on the internet. Just take a look at https://izzys.casa/2024/11/on-safe-cxx/ https://izzys.casa/2024/11/on-safe-cxx/
- downut 2y ago
  You are making a general statement about the distribution of general consumers of computer languages, complete with a long tail, and the commenter is explaining that he is an expert car driver, way out there on the long tail. This tyranny of the less capable mode is really grating, especially on a site named "Hacker News". As usual, the answer is quite simple: "please use rust". We promise to never mention when we break out nasm. Driver anecdote: I have antilock brakes on my Tundra, but they are annoyingly counterproductive in 4WD descending 6" or larger sandy rocky steps. Do antilock brakes work overall best for the less capable mode? Of course! Do they work best for me? No.
  - ModernMech 2y ago
    We learned a long time ago as an industry that the expert car drivers are not immune to causing pile ups, which makes it all our problem to solve. Safety by default with escape hatches when absolutely necessary is the better way to go for all, even if it means some power users have to change their ways.
- andrewflnr 2y ago
  You're trying to install airbags on a motorcycle, though. The design of the vehicle/language is incompatible with airbags/lifetimes. So if you want airbags... don't use C++. (Yes, I know about airbag vests. Let's analogize those with external static checkers.)
bluGill 2y ago
C++ is on the trajectory to create a future with more safety. Should we do profiles or static lifetime checking (or something else??) is still an open question (and both may be valid). However I'm glad c++ is thinking about that. We have real problems around safety in the real world and people are writing unsafe code even when modern safe code would be easier to write. Of course it remains to be seen how this all plays out. Static lifetimes can be done good or bad. Profiles can be good or bad. Even if whatever we come up with is done well that doesn't mean people will (I know rust programmers who just put unsafe everywhere).
- titzer 2y ago
  Look, we need more than just promises. C++ is charting a future to the past in the most torturously slow process possible, primarily because of absolutely intrasigent performance obsession that won't even admit the possibility of a 1% performance overhead for bounds checks. The C++ steering committee are the real extremists that are holding back the entire software industry because of a sacred cow and a free pass to externalize that cost onto the rest of us in terms of significantly less secure software.
  - bagxrvxpepzn 2y ago
    > The C++ steering committee are the real extremists that are holding back the entire software industry because of a sacred cow and a free pass to externalize that cost onto the rest of us in terms of significantly less secure software. The C++ leadership serves the C++ community, not the entire software industry. You and everyone who disagrees with them are free to use and write software based on other languages, e.g. Java and Rust.
    - humanrebar 2y ago
      You can even add nonstandard features to existing compilers! The neat thing is that once the standard committee learns about this use case, it could get de facto support as existing use!
    - pjmlp 2y ago
natemcintosh 2y ago
And what about, for example, those government contractors who are in the same position as you: they have a large C++ codebase that currently works, and is too big to re-write in rust? Now they're being asked to make it safer. How will they do that with the "existing C++ process"?
- pizlonator 2y ago
  They can use Fil-C++ and then they get memory safety without any rewrites.
- moregrist 2y ago
  The funny thing about government funding is that it may be easier to secure capital for a Rust rewrite than for ongoing maintenance to add static lifetimes and other safety features to an existing C++ codebase. Legislatures seem a lot more able to allocate large pots of money for major discrete projects than to guarantee an ongoing stream of revenue to a continuing project.
- jart 2y ago
  Didn't Project Zero publish a blog post a few months ago, saying that old code isn't your security problem? They said it's new code you have to worry about. Zero also had copious amounts of data to demonstrate their point. In any case, if you really want to rewrite C++ in Rust, LLMs are fantastic at doing that. They're not really good yet at writing a new giant codebase from first principles. But if you give them something that already exists and ask them to translate it into a different language, oftentimes the result works for me on the first try. Even if it's hundreds of lines long.
  - SkiFire13 2y ago
    The issue is that newer code often needs to communicate with older code, and interfacing C++ and Rust is not trivial.
  - fulafel 2y ago
    A link would be helpful, but at face value: of course old code vulnerabilities are still a problem. Vulnerabilities in old code make the headlines all the time.

lubesGordi 2y ago

I don't know enough about what it would take to implement static lifetime checking. Is that fundamentally impossible to do in a backwards compatible way?

steveklabnik 2y ago
It depends on what you mean by "backwards compatible," and what you mean by "static lifetime checking" :) The profiles proposal suggests adding static lifetime checking, "without viral annotations." I use quotations because I don't really agree with this framing, but whatever. The paper is here if you'd like to read it yourself: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3081r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p30... The core idea here is that you add annotations to opt in or out of certain checks. And opting in may be a compiler flag, requiring no changes to source code. So that would be "backwards compatibility" in that sense. Of course, code may fail these checks, so you'll have to add annotations to opt out, or re-write the code. We will see in practice how much change is required once implementations exist and are tried out. But the other part is, these profiles do not attempt to cover all valid cases. And what I mean by that is, there are some lifetime issues that this proposal does not attempt to analyze. And, where the analysis is similar, they offer a subset of what other proposals do. These decisions were made because the authors believe that they'll reduce a significant number of issues, and are easier to adopt. And that's worth it instead of going for more checks. The competing proposal, Safe C++, has you opt into safety checks on a file-per-file basis. So in that sense, it is also backwards compatible: all existing code compiles as-is. When you opt in to those checks, it adds new syntax, similar to Rust, to do the safety analysis checks. So you gain this benefit for only new code, but it also you get much more power. This syntax is necessary to communicate programmer intent to the checks, but is the "viral annotations" that the proponents of profiles don't like. So, basically, that's the thing: both are backwards compatible, but offer very different tradeoffs in the design space.
aiono 2y ago
If you want alias tracking and lifetime checking, yes they are backwards incompatible. They need "viral annotations" if we speak with the C++ committee terminology.

mempko 2y ago

This! The hardest part of making software is making something that works for people. What I love about C++ is multi-paradigm programming. I can express my ideas directly using the appropriate paradigms. Regarding safety, with modern C++ programming, it's not hard to write software that's correct. Safety is often never the first thing I worry about. If having strict safety means I can't express my mental models in code, I don't want it. It will slow me down. It will make it harder to write software that's useful. Remember people, we are here to make things that are useful to people. If safety gets in the way of that, then it's not worth it.

aiono 2y ago

You frame it like "Rust advocates" try to infiltrate into C++ language decision making and inject safety features into it. That's not the case at all. For years C++ committee simply ignored the need for safety and they didn't take Rust and lifetime analysis seriously. But now they themselves want it.

einpoklum 2y ago

> I approve of the current C++ trajectory But this isn't one thing. Part of the problem is contradictions even in the definition of this trajectory. An important example: Will it be "you don't pay for what you don't use", or will it be "stable ABI"? There are adopted papers which say both - as the linked article indicates. > please just consider another language, e.g. Rust I'm not one of those people necessarily, but - Rust has its own set of design goals and problems. It is legitimate to want C++ to go one way rather than another. > To Rust advocates, you can have the US government and big tech. Now you are kind of contradicting yourself, because wide applicability is definitely a goal for C++.

AlotOfReading 2y ago

C++ has lifetime rules just like Rust. They're simply implicit in the code and not enforced by the compiler. Do you prefer the uncertainty of silent miscompilations and undefined behavior to upfront compiler errors? You're already using a language with a strong type system, so it's confusing to me why you would choose to draw the line here.

bagxrvxpepzn 2y ago
> Do you prefer the uncertainty of silent miscompilations and undefined behavior to upfront compiler errors? Yes because then I don't have to spend hours writing esoteric spaghetti code to prove something to the compiler that is trivially known to be true. Your error is assuming static lifetime checking is free. As an engineer, I use judgement to make context-dependent trade offs. If you like playing the compiler olympics, or your employer forces you to, please use Rust.
- zozbot234 2y ago
  "Trivially known to be true" until the code evolves making your unstated assumptions not hold and everything breaks, often in complex and unintuitive ways involving interactions across modules. This is why these automated soundness checks are valuable.
  - restalis 2y ago
    "until the code evolves [...]" That is already a desirable place to be, where you managed to get a working implementation ready to evolve. My issue with opinionated languages like Rust is that they make development more expensive. I then afford to pay the necessary work-effort for fewer projects than I otherwise could if I was to focus more on the problem(s) at hand instead of that and other mandatory constraints forced upon me by the compiler. I very much want my development tools to limit themselves on being tools, to assist me on the part of the problem I chose to focus on with little to no cost paid for their usage. I want to be able to focus on prototyping some working solution first, and only then, if the project's needs really warrant it, to switch on paying the development cost for other aspects, be it safety or whatnot.

diath 2y ago

On the contrary, why would I not want these things in C++ if I'm developing every project with -fsanitize=address,undefined to catch these types of errors anyway?

616c 2y ago

[flagged]

AnimalMuppet 2y ago
> But why say so under a pseudonym That's a rather odd complaint, coming from a pseudonym.
School-Cotton 2y ago
Please don't shame people for using pseudonyms on here, regardless of whether you disagree with their concrete point. It's nice to have a place where people don't have to think about how their friends, family or colleagues will react before posting something.

jandrewrogers 2y ago

The parts of the government that think everything should be written in a memory-safe language (like Rust) are the same parts that already write everything in Java. Most of the high-end systems work is in C++, and that is the type of software where lifetimes and ownership are frequently unknowable at compile-time, obviating Rust's main selling point.

AlotOfReading 2y ago
It's not a hard dichotomy. Almost all of the rules Rust imposes are also present in C++, enforcement is simply left up to the fallible human programmer. Frankly though, is it that big a deal whether we call it unique_ptr/shared_ptr or Box/Arc if a lifetime is truly unknowable? Rust shines in the other 95% of code. I spend some time every morning cleaning up the sorts of issues Rust prevents that my coworkers have managed to commit despite tooling safeguards. I try for 3 a day, the list is growing, and I don't have to dig deep to find them. My coworkers aren't stupid people, they're intelligent people making simple mistakes because they aren't computers. It won't matter how often I tell them "you made X mistake on Y line, which violates Z rule" because the issue is not their knowledge, it's the inherent inability of humans to follow onerous technical rules without mistakes.
- galangalalgol 2y ago
  Yeah, I don't end up fighting rust very often, and when I do, it is right. And when I run into a case that it isnt, I have unsafe and the rustonimicon to help me. You can do anything in rust you can do in c++, it is just that rust defaults to safe instead of unsafe, and there is no single keyword to let you know the c++ you are looking at is safe.

feelamee 2y ago

Ok. Please, just use your current C++ standard. But we will go to use the new one with all features we want to use.

blub 2y ago
Who’s “we”? The C++ developers that like the “Safe C++” proposal which is tacking Rust on top of C++ are a tiny minority. It seems very fair to tell them to just use Rust and leave C++ alone.
- pjmlp 2y ago
  Indeed, that is exactly what many FAANG companies are doing, have you noticed the slow down in velocity in major compilers regarding ISO C++ compliance?
  - blub 2y ago
    Nope, still using C++17 and not bothered by any slowdown. C++ has been moving too fast lately.
    - pjmlp 2y ago
      It is currently an open debate what will be the very last ISO version the world will care about, C++17 might be the one, or C++26, bets are open.
  - bobnamob 2y ago
    See Apple’s slowdown on clang development and subsequent advances in Swift<->C++ interop (even going as far as merging Swift code into FoundationDB) And ofc Google’s investment in Carbon
    - pjmlp 2y ago
      Or MSVC slow pace with C++23, after being the first to reach full C++20 support. Everyone else outside the big three, is somewhere between C++14 and C++17.

GrantMoyer 2y ago

While programming in Rust, I've never thought to myself, "man, this would be so much easier to express in C++". I've plenty of times thought the reverse while programming in C++ though. Edit: except when interfacing with C APIs.

throwawayffffas 2y ago
I have had the exact opposite experience.
kkert 2y ago
This is interesting because i'm writing quite a bit of embedded Rust, and i always run into limitations of very barebones const generics. I always wish they'd have half the expressiveness of C++ constexpr and templates. Win some, lose some though, as the overall development workflow is lightyears ahead of C++, mostly due to tooling
- smilekzs 2y ago
  > as the overall development workflow is lightyears ahead of C++, mostly due to tooling My experience has been the other way around. Eclipse-based IDEs from NXP, TI, ST all have out-of-the-box usable tooling integration: - MCU pinout and configuration codegen - no need to manually fiddle with linker scripts - static stack and code size analyzers (very helpful for fitting stuff in low-cost MCUs) - stable JTAG-based debugging with: - peripheral registers view (with bitfield definitions) - RTOS threads view (run status, blocked on which resources, ...) And yes, these are important enough for me to put up with Eclipse and pre-modern C/C++. I really want to write Rust for embedded but struggling with the tooling all the time didn't help.
- afdbcreid 2y ago
  That's actually quite interesting because this is not an inherent limitation of Rust, and it is definitely planned to be improved. And AFAIK, today (as opposed to last years) it is even being actively worked on!
- badmintonbaseba 2y ago

Attrecomet 2y ago

What I don't understand is why you demand that C++ evolution be halted in a clearly suboptimal position so you don't need to change your processes. Just use the version of C++ that meets your needs, you clearly don't want nor need new developments. You are fine with being locked into bad designs for hash maps and unique ptr due to the (newly invented, in 2011/13) ABI stability being made inviolable, you clearly need no new developments in usability and security. So why not be honest and just use C++01, or 11, or whatever it is that works for you, and let the rest of the ecosystem actually evolve and keep the language we invested so much effort into as a viable alternative? There's zero benefit, except to MS who want to sell this year's Visual Studio to all the companies with 80's-era C++...

bagxrvxpepzn 2y ago
> What I don't understand is why you demand that C++ evolution be halted in a clearly suboptimal position so you don't need to change your processes. I don't demand that C++ evolution be halted. I support the current trajectory of not adding viral annotations for the sake of implementing static lifetime checking. I want C++ to evolve into a better version of itself, I don't want it to become something it's not. If you want static lifetime checking, please use Rust. It already exists and it's great for people who need static lifetime checking.
liontwist 2y ago
> evolution be halted in a clearly suboptimal position It’s clear it’s imperfect. But not clear there is an obvious path to a nearby local maxima. Design choices have tradeoffs. And even if that were true, who would take advantage of that “better” language in a purely abstract sense? New language standards primarily exist to benefit existing C++ code bases, and the cohort of engineers who work on them. You have to consider that social reality.

sumanthvepa 2y ago

Thank you for this. C++ should NOT try to be Rust. I find modern C++ really nice to program in, for the work I'm doing - 3D graphics. The combination of very powerful abstractions and excellent performance is what I'm looking for. I'm more than willing to endure percived lack of safety in the language.

tsimionescu 2y ago
The lack of safety is perceived because it is there. There is no proof that anyone can write a C++ program larger than, say, 100k lines of code that doesn't have memory safety issues.
- logicchains 2y ago
  And that memory safety is completely not an issue if you're writing something like a game, trading system, simulation, internal application or science calculation where there's no potentially hostile users who could do real harm by hacking your code. It's just a class of bug that in modern C++ is generally far outnumbered by logic bugs.
  - zozbot234 2y ago
    The issue of memory safety goes well beyond adversaries "hacking your code". Without memory safety, your code doesn't even have any kind of well-defined semantics so it's not feasible to defend against even "logic" bugs by automated means. If you care about program correctness in any real sense, memory safety is table stakes.
    - uecker 2y ago
      No, this is not how it works. Even without memory safety, the code has well-defined semantics for correct input, i.e. input that does not trigger undefined behavior. And if you prove your program correct for all inputs, this then implies that it does not have undefined behavior for any input. Memory safety is not a prerequisite for applying formal methods to show correctness.

chlorion 2y ago

Imagine an engineer in any other field acting like this. "I don't want to install air bags and these shiny safety gadgets into my cars. We have been shipping cars without them for years and it works for us and our customers." The problem is that it doesn't actually work as well as you think, and you are putting people at risk without realizing it.

bookspace 2y ago
What if, bagxrv, is a Rust fan, just playing ya? Everyone knows Rust fans are the most vigorous developers on the internet. Just take a look at https://izzys.casa/2024/11/on-safe-cxx/ https://izzys.casa/2024/11/on-safe-cxx/
downut 2y ago
You are making a general statement about the distribution of general consumers of computer languages, complete with a long tail, and the commenter is explaining that he is an expert car driver, way out there on the long tail. This tyranny of the less capable mode is really grating, especially on a site named "Hacker News". As usual, the answer is quite simple: "please use rust". We promise to never mention when we break out nasm. Driver anecdote: I have antilock brakes on my Tundra, but they are annoyingly counterproductive in 4WD descending 6" or larger sandy rocky steps. Do antilock brakes work overall best for the less capable mode? Of course! Do they work best for me? No.
- ModernMech 2y ago
  We learned a long time ago as an industry that the expert car drivers are not immune to causing pile ups, which makes it all our problem to solve. Safety by default with escape hatches when absolutely necessary is the better way to go for all, even if it means some power users have to change their ways.
andrewflnr 2y ago
You're trying to install airbags on a motorcycle, though. The design of the vehicle/language is incompatible with airbags/lifetimes. So if you want airbags... don't use C++. (Yes, I know about airbag vests. Let's analogize those with external static checkers.)

bluGill 2y ago

C++ is on the trajectory to create a future with more safety. Should we do profiles or static lifetime checking (or something else??) is still an open question (and both may be valid). However I'm glad c++ is thinking about that. We have real problems around safety in the real world and people are writing unsafe code even when modern safe code would be easier to write. Of course it remains to be seen how this all plays out. Static lifetimes can be done good or bad. Profiles can be good or bad. Even if whatever we come up with is done well that doesn't mean people will (I know rust programmers who just put unsafe everywhere).

titzer 2y ago
Look, we need more than just promises. C++ is charting a future to the past in the most torturously slow process possible, primarily because of absolutely intrasigent performance obsession that won't even admit the possibility of a 1% performance overhead for bounds checks. The C++ steering committee are the real extremists that are holding back the entire software industry because of a sacred cow and a free pass to externalize that cost onto the rest of us in terms of significantly less secure software.
- bagxrvxpepzn 2y ago
  > The C++ steering committee are the real extremists that are holding back the entire software industry because of a sacred cow and a free pass to externalize that cost onto the rest of us in terms of significantly less secure software. The C++ leadership serves the C++ community, not the entire software industry. You and everyone who disagrees with them are free to use and write software based on other languages, e.g. Java and Rust.
  - humanrebar 2y ago
    You can even add nonstandard features to existing compilers! The neat thing is that once the standard committee learns about this use case, it could get de facto support as existing use!
  - pjmlp 2y ago

natemcintosh 2y ago

And what about, for example, those government contractors who are in the same position as you: they have a large C++ codebase that currently works, and is too big to re-write in rust? Now they're being asked to make it safer. How will they do that with the "existing C++ process"?

pizlonator 2y ago
They can use Fil-C++ and then they get memory safety without any rewrites.
moregrist 2y ago
The funny thing about government funding is that it may be easier to secure capital for a Rust rewrite than for ongoing maintenance to add static lifetimes and other safety features to an existing C++ codebase. Legislatures seem a lot more able to allocate large pots of money for major discrete projects than to guarantee an ongoing stream of revenue to a continuing project.
jart 2y ago
Didn't Project Zero publish a blog post a few months ago, saying that old code isn't your security problem? They said it's new code you have to worry about. Zero also had copious amounts of data to demonstrate their point. In any case, if you really want to rewrite C++ in Rust, LLMs are fantastic at doing that. They're not really good yet at writing a new giant codebase from first principles. But if you give them something that already exists and ask them to translate it into a different language, oftentimes the result works for me on the first try. Even if it's hundreds of lines long.
- SkiFire13 2y ago
  The issue is that newer code often needs to communicate with older code, and interfacing C++ and Rust is not trivial.
- fulafel 2y ago
  A link would be helpful, but at face value: of course old code vulnerabilities are still a problem. Vulnerabilities in old code make the headlines all the time.