6 ms·

I thought at first that specific list of languages might have just been theregister.com's editorialized list. But it's in the actual document[1]. "These inher

• MonkeyMalarky 4y ago
  I wouldn't put Python on that list because of how many packages are wrapped up C/C++ code. I know the same is done with Java and JNI but the pervasiveness of it is not at the same level.
  • tyingq 4y ago
    True, though Ruby made the list, and there's a fair amount of gems linked to native libraries and/or using their own C code.
    • MonkeyMalarky 4y ago
      Hah, I had no idea, I don't know anything about Ruby except it also suffers from a Gil? Maybe they're using the other golden rule: All languages starting with a P are old, crusty and should be avoided.
      • krallja 4y ago
        That's why Raku was invented!
      • tmtvl 4y ago
        Hey now, PureScript is not that old.
      • pmontra 4y ago
        It suffers from a GIL to prevent race conditions in the data structures of the interpreter, which is written in C. C extensions add to the problem. I'm not sure that this kind of languages can be classified as memory safe. Maybe JRuby, which runs on the JVM. Anyway, even without C extensions a malicious input might trigger a memory related vulnerability in the interpreter. A compiled program written in a memory safe language could suffer from a compiler bug. Did it happen to Go and Rust?
  • drewbug01 4y ago
    They actually address this: > Even with a memory safe language, memory management is not entirely memory safe. [...] Memory safe languages can also use libraries written in non-memory safe languages and thus can contain unsafe memory functionality. Although these ways of including memory unsafe mechanisms subvert the inherent memory safety, they help to localize where memory problems could exist, allowing for extra scrutiny on those sections of code. Which I suppose is a reasonable way to put it. It's been said elsewhere, but my read of this document is that this is not a _definitive_ list of languages you should use, but rather a list of languages that make it much more difficult for programmers to introduce memory-safety bugs.
  • PartiallyTyped 4y ago
    Also ... pickling is a mess. It's possible to put payload and execute arbitrary code.
  • bilbo0s 4y ago
    Happens with all those languages. It's as simple as an "unsafe" keyword. But yes, Python is, far and away, the most egregious example. Really, in the long term, "unsafe" and FFI interfaces should be removed from C#, Java, and Rust. That's the only way to be sure. in fact, I'd be willing to bet that in the short to medium term, with this recommendation, government contractors will soon be required to submit code that does not use these facilities. If you can't do it in C#, use Rust, if you can't do it in Rust, use Java, but you probably will no longer be allowed to pull in that wiz-bang c++ library.
    • 3a2d29 4y ago
      Maybe I am misunderstanding your comment, but there’s no way “unsafe” will be removed from rust. It’s essential to doing many things.
• Filligree 4y ago
  With the notable exception of Ruby, these are all relatively high-performance programming languages that can reasonably used for large amounts of data processing. I think they may simply be the first ones that came to the writer's mind.
• bluGill 4y ago
  I'm surprised ADA isn't on the list since it is memory safe in modern versions (like rust you can turn that off, though it isn't as obvious as unsafe when you do). Even modern C++ is reasonably memory safe, but someone needs to rewrite the old code you interface with to get that.
  • couchand 4y ago
    You can't "turn off" memory safety in Rust, that's an absolutely misleading way to describe unsafe.
    • pencilguin 4y ago
      Do you prefer "opt out"?
      • Filligree 4y ago
        I suppose the point GP is trying to make is that unsafe blocks don't really change the pre-existing safeties, it 'just' lets you also do things which are unsafe, but which have different syntax. Already-safe code remains safe if you wrap it with unsafe. The implications to a code reviewer don't change much from that, however.
        • pencilguin 4y ago
          What is being turned off is not safety itself, but automatic enforcement of rules. If course no one wants to ship actually unsafe code, and it is very rare to do it in Rust or modern C++ programs. But it is depressingly common in C programs and mostly-old programs like Chromium, and in the C libraries that programs of all kinds still depend on.
  • Jtsummers 4y ago
    Ada, no need to shout its name. But even Ada 83 had a lot of safety features that made it worthwhile, it just didn't take off (for a variety of reasons including anger from developers "how dare they tell us what to use" and cost "you want how much for a compiler and we have to get a new license for a new project?!?"). Its arrays carried their size and range with them so you could safely iterate over them and safely (well, you'd get a runtime error at least versus C's "I trust you" model) access their elements. You had tasks and rendezvous since Ada 83 which could be used to protect access to data across other tasks (this was improved later with protected types in Ada 95). You could tightly control, in the language not at runtime, the memory layout of records which was useful for over-the-wire protocols. With C you couldn't guarantee a particular packing for a struct would be uniform across compilers, with Ada you could. This also helps reduce bugs because you can apply DRY properly, in C you have to implement marshaling and unmarshaling yourself, in Ada it was just a given. It's a very underrated language, mostly discounted because, it turns out, people are more into fashion and style than substance. "Eww, it uses keywords like `begin` and `procedure`" seems to be the #1 reason for rejecting it anymore, rather than any serious analysis.
• twobitshifter 4y ago
  Someone writing in C or C++ isn’t likely to find JS or Python fits their use case, but that same is true of Ruby that somehow snuck in there
• account-5 4y ago
  Is Dart memory safe?
  • AdrienLemaire 4y ago
    I was searching for this answer too... From wiki: > Memory safety is the state of being protected from various software bugs and security vulnerabilities when dealing with memory access, such as buffer overflows and dangling pointers Dart has isolates, so I thought it was memory-safe. But searching for buffer overflow or dangling pointer on dart's github repo returns results, so I'm still left wondering.
    • account-5 4y ago
      I would have thought so, considering null safety, but can't find a specific mention either in their docs or by googling. Seems like a weird thing to overlook in a modern inoffensive language.