6 ms·

Really, the only memory unsafe languages still in use are C and C++. If it weren't for the behemoth of legacy code we'd really have this problem more-or-less l

by jerf 3y ago

Really, the only memory unsafe languages still in use are C and C++. If it weren't for the behemoth of legacy code we'd really have this problem more-or-less licked. Unfortunately, that behemoth is still rampaging across the landscape. "Rewrite it in Rust" gets a bit of pushback, perhaps even justified, but at this point in time I'll take anything that just reduces that behemoth in size. The journey of a thousand miles begins with a single step, an elephant is eaten one bite at a time, etc. Rust is just one of the easier and more effective options for a legacy codebase, with the unusual advantage of being able to slip in incrementally. Almost every other language requires a true rewrite.

DeathArrow 3y ago
>Really, the only memory unsafe languages still in use are C and C++. Ada, Fortran, assembly?
- orwin 3y ago
  Isn't Ada memory-safe?
  - 38529977thrw 3y ago
    the internet says "it tries to be". http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-13-9-1.html http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-13-9-1.... https://old.reddit.com/r/ada/comments/mme3jk/is_ada_memory_safe/gtsa411/ https://old.reddit.com/r/ada/comments/mme3jk/is_ada_memory_s...
    - kjs3 3y ago
      In summary, Ada tries to be memory safe by default -- as far as that can be done without requiring automatic memory management and garbage collection -- but deliberate use of "unchecked" language features can break memory safety. In other words, if you go out of your way to use unsafe features, and don't use the features that compensate, Ada is memory unsafe. This has become the goto dismissal of Ada, apparently more popular than "eww...a BEGIN..END language" and "designed by committee/government tainted".
  - SAI_Peregrinus 3y ago
    Ada isn't, Ada/SPARK is. That's a subset of Ada, and while it is the main draw of the language for new projects the majority of extant Ada code predates SPARK.
- munchler 3y ago
  Fortran doesn’t even have dynamic memory allocation, so it’s inherently safe.
  - julian_t 3y ago
    It actually has had this since Fortran-90, and there's even a 'pointer' keyword.
  - ok123456 3y ago
    https://www.ibm.com/docs/en/xffbg/121.141?topic=attributes-allocate https://www.ibm.com/docs/en/xffbg/121.141?topic=attributes-a... No pointer direct arithmetic, though. If you allocate the memory via allocate, you can inquire if it's been deallocated.
- helsinkiandrew 3y ago
  Fortran is probably as bad as C, and Ada isn't truly memory safe - they link to Ada/Spark which is but that doesn't seem to have much widespread use. https://www.adacore.com/about-spark https://www.adacore.com/about-spark
  - KMag 3y ago
    Isn't Ada/Spark in avionics the main use case for Ada these days? So, huge share of a tiny market?
    - helsinkiandrew 3y ago
      > Isn't Ada/Spark in avionics the main use case for Ada these days? Hasn't it always been? I'm no expert but always assumed that it was used basically military and avionics, and perhaps other safety critical equipment.
      - inamberclad 3y ago
        I think it's also used in high speed rail.
    - BirAdam 3y ago
      Also weapon systems.
  - ocschwar 3y ago
    Fortran is used for scientific computing. The crash of crashing a run on someone's Beowulf cluster is high, but the severity is low.
- jerf 3y ago
  Fortran does not end up where I'm too worried about its security. C and C++ does. At the scale I'm talking about I'm not sure we'd even say Fortran is "in use". Assembly is in use, yes, but in 2023 I feel there is generally an understanding of the risks and I haven't seen the "write everything in assembly" crew in about 15 years. The problem is that there's still too many programmers blithely using C and C++ without realizing the risks and thinking they can cowboy through the problems. For every line of vulnerable, dangerous assembly I bet there's thousands of lines of C or C++. There is also the problem that there have been some big bugs that got through even static analysis and fuzz testing, but I'd still be at least reasonably satisfied if all the critical software in C and C++ would be supported by those tools. Interpreters and compilers have had non-zero error rates too. At the scale I'm talking about, Ada is a non-entity as well. It isn't used. "But it is! I'm a professional Ada programmer!" says someone reading this to themselves. In which case I would say, you darned well know what I mean and don't pretend otherwise just to try to score useless internet points. Ada is not a relevant force on the programming world. That may be sad, but it's true.
  - chasil 3y ago
    SQLite is able to carry most of the justification for C itself at this point. Duplicating the DO-178B certification that it has obtained in an endorsed language will be an incredible burden for any who attempt it.
    - steveklabnik 3y ago
      Ferrocene has said in the past they plan on going for DO-178 in the future.
      - Xylakant 3y ago
        But we do not plan on rewriting SQLite, that much I can say :) (My reading is that the GP points to the exemplary achievement that SQLite has reached a close to (security) bugfree, at what I consider a nearly superhuman effort)
- rollcat 3y ago
  Objective-C? Plus everything that needs to directly interface with the above languages. So many Python libraries that are one "funny integer" away from a nightmare debugging session.
2devnull 3y ago
But other languages use c++. I think r for example is widely used and has a ton of packages where people write often buggy c++.
jvanderbot 3y ago
Why are C and C++ considered the same, in these conversations? C++ at least has tools to make life significantly more safe. I can write a buffer overflow in any language, and on the scale of difficulty, ASM-C-C++-Rust-Python covers my experience (from easiest to fuck up to hardest). Yet nobody is calling for us to rewrite everything in python. Why is the line drawn at Rust? It's perfectly simple to trash memory in Rust.
- School-Cotton 3y ago
  Rust is memory safe by default, with unsafety as an optional feature that you basically never need to use unless you’re writing extremely low-level code, need absolute maximum performance, or are interfacing with libraries written in other languages. C++ is unsafe by default. Of course it’s just as easy to write bugs in unsafe Rust as it is in C++ (actually, it’s probably even easier), but defaults matter.
  - corethree 3y ago
    No I've seen libraries that need the user to use it by default. The wgpu library is one example. It's not even that low level. Rust stuff is a little too safe that it influences code organization and modularity as well.
  - jvanderbot 3y ago
    This is a common conception, and I agree to a point. However, interfaces matter. At the interface to _literally any_ system call, unsafe starts to creep out. Either in the wrapper implementation, or in the interface _to_ the system, or even leaking through the wrapper to the caller. At that point, if we have to re-wrap everything in rust to hide the unsafety of the interfaces to the system (sockets, shared mem, etc etc), then why not just write safe cpp wrappers? Yes, people are writing memory overflows in their own code, but I'd argue 99% of the critical security bugs are actually in the unsafe interfaces. And we don't really need a new language to fix that. We just need new interfaces. I love Rust, but using it for anything nontrivial makes the "safe" patina really fade. You're quickly writing what feels like C, with MaybeUninit<X> all over.
corethree 3y ago
Rust is a little too safe imo. I want a rust with just shared pointers and no move semantics. I guess go would be it? But go is too opinionated with a bunch of stupid go specific philosophies like the weird error handling and the stupid packaging rules. Go is also opinionated with concurrency. So that's an issue too.
- photonbeam 3y ago
  Ocaml then?
  - corethree 3y ago
    I like functional, but this isn't what I'm referring too. OCaml by being functional is opinionated.
rewmie 3y ago
[dead]
caskstrength 3y ago
> If it weren't for the behemoth of legacy code we'd really have this problem more-or-less licked. Unfortunately, that behemoth is still rampaging across the landscape. It is not only or even mostly legacy. I'm a systems programmer (in classical sense, not "but my web service is soooo highly loaded and scalable that I will call it systems programming!") and from what I see on the job people start new projects in C and C++ all the time.
- eternityforest 3y ago
  Why do they choose C/C++? Is it just what they and their colleagues already know and nobody wants to be the one to push for change? Easier integration with other C/C++ stuff?
  - caskstrength 3y ago
    From my experience reasons differ for C and C++ programmers. C programmers are often more experienced people who are used to "simple" language that gets out of the way. They don't want to invest time into learning tricky language like Rust with all the intricacies of its type system, borrow checker, etc. Something simpler like Zig might work for them, but it is not on the table at the moment. C++ programmers tend to be people who spent hundreds if not thousands of hours learning its ugly corner cases, reading Meyers and Alexandrescu books, that kind of thing. Sunken cost is immense, they whole careers are built on being "C++ experts" and they dread to abandon it and have to learn another very complex language from scratch. And managers often don't see value in investing time into switching projects to new language. From their PoV it is more like programmers just want to play with a new toy instead of doing "real work".

by jerf 3y ago

DeathArrow 3y ago

>Really, the only memory unsafe languages still in use are C and C++. Ada, Fortran, assembly?

orwin 3y ago
Isn't Ada memory-safe?
- 38529977thrw 3y ago
  the internet says "it tries to be". http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-13-9-1.html http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-13-9-1.... https://old.reddit.com/r/ada/comments/mme3jk/is_ada_memory_safe/gtsa411/ https://old.reddit.com/r/ada/comments/mme3jk/is_ada_memory_s...
  - kjs3 3y ago
    In summary, Ada tries to be memory safe by default -- as far as that can be done without requiring automatic memory management and garbage collection -- but deliberate use of "unchecked" language features can break memory safety. In other words, if you go out of your way to use unsafe features, and don't use the features that compensate, Ada is memory unsafe. This has become the goto dismissal of Ada, apparently more popular than "eww...a BEGIN..END language" and "designed by committee/government tainted".
- SAI_Peregrinus 3y ago
  Ada isn't, Ada/SPARK is. That's a subset of Ada, and while it is the main draw of the language for new projects the majority of extant Ada code predates SPARK.
munchler 3y ago
Fortran doesn’t even have dynamic memory allocation, so it’s inherently safe.
- julian_t 3y ago
  It actually has had this since Fortran-90, and there's even a 'pointer' keyword.
- ok123456 3y ago
  https://www.ibm.com/docs/en/xffbg/121.141?topic=attributes-allocate https://www.ibm.com/docs/en/xffbg/121.141?topic=attributes-a... No pointer direct arithmetic, though. If you allocate the memory via allocate, you can inquire if it's been deallocated.
helsinkiandrew 3y ago
Fortran is probably as bad as C, and Ada isn't truly memory safe - they link to Ada/Spark which is but that doesn't seem to have much widespread use. https://www.adacore.com/about-spark https://www.adacore.com/about-spark
- KMag 3y ago
  Isn't Ada/Spark in avionics the main use case for Ada these days? So, huge share of a tiny market?
  - helsinkiandrew 3y ago
    > Isn't Ada/Spark in avionics the main use case for Ada these days? Hasn't it always been? I'm no expert but always assumed that it was used basically military and avionics, and perhaps other safety critical equipment.
    - inamberclad 3y ago
      I think it's also used in high speed rail.
  - BirAdam 3y ago
    Also weapon systems.
- ocschwar 3y ago
  Fortran is used for scientific computing. The crash of crashing a run on someone's Beowulf cluster is high, but the severity is low.
jerf 3y ago
Fortran does not end up where I'm too worried about its security. C and C++ does. At the scale I'm talking about I'm not sure we'd even say Fortran is "in use". Assembly is in use, yes, but in 2023 I feel there is generally an understanding of the risks and I haven't seen the "write everything in assembly" crew in about 15 years. The problem is that there's still too many programmers blithely using C and C++ without realizing the risks and thinking they can cowboy through the problems. For every line of vulnerable, dangerous assembly I bet there's thousands of lines of C or C++. There is also the problem that there have been some big bugs that got through even static analysis and fuzz testing, but I'd still be at least reasonably satisfied if all the critical software in C and C++ would be supported by those tools. Interpreters and compilers have had non-zero error rates too. At the scale I'm talking about, Ada is a non-entity as well. It isn't used. "But it is! I'm a professional Ada programmer!" says someone reading this to themselves. In which case I would say, you darned well know what I mean and don't pretend otherwise just to try to score useless internet points. Ada is not a relevant force on the programming world. That may be sad, but it's true.
- chasil 3y ago
  SQLite is able to carry most of the justification for C itself at this point. Duplicating the DO-178B certification that it has obtained in an endorsed language will be an incredible burden for any who attempt it.
  - steveklabnik 3y ago
    Ferrocene has said in the past they plan on going for DO-178 in the future.
    - Xylakant 3y ago
      But we do not plan on rewriting SQLite, that much I can say :) (My reading is that the GP points to the exemplary achievement that SQLite has reached a close to (security) bugfree, at what I consider a nearly superhuman effort)
rollcat 3y ago
Objective-C? Plus everything that needs to directly interface with the above languages. So many Python libraries that are one "funny integer" away from a nightmare debugging session.

2devnull 3y ago

But other languages use c++. I think r for example is widely used and has a ton of packages where people write often buggy c++.

jvanderbot 3y ago

Why are C and C++ considered the same, in these conversations? C++ at least has tools to make life significantly more safe. I can write a buffer overflow in any language, and on the scale of difficulty, ASM-C-C++-Rust-Python covers my experience (from easiest to fuck up to hardest). Yet nobody is calling for us to rewrite everything in python. Why is the line drawn at Rust? It's perfectly simple to trash memory in Rust.

School-Cotton 3y ago
Rust is memory safe by default, with unsafety as an optional feature that you basically never need to use unless you’re writing extremely low-level code, need absolute maximum performance, or are interfacing with libraries written in other languages. C++ is unsafe by default. Of course it’s just as easy to write bugs in unsafe Rust as it is in C++ (actually, it’s probably even easier), but defaults matter.
- corethree 3y ago
  No I've seen libraries that need the user to use it by default. The wgpu library is one example. It's not even that low level. Rust stuff is a little too safe that it influences code organization and modularity as well.
- jvanderbot 3y ago
  This is a common conception, and I agree to a point. However, interfaces matter. At the interface to _literally any_ system call, unsafe starts to creep out. Either in the wrapper implementation, or in the interface _to_ the system, or even leaking through the wrapper to the caller. At that point, if we have to re-wrap everything in rust to hide the unsafety of the interfaces to the system (sockets, shared mem, etc etc), then why not just write safe cpp wrappers? Yes, people are writing memory overflows in their own code, but I'd argue 99% of the critical security bugs are actually in the unsafe interfaces. And we don't really need a new language to fix that. We just need new interfaces. I love Rust, but using it for anything nontrivial makes the "safe" patina really fade. You're quickly writing what feels like C, with MaybeUninit<X> all over.

corethree 3y ago

Rust is a little too safe imo. I want a rust with just shared pointers and no move semantics. I guess go would be it? But go is too opinionated with a bunch of stupid go specific philosophies like the weird error handling and the stupid packaging rules. Go is also opinionated with concurrency. So that's an issue too.

photonbeam 3y ago
Ocaml then?
- corethree 3y ago
  I like functional, but this isn't what I'm referring too. OCaml by being functional is opinionated.

rewmie 3y ago

[dead]

caskstrength 3y ago

> If it weren't for the behemoth of legacy code we'd really have this problem more-or-less licked. Unfortunately, that behemoth is still rampaging across the landscape. It is not only or even mostly legacy. I'm a systems programmer (in classical sense, not "but my web service is soooo highly loaded and scalable that I will call it systems programming!") and from what I see on the job people start new projects in C and C++ all the time.

eternityforest 3y ago
Why do they choose C/C++? Is it just what they and their colleagues already know and nobody wants to be the one to push for change? Easier integration with other C/C++ stuff?
- caskstrength 3y ago
  From my experience reasons differ for C and C++ programmers. C programmers are often more experienced people who are used to "simple" language that gets out of the way. They don't want to invest time into learning tricky language like Rust with all the intricacies of its type system, borrow checker, etc. Something simpler like Zig might work for them, but it is not on the table at the moment. C++ programmers tend to be people who spent hundreds if not thousands of hours learning its ugly corner cases, reading Meyers and Alexandrescu books, that kind of thing. Sunken cost is immense, they whole careers are built on being "C++ experts" and they dread to abandon it and have to learn another very complex language from scratch. And managers often don't see value in investing time into switching projects to new language. From their PoV it is more like programmers just want to play with a new toy instead of doing "real work".