4 ms·

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

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.

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.