3 ms·
This is true for any programming language. The problem is being aware of what you really wrote
by kungito 5y ago
This is true for any programming language. The problem is being aware of what you really wrote
- b20000 5y agoNo, you are wrong. C++ is one example. I've been using that language now for about 20 years and I still don't use all of its features. It is possible to write code in that language that you assume will work a certain way but then in practice it does a lot of things you didn't think you signed up for. Recently I started using STL more, after having stayed away from it for most of my career, and the performance of my application went out the window, and I had to override all memory allocation related functions to fully understand where the problem was coming from. It's easy to use the STL and make assumptions about performance, then find out later you get a lot of issues that come with it that you never signed up for. And that is why I don't want rust in the kernel. If a language does a lot of stuff for you, there will be a price to pay.
- nicoburns 5y ago> It is possible to write code in that language that you assume will work a certain way but then in practice it does a lot of things you didn't think you signed up for This is also possible for C. Most commonly around Undefined Behaviour. C only does what you expect it to do if you know the C spec inside out. Rust can have confusing behaviour too, but it is generally much better in this regard than C or C++. You may find it easier to reason about C than Rust, but that's only because you know C better. I find it much easier to reason about Rust.