6 ms·
That's why languages need sandboxing at runtime as well
by 7373737373 27d ago
That's why languages need sandboxing at runtime as well
- josephg 27d agoYes, or the compile time equivalents. Rust’s safety gets you most of the way there. We just need a capability model in the language, a more limited std and a way to ban untrusted 3rd party libraries from using unsafe code without explicit permission. I dream of a world where a function with the signature of add(u32, u32) -> u32 can’t burn my house down and steal my wife. Functions should only have access to their arguments. Nothing more. We need to end ambient authority.
- nh2 26d agoYou have just reinvented "Safe Haskell" from 2012. It guarantees that pure functions are pure. https://www.microsoft.com/en-us/research/publication/safe-haskell/ https://www.microsoft.com/en-us/research/publication/safe-ha... https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/safe_haskell.html https://downloads.haskell.org/ghc/latest/docs/users_guide/ex...
- josephg 26d agoOooh I didn't know that was a thing! Yes, I want this but in a fast, compiled systems language like rust.
- tome 26d agoHaskell is a fast, compiled systems language like Rust (or rather, Rust is like Haskell).
- josephg 26d agoAre you sure about that? My understanding is that Haskell programs generally run much more slowly than their C counterparts because of all of Haskell’s magic. Like lazy evaluation and memoisation and however Haskell manages memory. Rust certainly borrows from Haskell. Like all good languages. But I’m not aware of Haskell beating rust in program performance & memory usage benchmarks. SeL4 was first written in Haskell and proven correct in Haskell. Then, with a great many years of effort, ported to C and proven correct there. If Haskell were a viable systems language, I suspect the kernel would not have been converted to C.
- tome 26d agoYes, I'm sure about that. I said that it is a systems language, not that it is as fast as C! I don't mind if your terminology excludes Haskell from being a systems language, as long as it also excludes Go. They are both managed, garbage collected, fast languages. > Like lazy evaluation and memoisation Yes, that causes performance impact. If you don't want the performance impact then don't write code that uses those behaviors. Sure, that rules out large parts of the ecosystem, but I said Haskell was a systems language not that its ecosystem was generally suitable for systems programming. > however Haskell manages memory No, Haskell's memory manager is world class, with two (at least) tunable garbage collectors. > But I’m not aware of Haskell beating rust in program performance & memory usage benchmarks Nor am I! > If Haskell were a viable systems language, I suspect the kernel would not have been converted to C. I suspect they converted it to C because you can't write a kernel in a managed language with a garbage collector.