6 ms·

Safe Haskell is just a worst version of Rust's unsafe. What it actually does is equivalent to Rust's #![forbid(unsafe_code)] which immediately lead to a questio

Safe Haskell is just a worst version of Rust's unsafe. What it actually does is equivalent to Rust's #![forbid(unsafe_code)] which immediately lead to a question: so Haskell has unsafe, just like Rust? And of course it does. Any practical systems language has unsafe in one form or another, not only for FFI but also for performance, Rust is just honest about it. There's two reasons Safe Haskell is substantially worse than what Rust does. Safe Haskell works by annotating code that is safe, but that's entirely backwards. We need to annotate unsafe code, and explain in plain English exactly why it is okay in that particular instance (of course it would be better to explain in code, like, give a formal proof that is checked by the compiler, but then it isn't unsafe anymore!). Safe Haskell answer for that is to annotate good unsafe code as trustworthy, but that doesn't work because it doesn't goes in detail on why the code is trustworthy (to do so you really need to go into the details, you can't handwave it). It's the // SAFETY comments that are at the heart of Rust's unsafe, carefully explaining safety invariants that must be kept (specially important if we are modifying code), not unsafe { } blocks. The second reason is much simpler. It's optional, and approximately nobody uses Safe Haskell or cares about it. If people used it we would have something to improve upon. So Rust achievement here is mostly sociological, it's a community of programmers that care about safety. Which is good given that a Rust program typically have much more unsafe code than a Haskell program. Here's a thread about Safe Haskell issues https://www.reddit.com/r/haskell/comments/zwkqke/deprecating_safe_haskell_or_heavily_investing_in/ https://www.reddit.com/r/haskell/comments/zwkqke/deprecating... that links to https://discourse.haskell.org/t/deprecating-safe-haskell-or-heavily-investing-in-it/5489 https://discourse.haskell.org/t/deprecating-safe-haskell-or-... And an older thread https://www.reddit.com/r/haskell/comments/msa3oq/safe_haskell/ https://www.reddit.com/r/haskell/comments/msa3oq/safe_haskel...

josephg 16d ago
The thing I really want is a language or environment with no implicit access rights. So, if I call add(a, b) then the add function doesn’t have implicit access to the filesystem, network or global variables in other parts of the program. If you want to give a function access to a subdirectory, you should pass a handle to that subdirectory as an argument and use openat() or equivalent. This would guarantee - at a language level - that leftpad or log4j can’t root my computer. Safe rust doesn’t give this guarantee. Safe code can still make arbitrary syscalls. Safe rust can convert a path string to a File. Or open arbitrary network sockets. Rust also doesn't have a way to import a crate but forbid the use of any unsafe blocks. I want to be able to use 3rd party code from cargo without getting hacked. Right now rust does not keep me safe from these supply chain attacks. I don’t know enough about safe Haskell to know how close it tacks to this. But that’s what I want.
- tialaramex 14d ago
  > The thing I really want is a language or environment with no implicit access rights I don't think you'll find anything like that from a General Purpose Language, so you probably want something like WUFFS [Wrangling Untrusted File Formats Safely]. https://github.com/google/wuffs https://github.com/google/wuffs
  - josephg 13d ago
    [dead]
- tome 16d ago
  I think nextaccountic is not technically fully correct, but he/she is at least correct in the most important part: Safe Haskell is not really practical. But if you don't want an ironclad guarantee and instead you're content with making wrong code obviously wrong even if it's not formally verified, then I recommend Haskell with a capability system (what the Haskell world calls an "effect system"). As far is I'm concerned there are two practical choices in 2026, Bluefin (mine) and effectful (one of Bluefin's inspirations) * https://hackage.haskell.org/package/bluefin https://hackage.haskell.org/package/bluefin * https://hackage.haskell.org/package/effectful https://hackage.haskell.org/package/effectful
  - josephg 16d ago
    How does this compare to Spritely Goblins? I had a good chat with Christine about it at a conference. She said "Ah, you've been infected with the capabilities virus too. My condolences." https://spritely.institute/goblins/ https://spritely.institute/goblins/
    - tome 16d ago
      Interesting, I have not heard of Spritely Goblins! But neither Bluefin nor effectful could be described as distributed capability systems/effect systems, so I don't think they're comparable. On infection, I think it's a bit like being infected by mitochondria :)

josephg 16d ago

The thing I really want is a language or environment with no implicit access rights. So, if I call add(a, b) then the add function doesn’t have implicit access to the filesystem, network or global variables in other parts of the program. If you want to give a function access to a subdirectory, you should pass a handle to that subdirectory as an argument and use openat() or equivalent. This would guarantee - at a language level - that leftpad or log4j can’t root my computer. Safe rust doesn’t give this guarantee. Safe code can still make arbitrary syscalls. Safe rust can convert a path string to a File. Or open arbitrary network sockets. Rust also doesn't have a way to import a crate but forbid the use of any unsafe blocks. I want to be able to use 3rd party code from cargo without getting hacked. Right now rust does not keep me safe from these supply chain attacks. I don’t know enough about safe Haskell to know how close it tacks to this. But that’s what I want.

tialaramex 14d ago
> The thing I really want is a language or environment with no implicit access rights I don't think you'll find anything like that from a General Purpose Language, so you probably want something like WUFFS [Wrangling Untrusted File Formats Safely]. https://github.com/google/wuffs https://github.com/google/wuffs
- josephg 13d ago
  [dead]
tome 16d ago
I think nextaccountic is not technically fully correct, but he/she is at least correct in the most important part: Safe Haskell is not really practical. But if you don't want an ironclad guarantee and instead you're content with making wrong code obviously wrong even if it's not formally verified, then I recommend Haskell with a capability system (what the Haskell world calls an "effect system"). As far is I'm concerned there are two practical choices in 2026, Bluefin (mine) and effectful (one of Bluefin's inspirations) * https://hackage.haskell.org/package/bluefin https://hackage.haskell.org/package/bluefin * https://hackage.haskell.org/package/effectful https://hackage.haskell.org/package/effectful
- josephg 16d ago
  How does this compare to Spritely Goblins? I had a good chat with Christine about it at a conference. She said "Ah, you've been infected with the capabilities virus too. My condolences." https://spritely.institute/goblins/ https://spritely.institute/goblins/
  - tome 16d ago
    Interesting, I have not heard of Spritely Goblins! But neither Bluefin nor effectful could be described as distributed capability systems/effect systems, so I don't think they're comparable. On infection, I think it's a bit like being infected by mitochondria :)