4 ms·

We should be seeing completely safe C++ code soon. Take a look at Herb Sutter's CppCon talk this year: https://www.youtube.com/watch?v=hEx5DNLWGgA https://www

We should be seeing completely safe C++ code soon. Take a look at Herb Sutter's CppCon talk this year: https://www.youtube.com/watch?v=hEx5DNLWGgA https://www.youtube.com/watch?v=hEx5DNLWGgA Reinventing the wheel isn't entirely necessary. Though if you're a SysAdmin and you write your codebase in Rust.. that's some nice job security. ;)

gmjosack 11y ago
I'd already looked through the slides for that talk but I'll check out the video. Thanks! I think C++ has a lot of awesome stuff coming out but I find Rust more pleasant to code in. Also having package/dependency management has been great compared to using the old versions of libraries that come with distros or tracking down all the transitive dependencies of software. Rust is just a more delightful experience out of the box. > Though if you're a SysAdmin and you write your codebase in Rust.. that's some nice job security. ;) I definitely understand this but I don't think it's true and will be less and less true over time. It is becoming very common in the SRE/SysAdmin industry that strong coding skills is a requirement. When I started 10 years ago that was very different but it's becoming harder and harder to find jobs as a Linux grunt. The SREs I work with care about software engineering best practices, code review, testing, continuous integration, etc. Also, even if that were true, I'd much rather have people with a weaker understanding contribute to Rust where the compiler has your back. If you haven't used Rust you might be surprised how good the error messages are. Once you spend a bit of time understanding the basics the compiler is super helpful.
MichaelGG 11y ago
Once C++ allows people to flip a switch to produce guaranteed memory safe code, then it can start really comparing itself on that metric. (This would be fantastic. Think of the resources that'd be spent on such research! It'd be world-changing.) But even then, the inherent differences in a statement oriented vs expression oriented is likely to keep C++ being needlessly verbose. And I object to using Rust (or other production-level but "edge" languages) as being "job security". If the underlying software matters enough that using Rust has significant benefits, then it matters enough that employees spend a few days learning a bit of Rust. This fear of languages as if learning a language was this huge mountain to scale in hiring is just silly. The actual code and environment probably outweighs the language used significantly. The real exception to this is if you're running a codebase that has essentially non-programmers adding bits here and there. Somewhere where you know that the individual contributors will find learning a language to be a higher barrier than contributing new pieces of code. (So either a rather trivial system, or contributors that have an unusually low capacity.)
- blub 11y ago
  I think you mean employees spend half a year to know enough Rust to be comfortable. That's how long it took me and others on my team to learn Java at a level where we knew the idioms, patterns and enough of the libraries. All of us had significant experience in other OO programming langauges. Learning a language in days is a fairytale, the fact that you're so cavalier about this point makes it seem that you're more interested in doing advocacy than having an honest discussion.
  - kibwen 11y ago
    Take the amount of time that it takes to become comfortable in a given language, and now increase that by an order of magnitude: this is how long it will take you to become comfortable writing C++ unsupervised. The language simply has too many subtle footguns to allow a beginner to be unleashed on a codebase (compare Java, where the worst a beginner will do is write a tangled mess of inflexible classes, but it will still largely work). The massive quantities of pre-C++11 documentation out there aren't doing the language any good either. And colleges (with the exception of game development programs) aren't teaching C++ anymore (and where they are, they're teaching C++98/03), so writing anything new in C++ means you're either going to maintain this yourself in perpetuity (talk about job security), or you're going to commit to a long period of coaching a beginner on the language, or you're going to hire an experienced C++ programmer for a significant multiple of what a less specialized programmer would have cost you. So in the context of a conversation about the costs of training and long-term maintainability, well, you should probably write all your stuff in Java, but if you can't, then you're better off selecting Rust over C++. I can teach Rust to anyone that knows Python, and once you know Rust you're at least familiar with the most useful subset of C++.
    - blub 11y ago
      There are plenty of C++ programmers to hire from. I know because we are hiring both at experienced and junior levels. Furthermore, a C++ programmer is not significantly more expensive than other programmers according to SO salary surveys. An experienced programmer will demand a good salary no matter which language he uses. I gather from this post that you seem to use a risky strategy for your development - let juniors loose on a problem and hope that Rust/Java will save them. Or is that just a straw man? In any case, all juniors should get coaching, CI with static analysis and code reviews are likewise highly recommended. Finally, I can't understand how someone can recommend Rust over C++ for long-term maintainability with a straight face. The first stable version of Rust was announced four months ago, let's talk again in 10 years and see how your code from 2015 is doing.
yokohummer7 11y ago
Like I said somewhere, a safe subset of C++ sounds wonderful at first, but it also has demerits: - If you enforce memory safety to all of your code, the number of the libraries that you can use will be severely limited. Imagine if you can only use C++14 libraries. How many C++14 libraries are out there? And I'm not sure if there will be many libraries written in safe C++, at least for the next few years. The adoption rate for newer C++ standards (C++11, C++14) was generally not satisfactory. - If you only enforce memory safety to your own code, then you could use the existing ecosystem. But in that case, your program will still segfault because of the libraries you're using. Admittedly this is also a concern of Rust when you use C libraries in Rust. The more safe code you use, the safer your program is. The problem is, if you choose this route, there's not much ecosystem-ish advantage in the C++'s side. You will also have to "reinvent the wheel" as you would have to do in Rust. This problem all boils to this: adding guaranteed memory safety to the unsafe language is a breaking change. And the problems occurred by breaking changes are very hard to solve.
- something123 11y ago
  Rereading your comment it feels like you've moved the goal posts and are being overly cynical. (This presentations essentially addressed your previous concern by providing interoperability between new safe code and existing code that doesn't have safety guarantees) These are valid concerns, but you're being very dismissive of the benefits I think confining errors to libraries is generally a good strategy. In effect you are guaranteeing that you're not going to introduce any new unsafe code. It might uncover errors in the existing code.. but that's a much smaller issue and one that fades with time (esp if you're talking about libraries that a lot of people are using) Is this "good enough" for a brand new aircraft-control/heart-lung-machine system? Maybe not. Maybe then you should start from the ground up using either Rust or C++/GSL entirely. But I think for most use cases this is sufficient and brings huge immediate benefits now. And of course with time libraries will be updated to include safety guarantees (which for the most part seem like it wouldn't involve a ton of work) This is more of an organic process that basically in some form preserves the millions of man hours people have invested in C++ and less of a clean slate solution. As I've said before, you gotta make a living now in the current reality with the current codebases and the current tools. You can't just judge languages in a vaccuum.

gmjosack 11y ago

I'd already looked through the slides for that talk but I'll check out the video. Thanks! I think C++ has a lot of awesome stuff coming out but I find Rust more pleasant to code in. Also having package/dependency management has been great compared to using the old versions of libraries that come with distros or tracking down all the transitive dependencies of software. Rust is just a more delightful experience out of the box. > Though if you're a SysAdmin and you write your codebase in Rust.. that's some nice job security. ;) I definitely understand this but I don't think it's true and will be less and less true over time. It is becoming very common in the SRE/SysAdmin industry that strong coding skills is a requirement. When I started 10 years ago that was very different but it's becoming harder and harder to find jobs as a Linux grunt. The SREs I work with care about software engineering best practices, code review, testing, continuous integration, etc. Also, even if that were true, I'd much rather have people with a weaker understanding contribute to Rust where the compiler has your back. If you haven't used Rust you might be surprised how good the error messages are. Once you spend a bit of time understanding the basics the compiler is super helpful.

MichaelGG 11y ago

Once C++ allows people to flip a switch to produce guaranteed memory safe code, then it can start really comparing itself on that metric. (This would be fantastic. Think of the resources that'd be spent on such research! It'd be world-changing.) But even then, the inherent differences in a statement oriented vs expression oriented is likely to keep C++ being needlessly verbose. And I object to using Rust (or other production-level but "edge" languages) as being "job security". If the underlying software matters enough that using Rust has significant benefits, then it matters enough that employees spend a few days learning a bit of Rust. This fear of languages as if learning a language was this huge mountain to scale in hiring is just silly. The actual code and environment probably outweighs the language used significantly. The real exception to this is if you're running a codebase that has essentially non-programmers adding bits here and there. Somewhere where you know that the individual contributors will find learning a language to be a higher barrier than contributing new pieces of code. (So either a rather trivial system, or contributors that have an unusually low capacity.)

blub 11y ago
I think you mean employees spend half a year to know enough Rust to be comfortable. That's how long it took me and others on my team to learn Java at a level where we knew the idioms, patterns and enough of the libraries. All of us had significant experience in other OO programming langauges. Learning a language in days is a fairytale, the fact that you're so cavalier about this point makes it seem that you're more interested in doing advocacy than having an honest discussion.
- kibwen 11y ago
  Take the amount of time that it takes to become comfortable in a given language, and now increase that by an order of magnitude: this is how long it will take you to become comfortable writing C++ unsupervised. The language simply has too many subtle footguns to allow a beginner to be unleashed on a codebase (compare Java, where the worst a beginner will do is write a tangled mess of inflexible classes, but it will still largely work). The massive quantities of pre-C++11 documentation out there aren't doing the language any good either. And colleges (with the exception of game development programs) aren't teaching C++ anymore (and where they are, they're teaching C++98/03), so writing anything new in C++ means you're either going to maintain this yourself in perpetuity (talk about job security), or you're going to commit to a long period of coaching a beginner on the language, or you're going to hire an experienced C++ programmer for a significant multiple of what a less specialized programmer would have cost you. So in the context of a conversation about the costs of training and long-term maintainability, well, you should probably write all your stuff in Java, but if you can't, then you're better off selecting Rust over C++. I can teach Rust to anyone that knows Python, and once you know Rust you're at least familiar with the most useful subset of C++.
  - blub 11y ago
    There are plenty of C++ programmers to hire from. I know because we are hiring both at experienced and junior levels. Furthermore, a C++ programmer is not significantly more expensive than other programmers according to SO salary surveys. An experienced programmer will demand a good salary no matter which language he uses. I gather from this post that you seem to use a risky strategy for your development - let juniors loose on a problem and hope that Rust/Java will save them. Or is that just a straw man? In any case, all juniors should get coaching, CI with static analysis and code reviews are likewise highly recommended. Finally, I can't understand how someone can recommend Rust over C++ for long-term maintainability with a straight face. The first stable version of Rust was announced four months ago, let's talk again in 10 years and see how your code from 2015 is doing.

yokohummer7 11y ago

Like I said somewhere, a safe subset of C++ sounds wonderful at first, but it also has demerits: - If you enforce memory safety to all of your code, the number of the libraries that you can use will be severely limited. Imagine if you can only use C++14 libraries. How many C++14 libraries are out there? And I'm not sure if there will be many libraries written in safe C++, at least for the next few years. The adoption rate for newer C++ standards (C++11, C++14) was generally not satisfactory. - If you only enforce memory safety to your own code, then you could use the existing ecosystem. But in that case, your program will still segfault because of the libraries you're using. Admittedly this is also a concern of Rust when you use C libraries in Rust. The more safe code you use, the safer your program is. The problem is, if you choose this route, there's not much ecosystem-ish advantage in the C++'s side. You will also have to "reinvent the wheel" as you would have to do in Rust. This problem all boils to this: adding guaranteed memory safety to the unsafe language is a breaking change. And the problems occurred by breaking changes are very hard to solve.

something123 11y ago
Rereading your comment it feels like you've moved the goal posts and are being overly cynical. (This presentations essentially addressed your previous concern by providing interoperability between new safe code and existing code that doesn't have safety guarantees) These are valid concerns, but you're being very dismissive of the benefits I think confining errors to libraries is generally a good strategy. In effect you are guaranteeing that you're not going to introduce any new unsafe code. It might uncover errors in the existing code.. but that's a much smaller issue and one that fades with time (esp if you're talking about libraries that a lot of people are using) Is this "good enough" for a brand new aircraft-control/heart-lung-machine system? Maybe not. Maybe then you should start from the ground up using either Rust or C++/GSL entirely. But I think for most use cases this is sufficient and brings huge immediate benefits now. And of course with time libraries will be updated to include safety guarantees (which for the most part seem like it wouldn't involve a ton of work) This is more of an organic process that basically in some form preserves the millions of man hours people have invested in C++ and less of a clean slate solution. As I've said before, you gotta make a living now in the current reality with the current codebases and the current tools. You can't just judge languages in a vaccuum.