4 ms·

From the perspective of people who don't know Rust, it's not a sweet nectar, but a suspicious murky liquid. From the perspective of people who don't like aspec

From the perspective of people who don't know Rust, it's not a sweet nectar, but a suspicious murky liquid. From the perspective of people who don't like aspects of Rust, it's a yucky goo. This is _not_ like with C. Few people are enamored with C, but - the language itself is relatively simple (Duff's device notwithstanding...), so in my analogy it's like water. You may not adore it, but you can see through it, and you'll be ok with gulping it down to quench your thirst.

nicoburns 5y ago
> From the perspective of people who don't like aspects of Rust, it's a yucky goo. > This is _not_ like with C I beg to differ. This is exactly how I feel about C. C is the language that's confusing as hell to read for anything other than really simple use cases AND makes it super easy for me to shoot myself in the foot.
- b20000 5y ago
  C is what you program is what you get. and i think that is pretty important.
  - pjmlp 5y ago
    C is what you program is what you might get. Know thy standard and thy compiler optmizations, least you be surprised by the outcome.
  - kungito 5y ago
    This is true for any programming language. The problem is being aware of what you really wrote
    - b20000 5y ago
      No, 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.
  - einpoklum 5y ago
    With modern compilers, there is no such thing as what you program is what you get.
    - randomswede 5y ago
      As long as you stay away from compiler-dependent, platform-dependent, and/or undefined behaviour, you should be fine. Main problem is that a surprising ab´mount of "looks normal" code is actually UB.
      - einpoklum 5y ago
        You would be "fine", but the compiler will optimize away alot of your code, and will rearrange a lot of the rest. I wasn't even talking about platform-dependent or undefined behavior.
merb 5y ago
> Few people are enamored with C, but - the language itself is relatively simple if you don't use pointers, yeah. but like you can't built anything useful without pointers.
- b20000 5y ago
  if you do not understand pointers and cannot work with them, you probably should not be a software engineer.
  - danShumway 5y ago
    I'm not sure that it's the concept of pointers that make C code harder to maintain than other languages. Lots of languages have pointers, including Rust. It's a question of whether unguarded pointers (and a lack of language features that keep pointer math from devolving into an unreadable mess) are good to have in areas where pointer errors can result in critical bugs. We started discouraging goto statements not because developers didn't understand them, but because they did understand them, and they understood that the tools you use influence the type of code you write. And Rust doesn't even really get rid of pointers, it just adds rules around them. We all accept some degree of abstraction/safety tradeoff, otherwise we'd program in lower-level languages than C that are even simpler and even easier to understand. C does introduce a lot of complexity over more primitive assembly languages. And Rust introduces a lot of complexity over C. Different people pick different points where they think the tradeoffs are optimized. But we have a pretty large amount of data suggesting that even <quote>good</quote> programmers in industry make pointer errors in C. So it's pretty obviously not lack of understanding that's causing these issues, it's that unrestricted memory access and pointer math is inherently error-prone. Whether it's SO error-prone that's it's worth introducing a much more complicated, rigid language into the kernel is left as an exercise for the reader. There is a downside to introducing more complexity here, all abstractions have downsides. But it's real dismissive to say that if everyone understood C pointers then their code wouldn't ever devolve into an unreadable mess. I just don't think that's an opinion that can be backed up by any real evidence, pretty much every org struggles to some extent with writing secure C code. And we have a lot of experience in the field of software engineering that should have taught us by now that sometimes unreadable code is the result of language affordances and patterns.

nicoburns 5y ago

> From the perspective of people who don't like aspects of Rust, it's a yucky goo. > This is _not_ like with C I beg to differ. This is exactly how I feel about C. C is the language that's confusing as hell to read for anything other than really simple use cases AND makes it super easy for me to shoot myself in the foot.

b20000 5y ago
C is what you program is what you get. and i think that is pretty important.
- pjmlp 5y ago
  C is what you program is what you might get. Know thy standard and thy compiler optmizations, least you be surprised by the outcome.
- kungito 5y ago
  This is true for any programming language. The problem is being aware of what you really wrote
  - b20000 5y ago
    No, 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.
- einpoklum 5y ago
  With modern compilers, there is no such thing as what you program is what you get.
  - randomswede 5y ago
    As long as you stay away from compiler-dependent, platform-dependent, and/or undefined behaviour, you should be fine. Main problem is that a surprising ab´mount of "looks normal" code is actually UB.
    - einpoklum 5y ago
      You would be "fine", but the compiler will optimize away alot of your code, and will rearrange a lot of the rest. I wasn't even talking about platform-dependent or undefined behavior.

merb 5y ago

> Few people are enamored with C, but - the language itself is relatively simple if you don't use pointers, yeah. but like you can't built anything useful without pointers.

b20000 5y ago
if you do not understand pointers and cannot work with them, you probably should not be a software engineer.
- danShumway 5y ago
  I'm not sure that it's the concept of pointers that make C code harder to maintain than other languages. Lots of languages have pointers, including Rust. It's a question of whether unguarded pointers (and a lack of language features that keep pointer math from devolving into an unreadable mess) are good to have in areas where pointer errors can result in critical bugs. We started discouraging goto statements not because developers didn't understand them, but because they did understand them, and they understood that the tools you use influence the type of code you write. And Rust doesn't even really get rid of pointers, it just adds rules around them. We all accept some degree of abstraction/safety tradeoff, otherwise we'd program in lower-level languages than C that are even simpler and even easier to understand. C does introduce a lot of complexity over more primitive assembly languages. And Rust introduces a lot of complexity over C. Different people pick different points where they think the tradeoffs are optimized. But we have a pretty large amount of data suggesting that even <quote>good</quote> programmers in industry make pointer errors in C. So it's pretty obviously not lack of understanding that's causing these issues, it's that unrestricted memory access and pointer math is inherently error-prone. Whether it's SO error-prone that's it's worth introducing a much more complicated, rigid language into the kernel is left as an exercise for the reader. There is a downside to introducing more complexity here, all abstractions have downsides. But it's real dismissive to say that if everyone understood C pointers then their code wouldn't ever devolve into an unreadable mess. I just don't think that's an opinion that can be backed up by any real evidence, pretty much every org struggles to some extent with writing secure C code. And we have a lot of experience in the field of software engineering that should have taught us by now that sometimes unreadable code is the result of language affordances and patterns.