11 ms·

> I'm just old and moany, and I need to step aside for bigger and better things such as Rust. You are. This is firm "I don't want to have to learn new things"

> I'm just old and moany, and I need to step aside for bigger and better things such as Rust. You are. This is firm "I don't want to have to learn new things" territory, which isn't a viable attitude in this industry. In any case Rust is usually easier than C (excluding buggy C which is very easy to write), and certainly easier than actually learning the Git or Linux codebases.

hedgehog 1y ago
I think it is often under appreciated by people who haven't worked in security how hard high quality C is in practice.
- uecker 1y ago
  We might also have different priorities. I do not care too much that google and apple want to lock down their smartphone spyware and sales platforms. The supply chain risks and maintenance burden imposed onto me by the Rust ecosystem are much more of an concern.
  - hedgehog 1y ago
    I don't know what this has to do with locking down phones, but I do appreciate not getting compromised just for cloning a repo or opening my laptop at a coffee shop.
    - germandiago 1y ago
      Who says you do not? :)
      - hedgehog 1y ago
        Oh, I think it's a real problem, that's why I'm in favor of improved tools.
    - sunshowers 1y ago
      (There is a persistent idea that the lack of memory safety in C is good because it allows people to jailbreak their phones.)
      - rcxdude 1y ago
        It is a sad thing but I do root against secure boot initiatives because they almost entirely work to limit user's freedom instead of improving their security.
      - uecker 1y ago
        This is not what I said, but memory safety is certainly not anything which is a high priority for my own security. I still think memory safety is important and I also think Rust is an interesting language, but... the hype is exaggerated and driven by certain industry interests.
        IshKebab 1y ago
        Rust isn't popular just because of memory safety though. I think the memory safety message is maybe a little too loud. It's also a modern language with fantastic tooling, very high quality library ecosystem and a strong type system that reduces the chance of all kinds of bugs. It's obviously not perfect: compile time is ... ok, there aren't any mature GUI toolkits (though that's true of many languages), async Rust has way too many footguns. But it's still waaaaay better than C or C++. In a different league.
        uecker 1y ago
        Rust is a nice language, but it pushed too aggressively with the argument of "memory safety" at all cost ignoring other considerations. And Cargo is certainly a disaster even though it may be considered "fantastic tooling" by some. In any case, I do not think it is funny that I now depend on packages without timely security update in my distribution. This makes me less secure.
        scns 1y ago
    - account42 1y ago
      How often do you clone a repo and don't immediately run build commands that execute scripts provided by the repo.
toast0 1y ago
> You are. This is firm "I don't want to have to learn new things" territory, which isn't a viable attitude in this industry. It's viable, but limiting. Sometimes you have to do things you don't want to, which is why it's called work. But if you can choose what platforms you work on, you can orient towards things where things change less, and then you don't need to learn new things as often. Chances are, if you get into the weeds in a lot of C programs, Rust is in your future, but it's viable to not want that, and to moan about it while doing it when you need to.
- altairprime 1y ago
  No one’s laying off COBOL programmers. Specialization has its upsides once the market isn’t saturated!
  - IshKebab 1y ago
    Well only because 99% of the world's COBOL developers were laid off decades ago (or switched to another language).
    - altairprime 1y ago
      The more things change,
  - Tadpole9181 1y ago
    As someone with experience in this specific niche, yes they absolutely are. There are no longer ten thousand retail chains asking for COBOL-based counterpoint PoS mods on a yearly basis. The COBOL market is basically tenured experts in existing systems or polyglots helping migrate the systems to VB or C# at this point. The market has plummeted and now it's in the final deflationary shrink before death.
    - altairprime 1y ago
      Ah, damn, I’m sad to hear that. Always respected the language. :/
oreally 1y ago
[flagged]
- pornel 1y ago
  Rust is over 10 years old now. It has a track record of delivering what it promises, and a very satisfied growing userbase. OTOH static analyzers for C have been around for longer than Rust, and we're still waiting for them to disprove Rice's theorem. AI tools so far are famous for generating low-quality code, and generating bogus vulnerability reports. They may eventually get better and end up being used to make C code secure - see DARPA's TRACTOR program.
  - nanolith 1y ago
    The applicability of Rice's theorem with respect to static analysis or abstract interpretation is more complex than you implied. First, static analysis tools are largely pattern-oriented. Pattern matching is how they sidestep undecidability. These tools have their place, but they aren't trying to be the tooling you or the parent claim. Instead, they are more useful to enforce coding style. This can be used to help with secure software development practices, but only by enforcing idiomatic style. Bounded model checkers, on the other hand, are this tooling. They don't have to disprove Rice's theorem to work. In fact, they work directly with this theorem. They transform code into state equations that are run through an SMT solver. They are looking for logic errors, use-after-free, buffer overruns, etc. But, they also fail code for unterminated execution within the constraints of the simulation. If abstract interpretation through SMT states does not complete in a certain number of steps, then this is also considered a failure. The function or subset of the program only passes if the SMT solver can't find a satisfactory state that triggers one of these issues, through any possible input or external state. These model checkers also provide the ability for user-defined assertions, making it possible to build and verify function contracts. This allows proof engineers to tie in proofs about higher level properties of code without having to build constructive proofs of all of this code. Rust has its own issues. For instance, its core library is unsafe, because it has to use unsafe operations to interface with the OS, or to build containers or memory management models that simply can't be described with the borrow checker. This has led to its own CVEs. To strengthen the core library, core Rust developers have started using Kani -- a bounded model checker like those available for C or other languages. Bounded model checking works. This tooling can be used to make either C or Rust safer. It can be used to augment proofs of theorems built in a proof assistant to extend this to implementation. The overhead of model checking is about that of unit testing, once you understand how to use it. It is significantly less expensive to teach C developers how to model check their software using CBMC than it is to teach them Rust and then have them port code to Rust. Using CBMC properly, one can get better security guarantees than using vanilla Rust. Overall, an Ada + Spark, CBMC + C, Kani + Rust strategy coupled with constructive theory and proofs regarding overall architectural guarantees will yield equivalent safety and security. I'd trust such pairings of process and tooling -- regardless of language choice -- over any LLM derived solutions.
ajsnigrutin 1y ago
It's not "having to learn something new", but "having to be good at two things, both of which are full languages with their own specifics, problems and ways to solve them, two sets of compilers and some duct tape to hold them together. It's like putting steak on a pizza... pizza is good, steak is good, pizza on a steak might be good too, but to actually do that in production, you now need two prep stations and you can't mess up either one.
hoppp 1y ago
Technical debt is real tho and the rust-c interop is not the best ever. Why not rewrite the entire git in rust and have two compatible versions?

hedgehog 1y ago

I think it is often under appreciated by people who haven't worked in security how hard high quality C is in practice.

uecker 1y ago
We might also have different priorities. I do not care too much that google and apple want to lock down their smartphone spyware and sales platforms. The supply chain risks and maintenance burden imposed onto me by the Rust ecosystem are much more of an concern.
- hedgehog 1y ago
  I don't know what this has to do with locking down phones, but I do appreciate not getting compromised just for cloning a repo or opening my laptop at a coffee shop.
  - germandiago 1y ago
    Who says you do not? :)
    - hedgehog 1y ago
      Oh, I think it's a real problem, that's why I'm in favor of improved tools.
  - sunshowers 1y ago
    (There is a persistent idea that the lack of memory safety in C is good because it allows people to jailbreak their phones.)
    - rcxdude 1y ago
      It is a sad thing but I do root against secure boot initiatives because they almost entirely work to limit user's freedom instead of improving their security.
    - uecker 1y ago
      This is not what I said, but memory safety is certainly not anything which is a high priority for my own security. I still think memory safety is important and I also think Rust is an interesting language, but... the hype is exaggerated and driven by certain industry interests.
      - IshKebab 1y ago
        Rust isn't popular just because of memory safety though. I think the memory safety message is maybe a little too loud. It's also a modern language with fantastic tooling, very high quality library ecosystem and a strong type system that reduces the chance of all kinds of bugs. It's obviously not perfect: compile time is ... ok, there aren't any mature GUI toolkits (though that's true of many languages), async Rust has way too many footguns. But it's still waaaaay better than C or C++. In a different league.
        uecker 1y ago
        Rust is a nice language, but it pushed too aggressively with the argument of "memory safety" at all cost ignoring other considerations. And Cargo is certainly a disaster even though it may be considered "fantastic tooling" by some. In any case, I do not think it is funny that I now depend on packages without timely security update in my distribution. This makes me less secure.
        scns 1y ago
  - account42 1y ago
    How often do you clone a repo and don't immediately run build commands that execute scripts provided by the repo.

toast0 1y ago

> You are. This is firm "I don't want to have to learn new things" territory, which isn't a viable attitude in this industry. It's viable, but limiting. Sometimes you have to do things you don't want to, which is why it's called work. But if you can choose what platforms you work on, you can orient towards things where things change less, and then you don't need to learn new things as often. Chances are, if you get into the weeds in a lot of C programs, Rust is in your future, but it's viable to not want that, and to moan about it while doing it when you need to.

altairprime 1y ago
No one’s laying off COBOL programmers. Specialization has its upsides once the market isn’t saturated!
- IshKebab 1y ago
  Well only because 99% of the world's COBOL developers were laid off decades ago (or switched to another language).
  - altairprime 1y ago
    The more things change,
- Tadpole9181 1y ago
  As someone with experience in this specific niche, yes they absolutely are. There are no longer ten thousand retail chains asking for COBOL-based counterpoint PoS mods on a yearly basis. The COBOL market is basically tenured experts in existing systems or polyglots helping migrate the systems to VB or C# at this point. The market has plummeted and now it's in the final deflationary shrink before death.
  - altairprime 1y ago
    Ah, damn, I’m sad to hear that. Always respected the language. :/

oreally 1y ago

[flagged]

pornel 1y ago
Rust is over 10 years old now. It has a track record of delivering what it promises, and a very satisfied growing userbase. OTOH static analyzers for C have been around for longer than Rust, and we're still waiting for them to disprove Rice's theorem. AI tools so far are famous for generating low-quality code, and generating bogus vulnerability reports. They may eventually get better and end up being used to make C code secure - see DARPA's TRACTOR program.
- nanolith 1y ago
  The applicability of Rice's theorem with respect to static analysis or abstract interpretation is more complex than you implied. First, static analysis tools are largely pattern-oriented. Pattern matching is how they sidestep undecidability. These tools have their place, but they aren't trying to be the tooling you or the parent claim. Instead, they are more useful to enforce coding style. This can be used to help with secure software development practices, but only by enforcing idiomatic style. Bounded model checkers, on the other hand, are this tooling. They don't have to disprove Rice's theorem to work. In fact, they work directly with this theorem. They transform code into state equations that are run through an SMT solver. They are looking for logic errors, use-after-free, buffer overruns, etc. But, they also fail code for unterminated execution within the constraints of the simulation. If abstract interpretation through SMT states does not complete in a certain number of steps, then this is also considered a failure. The function or subset of the program only passes if the SMT solver can't find a satisfactory state that triggers one of these issues, through any possible input or external state. These model checkers also provide the ability for user-defined assertions, making it possible to build and verify function contracts. This allows proof engineers to tie in proofs about higher level properties of code without having to build constructive proofs of all of this code. Rust has its own issues. For instance, its core library is unsafe, because it has to use unsafe operations to interface with the OS, or to build containers or memory management models that simply can't be described with the borrow checker. This has led to its own CVEs. To strengthen the core library, core Rust developers have started using Kani -- a bounded model checker like those available for C or other languages. Bounded model checking works. This tooling can be used to make either C or Rust safer. It can be used to augment proofs of theorems built in a proof assistant to extend this to implementation. The overhead of model checking is about that of unit testing, once you understand how to use it. It is significantly less expensive to teach C developers how to model check their software using CBMC than it is to teach them Rust and then have them port code to Rust. Using CBMC properly, one can get better security guarantees than using vanilla Rust. Overall, an Ada + Spark, CBMC + C, Kani + Rust strategy coupled with constructive theory and proofs regarding overall architectural guarantees will yield equivalent safety and security. I'd trust such pairings of process and tooling -- regardless of language choice -- over any LLM derived solutions.

ajsnigrutin 1y ago

It's not "having to learn something new", but "having to be good at two things, both of which are full languages with their own specifics, problems and ways to solve them, two sets of compilers and some duct tape to hold them together. It's like putting steak on a pizza... pizza is good, steak is good, pizza on a steak might be good too, but to actually do that in production, you now need two prep stations and you can't mess up either one.

hoppp 1y ago

Technical debt is real tho and the rust-c interop is not the best ever. Why not rewrite the entire git in rust and have two compatible versions?