5 ms·

Spiteful downvotes notwithstanding, there really is nothing Linus can do to stop you coding your eBPF fragments in C++.

by ncmncm 4y ago

galangalalgol 4y ago
eBPF doesn't prevent UB, just keeps that code from hurting the rest of the kernel right? I have written c++ for 28 years and I can only recall letting something rust would have protected me from make it out of test once. That I know of... A coworker found some UB in a rather large c++98 codebase recently. It wasn't exactly idiomatic modern c++. But the same person writing the same code in c++20 would just have had explicit and auto in more places. It was a use after free on the stack that wasn't terribly subtle but I only found it because I knew something was there. Cppcheck and clang-tidy were no help. Debug builds didn't exhibit the UB with g++ or clang, clang didn't exhibit it with -O3 (optimized out), but g++ did. Asan would have caught it, if they used asan (they don't) and if they had unit test coverage for that branch (also no). So experienced c++ developers with years of experience (no novices on that codebase) made an error that can't be caught by static analysis, and requires 100% branch coverage for asan to catch. It eventually popped up in production. I find modern c++ much more pleasant to write than rust. I like that it is easy to interface with the rest of the world. I hate spending eons to get unit tests to find that last path theough the code in a meaningful way. I hate waiting for pipelines to run unit tests and coverage to find a mistake. Modern C++ built with static analysis (including modernization checks) takes as long as a rust builds, but still doesn't catch as much stuff. I'm not using rust yet, but I'm planning to start. I'm tired of this stuff, it's been almost 30 years.
- selfmodruntime 4y ago
  You‘re also missing that there is a chance of UB in your code base for which your compiler just assumes your original intention and will then go on to correct it
  - fyvhbhn 4y ago
    Could you share an example, please?
    - galangalalgol 4y ago
      Well the use after free on the stack was getting the aame memory over and over so it just happened to work in the case above. Until it didn't.
- speed_spread 4y ago
  Going from C++ to Rust, keep in mind that Rust does not mainly solve a technical problem, but a human one. It's not so much about making programs that run fast and don't fail than about making such code writable and maintainable by a wide variety of people over a long period of time. The initial Rust learning curve is steep but the competence curve is actually much flatter than C++, IMO. It's worth reiterating this because this is not as apparent to a seasoned systems programmer.
  - galangalalgol 4y ago
    I do find that surprising. I have never used rust for more than toy programs, and I don't use a fraction of what is available, how can a language with so many features have a flat competency curve? I can easily write something that doesn't use traits or iterators, panics all the time, and calls clone all over the place to satiate the BC and call it a day right? I could create very unidiomatic code that was still correct, but not performant or easy to read/use. I suppose the fact I was able to make that list without ever having used the language in anger maybe makes your point... But with all those features surely I'm missing as many pitfalls as I know about?
    - sebzim4500 4y ago
      >I can easily write something that doesn't use traits or iterators Do you mean that you aren't using them at all or you aren't defining your own? Because I would expect any nontrivial rust program (outside of some obscure embedded context maybe) to make use of the traits that are in the standard library/your dependencies. Similarly, you can't even write a for loop without using iterators. >panics all the time That might be fine, depending on your usecase. Presumably if you were going to put it into production you would go through and handle the errors. Crucially, by grepping for `unwrap` and `expect` you can find the panics very easily. >calls clone all over the place to satiate the BC If it's not a performance issue then this might be fine. >I could create very unidiomatic code that was still correct, but not performant or easy to read/use This is true in every language. The value proposition of rust is that if you do write idiomatic code then it will likely be reasonably performant and easy to maintain. >But with all those features surely I'm missing as many pitfalls as I know about? Maybe, but not every program will need to use every feature. Quite a few of the more advanced features are mainly useful for libraries, for example.
- deleted 4y ago
  [deleted]
seabrookmx 4y ago
Correct. And eBPF is cool, but it's not a replacement for in-tree drivers. It also goes through a strict verification process in the kernel before being run which among other things, imposes limits on looping.
throwaway894345 4y ago
I didn't downvote you out of spite, but because of the factual errors in your post, notably: > Coding C++, you need only choose known-correct primitives to get the same level of assurance. C++ has no such primitives that offer the same level of assurance as Rust does. Not every disagreement is spiteful.
bitcharmer 4y ago
I downvoted you for being hilariously incorrect; in particular: > Coding C++, you need only choose known-correct primitives to get the same level of assurance.

Spiteful downvotes notwithstanding, there really is nothing Linus can do to stop you coding your eBPF fragments in C++.

by ncmncm 4y ago

Spiteful downvotes notwithstanding, there really is nothing Linus can do to stop you coding your eBPF fragments in C++.

eBPF doesn't prevent UB, just keeps that code from hurting the rest of the kernel right? I have written c++ for 28 years and I can only recall letting something rust would have protected me from make it out of test once. That I know of... A coworker found some UB in a rather large c++98 codebase recently. It wasn't exactly idiomatic modern c++. But the same person writing the same code in c++20 would just have had explicit and auto in more places. It was a use after free on the stack that wasn't terribly subtle but I only found it because I knew something was there. Cppcheck and clang-tidy were no help. Debug builds didn't exhibit the UB with g++ or clang, clang didn't exhibit it with -O3 (optimized out), but g++ did. Asan would have caught it, if they used asan (they don't) and if they had unit test coverage for that branch (also no). So experienced c++ developers with years of experience (no novices on that codebase) made an error that can't be caught by static analysis, and requires 100% branch coverage for asan to catch. It eventually popped up in production. I find modern c++ much more pleasant to write than rust. I like that it is easy to interface with the rest of the world. I hate spending eons to get unit tests to find that last path theough the code in a meaningful way. I hate waiting for pipelines to run unit tests and coverage to find a mistake. Modern C++ built with static analysis (including modernization checks) takes as long as a rust builds, but still doesn't catch as much stuff. I'm not using rust yet, but I'm planning to start. I'm tired of this stuff, it's been almost 30 years.

selfmodruntime 4y ago
You‘re also missing that there is a chance of UB in your code base for which your compiler just assumes your original intention and will then go on to correct it
- fyvhbhn 4y ago
  Could you share an example, please?
  - galangalalgol 4y ago
    Well the use after free on the stack was getting the aame memory over and over so it just happened to work in the case above. Until it didn't.
speed_spread 4y ago
Going from C++ to Rust, keep in mind that Rust does not mainly solve a technical problem, but a human one. It's not so much about making programs that run fast and don't fail than about making such code writable and maintainable by a wide variety of people over a long period of time. The initial Rust learning curve is steep but the competence curve is actually much flatter than C++, IMO. It's worth reiterating this because this is not as apparent to a seasoned systems programmer.
- galangalalgol 4y ago
  I do find that surprising. I have never used rust for more than toy programs, and I don't use a fraction of what is available, how can a language with so many features have a flat competency curve? I can easily write something that doesn't use traits or iterators, panics all the time, and calls clone all over the place to satiate the BC and call it a day right? I could create very unidiomatic code that was still correct, but not performant or easy to read/use. I suppose the fact I was able to make that list without ever having used the language in anger maybe makes your point... But with all those features surely I'm missing as many pitfalls as I know about?
  - sebzim4500 4y ago
    >I can easily write something that doesn't use traits or iterators Do you mean that you aren't using them at all or you aren't defining your own? Because I would expect any nontrivial rust program (outside of some obscure embedded context maybe) to make use of the traits that are in the standard library/your dependencies. Similarly, you can't even write a for loop without using iterators. >panics all the time That might be fine, depending on your usecase. Presumably if you were going to put it into production you would go through and handle the errors. Crucially, by grepping for `unwrap` and `expect` you can find the panics very easily. >calls clone all over the place to satiate the BC If it's not a performance issue then this might be fine. >I could create very unidiomatic code that was still correct, but not performant or easy to read/use This is true in every language. The value proposition of rust is that if you do write idiomatic code then it will likely be reasonably performant and easy to maintain. >But with all those features surely I'm missing as many pitfalls as I know about? Maybe, but not every program will need to use every feature. Quite a few of the more advanced features are mainly useful for libraries, for example.
deleted 4y ago
[deleted]

seabrookmx 4y ago

Correct. And eBPF is cool, but it's not a replacement for in-tree drivers. It also goes through a strict verification process in the kernel before being run which among other things, imposes limits on looping.

throwaway894345 4y ago

I didn't downvote you out of spite, but because of the factual errors in your post, notably: > Coding C++, you need only choose known-correct primitives to get the same level of assurance. C++ has no such primitives that offer the same level of assurance as Rust does. Not every disagreement is spiteful.

bitcharmer 4y ago

I downvoted you for being hilariously incorrect; in particular: > Coding C++, you need only choose known-correct primitives to get the same level of assurance.