4 ms·
As someone who has had to deal with C++ in the Windows and Linux kernels for the last couple of years, the thing that excited me and drew me to Rust is the use
by epage 7y ago
As someone who has had to deal with C++ in the Windows and Linux kernels for the last couple of years, the thing that excited me and drew me to Rust is the use of Result rather than exceptions.
Exceptions are incompatible with environments like the Linux kernel. This then makes you incompatible with the stdlib and most third party libraries. It feels like most exception-less C++ libraries also handle error handling in their own way. This means you are in this weird language+library word disconnected from using existing C++ code. You also have to deal with training, not just for kernel + language but kernel + language + special language variant with all of the gotchas of all three.
Herb Sutter is working on improving this situation but I feel it is a ways out and last I looked at it, I was a little uncomfortable with it.
Even once that is handled, there is the issue of what subset of the stdlib is safe to use. Rust has done some work to help with this with nostd and most third party code that isn't compatible with nostd could probably be easily fixed to do so.
bcraig is working on "freestanding" proposals to fix this in C++.
- m0zg 7y agoYou don't have to use exceptions in C++. Google doesn't, for example. Errors are reported with StatusOr<> like so: https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/stubs/statusor.h https://github.com/protocolbuffers/protobuf/blob/master/src/...
- mehrdadn 7y agoThere's nothing that requires exceptions in C++ though. It's not like Python where handling exceptions is a requirement for some facilities in the language or standard library. You can entirely avoid them if you want.
- rkangel 7y agoExceptions are the only way to signal errors from a constructor in C++. If you don't want to use exceptions you end up having to use static factory methods or similar to do all of your constructing and that's a bit dull.
- mehrdadn 7y agoNah, you can just return the status code with a parameter or state variable.
- rkangel 7y agoExcept that you've still got to construct an object (because that's how constructors work), you're just signalling that it's an unusable one. Let's say your object is going to contain another object that wraps a file, but constructing that file wrapper fails because the file doesn't exist. You are forced to construct your object, so you are forced to have something to put there. Maybe it's a dummy, maybe you can 'null it in some way', but it's immediately not as ergonomic. You also then have to either rely on the caller to not use the failed constructed object, or put a check in every method call checking for 'valid'.
- mehrdadn 7y agoDid I say it would be "ergonomic"? You're deliberately refusing to use the correct tool for the job; of course the next-best thing is going to be "not as ergonomic". Is that surprising? It was never "ergonomic" in C to begin with. You had to check status codes and manually allocate and deallocate and construct and destroy everything everywhere. Now we have a language here that automates a ton of this for you, and gives you better tools. It also lets you avoid the individual tools you don't like, while letting you use the others, and while letting you fall back to your old style entirely whenever you prefer, and you're still complaining about it? What are you even complaining about? If you think it's better to have everything to be difficult instead of some things, then just stick with C. There's no point having a pointless argument with me about it.