Bluefin Alternatives

bluefin reviews and mentions

• Algebraic Effects for the Rest of Us
  4 projects | news.ycombinator.com | 30 May 2026
• AI models need a virtual machine
  6 projects | news.ycombinator.com | 30 Aug 2025

  Have you seen my effect system Bluefin? It sounds like exactly what you're describing:

  https://hackage-content.haskell.org/package/bluefin-0.0.16.0...

  Happy to answer any questions about it, either here, or if you open an issue: https://github.com/tomjaguarpaw/bluefin/issues/new

• Why not object capability languages?
  5 projects | news.ycombinator.com | 11 May 2025

  Yes, I think so. In fact Haskell "effect systems" are a lot like "capability languages" in the sense that the restrict in a fine-grained way which parts of your codebase can perform which sorts of actions. My library Bluefin[1] takes this a step further and represents capabilities as value-level entities which you pass around to whoever needs the capability (and correspondingly, not to whoever doesn't need it). Bluefin calls capabilities "handles" (though I have wondered about renaming).

  In fact, this passage from the article describes very closely what it is like to use Bluefin, yet I bet the author doesn't even know of Bluefin's existence! That makes me think I am on the right lines with my design.

  > The first is that if you want the entire application to be written in an object-capability style then its main() method must be given a “god object” exposing all the ambient authorities the app begins with. You then have to write proxy objects that restrict access to this god object whilst implementing standard interfaces.

  This part is too pessimistic, however:

  > No language has such an object or such interfaces in its standard library, and in fact “god objects” are viewed as violating good object oriented design.

  As you correctly point out, cryptonector, Haskell's IO is the "god object". It allows you to do roughly anything. And indeed Bluefin's runEff[2] gives you access to the god object (which is IO wrapped up in an effect (or "capability") called IOE). The rest of the program runs by "peeling parts off" this god object so it only uses the parts that it needs.

  I have found this a very satisfactory way to program.

  [1] https://hackage.haskell.org/package/bluefin

  [2] https://hackage-content.haskell.org/package/bluefin-0.0.15.0...

• Rust Dependencies Scare Me
  23 projects | news.ycombinator.com | 9 May 2025

  Yes, there is a sense in which Haskell's "effect systems" are "capability systems". My effect system, Bluefin, models capabilities as values that you explicitly pass around. You can't do I/O unless you have the "IOE" capability, for example.

  https://hackage.haskell.org/package/bluefin

• Some Programming Language Ideas
  12 projects | news.ycombinator.com | 8 Jan 2025

  I'm surprised these are called "programming language ideas". They seem to be solvable, at least many of them, with libraries. For example, my Haskell effect system Bluefin can be seen as a capability system for Haskell. My database library Opaleye is basically a relational query language for Haskell. Maybe I'm short-sighted but I haven't seen the need for a whole new language to support any of that functionality. In fact one gets huge benefits from implementing such things in an existing language.

  * https://hackage.haskell.org/package/bluefin

  * https://hackage.haskell.org/package/opaleye

• OOP is not that bad, actually
  5 projects | news.ycombinator.com | 21 Oct 2024

  This is strange to me because I don't see FP faltering here at all. I suppose it depends on precisely what you mean by "OOP" and "FP". Below is an example implementation in my Haskell effect system Bluefin. It defines a Logger interface (that can log a message with severity) and then instantiates it with two implementations

  https://hackage.haskell.org/package/bluefin

  1. a logger that logs to stdout

  2. a logger that logs to a file

  The file logger also brackets the opening of the file so that if abnormal termination is encountered then the file handle is guaranteed to be cleaned up. This is similar to RAII.

  I really like this solution! It's just programming against an interface, and then instantiating the interface in different ways. I think an solution using inheritance would be worse, because it would use a special language concept (inheritance) rather than a standard one (function definition).

  Perhaps this is "OOP" and not "FP"? That's fine by me! But in that case I conclude Haskell is an excellent OOP language. (I already conclude that it's an excellent imperative language.)

      {-# LANGUAGE GHC2021 #-}

• Functional programming languages should be better at mutation than they are
  4 projects | news.ycombinator.com | 30 Jul 2024

  I agree with Alexis. Bluefin approaches this by not actually having a nesting order. The effects that can be performed as specified as function arguments, so they can be freely reordered without changing behaviour. effectful, which was one of the inspirations for Bluefin, is similar but uses constraints instead of function arguments, which are even more free to reorder.

  > I'll be sure to check it out

  Great! If you have any questions or thoughts then feel free to file an issue on the repo (https://github.com/tomjaguarpaw/bluefin/issues/new).

• A note from our sponsor - SaaSHub
  www.saashub.com | 7 Jun 2026

  SaaSHub helps you find the best software and product alternatives Learn more →