Live data from Hacker News

Flix – A powerful effect-oriented programming language

flix.dev

101–110 of 197 posts

Re: Flix – A powerful effect-oriented programming language

#101

Earlier quoted context omitted.

Indeed. I even like the syntax.

As a non-functional-programming, c-language-familiar person, the syntax look fabulous. It seems like the first functional language I've seen that makes simple things look simple and clear.

It's kind of a bummer that "skins/themes" never caught on for programming languages. You see it once in awhile, I think some compiler people at one of the FAANGs did an OCaml skin/theme/alternative syntax (reason? something). And there's stuff like Elixir that's kind of a new language but also an interface to an existing world (very cool, Valim is a brilliant guy).

But you could do it for almost anything. I would love the ability to hit a key chord in `emacs` and see things in an Algol-family presentation, or an ML family, or a Lisp.

Seems like the kind of thing that might catch on someday. Certainly the math notation in things like Haskell and TLA were a bit of a barrier to entry at one time. Very solvable problem if people care a lot.

Re: Flix – A powerful effect-oriented programming language

#102
Minor nit: the semicolons! Especially in the yield examples, since there's no "return" on the last line, the disparity looks weird.

That said, I like how the syntax isn't overly functional, and not too different from what we see in mainstream languages. I'd be fine with either braces or indentation, but the semicolons have to go!

Re: Flix – A powerful effect-oriented programming language

#103
post #97

Any code agents work well with this or do we have to start thinking with our own brain again? Seriously though, looks like a cool language and makes me sad that LLMs will probably inhibit the adoption of new languages, and wonder what we can do about it.

I have the opposite gut feeling about LLM's; I think they're going to break down the barriers to adopting new programming languages, since they'll lower the cost of porting code dramatically.

The code in a language's standard library is probably enough to train an LLM on the new syntax, and even if it isn't, agents now observe the compiler output and can in principle learn from it. Porting code from one language to another doesn't require deep creativity and is, barring API aesthetics, a perfectly well defined task. It will be one of the first programming tasks to be perfectly automated by LLM's.

We are going to have to use our brains again to start thinking about why we're doing any of the stuff we're doing, and what effects it will have on the world.

Re: Flix – A powerful effect-oriented programming language

#104

I am deeply impressed by the depth and breadth of this language. Algebraic data types, logic programming, mutability, all there from the get go. Another aspect that I love from their comparison table is that a single executable is both the package manager, LSP and the compiler. As I understand, the language server for Haskell has/had to do a lot of dances and re implement things from ghc as a dance between the partic…

F# doesn’t have type classes (yet?) so programming with monads can be quite limited.

It would be interesting if F# skipped Haskell style monads and jumped straight to algebraic effects. They seem like a better fit for F# philosophy in any case.

Re: Flix – A powerful effect-oriented programming language

#105

I am deeply impressed by the depth and breadth of this language. Algebraic data types, logic programming, mutability, all there from the get go. Another aspect that I love from their comparison table is that a single executable is both the package manager, LSP and the compiler. As I understand, the language server for Haskell has/had to do a lot of dances and re implement things from ghc as a dance between the partic…

I agree, somewhat, but "StringBuilder"... Hmm... Leaning towards Java a lot in this aspect. Not sure I like this aspect of it. The rest does seem look at a quick glance.

Re: Flix – A powerful effect-oriented programming language

#106
post #35

Anyone have a good primer on what effect-oriented programming looks like and how it’s used? Feel free to shill your own blog!

I wrote about them here. https://crowdhailer.me/2025-02-14/algebraic-effects-are-a-fu... as I got a reasonable handle on implementing them in EYG

All the examples are editable, though not as text.

Re: Flix – A powerful effect-oriented programming language

#107
post #69

Very similar to the koka language. I hope these effect systems become mainstream.

I'm pretty confident they will become a common feature in functional languages. Unison, Roc, EYG also have some version.

Then we just need to wait for the functional languages to become mainstream.

Re: Flix – A powerful effect-oriented programming language

#108

I am deeply impressed by the depth and breadth of this language. Algebraic data types, logic programming, mutability, all there from the get go. Another aspect that I love from their comparison table is that a single executable is both the package manager, LSP and the compiler. As I understand, the language server for Haskell has/had to do a lot of dances and re implement things from ghc as a dance between the partic…

I agree, somewhat, but "StringBuilder"... Hmm... Leaning towards Java a lot in this aspect. Not sure I like this aspect of it. The rest does seem look at a quick glance.

The StringBuilder example is just that-- an example that many software developers should be familiar with. The deeper idea is that in Flix one can write a pure function that internally use mutation and imperative programming.

Re: Flix – A powerful effect-oriented programming language

#109

Earlier quoted context omitted.

Indeed. I even like the syntax.

Really? The mix of :/indentation-significant functions and braces for everything else seems extremely questionable.

There is no significant indentation. What leads you to be believe that?

Re: Flix – A powerful effect-oriented programming language

#110

Earlier quoted context omitted.

> The upshot is that traits are a compile-time construct that is fully eliminated through monomorphization. So, apparently, I can't re-implement distage for Flix. I don't mind a little bit of overhead in exchange for a massive productivity boost. I don't even need full nominal inheritance, just literally one level of interface inheritance with dynamic dispatching :( > their real (or perceived) (ab)use in other progra…

The reality is that careless programmers will do bad things with any tool they happen to pick up. Using that as an excuse to reduce the power of a tool is poor form. Another way of putting it is to point out that removing goto from a language isn't going to reduce the occurrence of spaghetti code. The average skill and care of the developers who happen to be using that language is what does that.

Not sure I agree. A simple example: If your language has null as a subtype of every type then you will have null ptr exceptions everywhere. If your language does not have a null value then you won't. The situation is not as clear cut as you suggest.

Yes, you can write spaghetti code in any language. But a good language design can help (a) reduce errors and (b) nudge the developer towards writing better code.

Post reply on HN