4 ms·

The way I look at it is we're in a transitional period. A language like Go or Rust can replace some of the C++ lift, but we're not sure because they're not a l

The way I look at it is we're in a transitional period. A language like Go or Rust can replace some of the C++ lift, but we're not sure because they're not a large body of experience with those languages. I suspect, but can't say with any certainty, that we'll wind up in a world where the use case for C++ shrinks significantly. Rust and Go will eat into the share of new Greenfield systems that would have normally gone to C++ or even C. I like to live in the embedded world and there I think Rust will shortly start to push out C and C++ at the wide-spread, commercial level. This is where my head is at, maybe it helps you formulate your opinion: First, embedded C++ is not the same a full C++ (with features or library parts missing to accommodate the constrained environment). So I might never see some of the C++2x or even C++1x features. I really don't care about the C++2x standards since I might not see them in the next 10 years. Second, memory and concurrency issues are real, even when you don't allow dynamic memory allocation after the system is initialized. We test, then test, and then run more tests, and turn on a lot of linters and analyzers but at the end of the day, they're bandaids. You can write terrible code in Rust, but you have to work harder to do it. Third, if you really need an environment where memory is as fungible as play dough but want something portable (like inside a kernel), there will always be C. Setting up a C callable environment from assembly is well understood. In theory, calling into Rust shouldn't be any harder. But reading disassembled object files from C is generally reasonable assembler for the C I wrote. I haven't really tried doing that with Rust. Fourth, it will take 5 years or so, but eventually we'll see commercially supported RTOS implementations for Rust that help companies to shield themselves from liability. For example, something like Threadx (AzureRTOS now). This will help push money in a virtuous cycle of better tooling -> more projects -> more money for tool venders -> better tooling. Fifth, there will be Rust bindings to cover just about everything you do with C++ now (like game development) with high quality, idiot-proof, and portable semantics. You will find that junior developers or fresh-outs will have their skin crawl when asked to write "unsafe" code. Sixth, there's counter evidence to support a lack of adoption of new languages. Ada provides many of the same concurrency and memory safety guarantees as Rust, and has been available since 1983, but it is not widely adopted. It is harder to use and requires significant developer training. If Rust is significantly more challenging for developers, it may go the way of Ada. But that's in the future. If I had to start a new project today (for a braking system on a train, for example), I would start with C, a validated RTOS, and commercial toolchain. If I had to light up my kid's halloween costume? Embedded Rust as a learning exercise. The rendering engine for a VR headset (with limited batter and compute), probably C++.

__jem 4y ago
> Sixth, there's counter evidence to support a lack of adoption of new languages. Ada provides many of the same concurrency and memory safety guarantees as Rust, and has been available since 1983, but it is not widely adopted. It is harder to use and requires significant developer training. If Rust is significantly more challenging for developers, it may go the way of Ada. Rust is definitely difficult to learn, but I'll anecdotally say that Rust helped get me into the embedded world as someone with very little C or C++ experience. Unlike Ada, Rust has a modern toolchain and type system that feels very comfortable to developers coming from higher level languages, even if many of the concepts related to manual memory management remain quite difficult.
- pyjarrett 4y ago
  > Unlike Ada, Rust has a modern toolchain We have a modern toolchain too :) # install compiler and build tools alr toolchain --select # make, build and run a project alr init --bin my_project alr build alr run
- f1shy 4y ago
  In the aeronautics and space industry Ada was and is popular. Ok, not the biggest industry, but still...
  - phoehne 4y ago
    It's a very good language. I learned it graduate school in the mid 1990s. I personally think the learning curve is not particularly steep. But it seems like most developers and the industry would rather enforce coding standards to nerf the foot-guns in C/C++ (https://news.ycombinator.com/item?id=7628746 https://news.ycombinator.com/item?id=7628746). With Ada there would still be coding standards but I would wager that it wouldn't be as much about inherent problems in the language. They might both have a rule like: AV Rule 1 Any one function (or method) will contain no more than 200 logical source lines of code (L- SLOCs). But Ada would probably not have something like: AV Rule 59 (MISRA Rule 59, Revised) The statements forming the body of an if, else if, else, while, do...while or for statement shall always be enclosed in braces, even if the braces form an empty block. Or: AV Rule 193 (MISRA Rule 61) Every non-empty case clause in a switch statement shall be terminated with a break statement. Those two arise from deficiencies in the basic C/C++ syntax. They are probably not fixable in a future revision of the spec because they would break too much code. So we create a coding standard, configure a linter to check for it, wire up our source repository to scan for it on checkin, and make all the leads code review for it. Ada might have different language specific standards. For example, around not allowing breaks out of infinite loops. Requiring, instead, a loop construct with a testable condition. But even then, you can pragma things out of the compiler to help you enforce behavior. That's "built in." My comment with Rust is not that Ada is bad or too hard, but rather even a small amount of additional work might be enough for developers and organizations to avoid Rust. There's a lot of Rust advocacy, which is a good thing. However, there was also a lot of activity on comp.lang.ada.advocacy (if I remember the newsgroup correctly). One good thing is that Ada felt "imposed" by a number of people and that automatically stimulates a kind of rejection response. Rust's introduction is definitely more "bottom up."

__jem 4y ago

> Sixth, there's counter evidence to support a lack of adoption of new languages. Ada provides many of the same concurrency and memory safety guarantees as Rust, and has been available since 1983, but it is not widely adopted. It is harder to use and requires significant developer training. If Rust is significantly more challenging for developers, it may go the way of Ada. Rust is definitely difficult to learn, but I'll anecdotally say that Rust helped get me into the embedded world as someone with very little C or C++ experience. Unlike Ada, Rust has a modern toolchain and type system that feels very comfortable to developers coming from higher level languages, even if many of the concepts related to manual memory management remain quite difficult.

pyjarrett 4y ago
> Unlike Ada, Rust has a modern toolchain We have a modern toolchain too :) # install compiler and build tools alr toolchain --select # make, build and run a project alr init --bin my_project alr build alr run
f1shy 4y ago
In the aeronautics and space industry Ada was and is popular. Ok, not the biggest industry, but still...
- phoehne 4y ago
  It's a very good language. I learned it graduate school in the mid 1990s. I personally think the learning curve is not particularly steep. But it seems like most developers and the industry would rather enforce coding standards to nerf the foot-guns in C/C++ (https://news.ycombinator.com/item?id=7628746 https://news.ycombinator.com/item?id=7628746). With Ada there would still be coding standards but I would wager that it wouldn't be as much about inherent problems in the language. They might both have a rule like: AV Rule 1 Any one function (or method) will contain no more than 200 logical source lines of code (L- SLOCs). But Ada would probably not have something like: AV Rule 59 (MISRA Rule 59, Revised) The statements forming the body of an if, else if, else, while, do...while or for statement shall always be enclosed in braces, even if the braces form an empty block. Or: AV Rule 193 (MISRA Rule 61) Every non-empty case clause in a switch statement shall be terminated with a break statement. Those two arise from deficiencies in the basic C/C++ syntax. They are probably not fixable in a future revision of the spec because they would break too much code. So we create a coding standard, configure a linter to check for it, wire up our source repository to scan for it on checkin, and make all the leads code review for it. Ada might have different language specific standards. For example, around not allowing breaks out of infinite loops. Requiring, instead, a loop construct with a testable condition. But even then, you can pragma things out of the compiler to help you enforce behavior. That's "built in." My comment with Rust is not that Ada is bad or too hard, but rather even a small amount of additional work might be enough for developers and organizations to avoid Rust. There's a lot of Rust advocacy, which is a good thing. However, there was also a lot of activity on comp.lang.ada.advocacy (if I remember the newsgroup correctly). One good thing is that Ada felt "imposed" by a number of people and that automatically stimulates a kind of rejection response. Rust's introduction is definitely more "bottom up."