Live data from Hacker News

Flix – A powerful effect-oriented programming language

flix.dev

41–50 of 197 posts

Re: Flix – A powerful effect-oriented programming language

#41

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…

Indeed. I even like the syntax.

Re: Flix – A powerful effect-oriented programming language

#42

Earlier quoted context omitted.

FP isn't really about eliminating side effects. Controlled effects are fine. That's what an effect system does. Avoiding side effects is really just a side effect (pun intended) of older programming language technology that didn't provide any other way to control effects.

Arguably FP really is about eliminating side effects. The research has sprung out of lambda calculus where a computation is defined in terms of functions (remember: Functional programming). Side effects can only be realized by exposing them in the runtime / std-lib etc. How one does that is a value judgement, but if a term is not idempotent, then you arguably does not have a functional programming language anymore.

Lisp always had side effects and mutability, and it's the canonical FP language, directly inspired by lambda calculus. To be fair, before Haskellers figured out monads, nobody even knew of any way to make a FP language that's both pure and useful.

Re: Flix – A powerful effect-oriented programming language

#43
post #31

I looked and Flix a while ago and found it really interesting - so much so that I wrote an article "Flix for Java Programmers" about it. Might actually be a bit outdated by now.. need to look at Flix's recent development again. But if you're interested: https://www.reactivesystems.eu/2022/06/24/flix-for-java-prog...

Cool blog post! With your permission, I would be happy to add it here: https://doc.flix.dev/blog-posts.html

The language has improved a lot in the years since the post. In particular, the effect system has been significantly extended, Java interoperability is much improved, and some syntax have been updated.

Re: Flix – A powerful effect-oriented programming language

#44

Awesome, it even supports HKTs. Can't find any mentions of typeclasses though, are they supported? Give me typeclasses and macros comparable with Scala ones and I would be happy to port my libraries (distage, izumi-reflect, BIO) to Flix and consider moving to it from Scala :3 UPD: ah, alright, they call typeclasses traits. What about macros? UPD2: ergh, they don't support nominal inheritance even in the most harmless…

Flix supports type classes (called "traits") with higher-kinded types (HKTs) and with associated types and associated effects. A Flix trait can provide a default implementation of a function, but specific trait instances can override that implementation. However, Flix has no inheritance. The upshot is that traits are a compile-time construct that is fully eliminated through monomorphization. Consequently, traits incu…

Sorry to hijack, but since you are involved, can you explain why tail call optimization would incur a run time perf penalty, as the docs mention? I would expect tail call optimization to be a job for the compiler, not for the runtime.

Re: Flix – A powerful effect-oriented programming language

#45
post #38
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!

It looks like "effect" as in impure functions in a functional language? I.e. a new way of dealing with effects (global/hidden state mutations) in a language that makes the pure-impure distinction. I'm not entirely sure. I thought it was going to be something like contracts or dependent types or something.

No. It is essentially resumable exceptions. You throw an exception saying “I need a MyAlgebraicType” and the effect handler catches the exception, generates the value, and returns execution to the place the exception was called from.

Re: Flix – A powerful effect-oriented programming language

#46

Earlier quoted context omitted.

Flix supports type classes (called "traits") with higher-kinded types (HKTs) and with associated types and associated effects. A Flix trait can provide a default implementation of a function, but specific trait instances can override that implementation. However, Flix has no inheritance. The upshot is that traits are a compile-time construct that is fully eliminated through monomorphization. Consequently, traits incu…

Sorry to hijack, but since you are involved, can you explain why tail call optimization would incur a run time perf penalty, as the docs mention? I would expect tail call optimization to be a job for the compiler, not for the runtime.

TCO (tail call optimization) is often confused with TCE (tail call elimination), the latter is a runtime guarantee whereas the former is a compiler's best effort attempt to statically optimize tail calls.

Re: Flix – A powerful effect-oriented programming language

#47
post #38

Earlier quoted context omitted.

It looks like "effect" as in impure functions in a functional language? I.e. a new way of dealing with effects (global/hidden state mutations) in a language that makes the pure-impure distinction. I'm not entirely sure. I thought it was going to be something like contracts or dependent types or something.

No. It is essentially resumable exceptions. You throw an exception saying “I need a MyAlgebraicType” and the effect handler catches the exception, generates the value, and returns execution to the place the exception was called from.

But entirely definable in user code, so an effect is essentially a set of possibly impure operations you can perform (like I/O or exception throwing), and a function that exhibits that effect has access to those operations. Of course the call sites then also exhibit that effect, unless they provide implementations of the effect operations.

Re: Flix – A powerful effect-oriented programming language

#48

Earlier quoted context omitted.

Flix supports type classes (called "traits") with higher-kinded types (HKTs) and with associated types and associated effects. A Flix trait can provide a default implementation of a function, but specific trait instances can override that implementation. However, Flix has no inheritance. The upshot is that traits are a compile-time construct that is fully eliminated through monomorphization. Consequently, traits incu…

Sorry to hijack, but since you are involved, can you explain why tail call optimization would incur a run time perf penalty, as the docs mention? I would expect tail call optimization to be a job for the compiler, not for the runtime.

We have to emulate tail calls using trampolines. This means that in some cases we have to represent stack frames as objects on the heap. Fortunately, in the common case where a recursive function simply calls itself in tail position, we can rewrite the call to a bytecode level loop and there is no overhead.

Re: Flix – A powerful effect-oriented programming language

#49

Earlier quoted context omitted.

Sorry to hijack, but since you are involved, can you explain why tail call optimization would incur a run time perf penalty, as the docs mention? I would expect tail call optimization to be a job for the compiler, not for the runtime.

TCO (tail call optimization) is often confused with TCE (tail call elimination), the latter is a runtime guarantee whereas the former is a compiler's best effort attempt to statically optimize tail calls.

Thanks! So you are implying that `TCO :: Maybe TCE`?

I am trying to think of a situation where a functional language compiler does not have enough information at compile time, especially when effects are witnessed by types.

Re: Flix – A powerful effect-oriented programming language

#50

Awesome, it even supports HKTs. Can't find any mentions of typeclasses though, are they supported? Give me typeclasses and macros comparable with Scala ones and I would be happy to port my libraries (distage, izumi-reflect, BIO) to Flix and consider moving to it from Scala :3 UPD: ah, alright, they call typeclasses traits. What about macros? UPD2: ergh, they don't support nominal inheritance even in the most harmless…

Flix supports type classes (called "traits") with higher-kinded types (HKTs) and with associated types and associated effects. A Flix trait can provide a default implementation of a function, but specific trait instances can override that implementation. However, Flix has no inheritance. The upshot is that traits are a compile-time construct that is fully eliminated through monomorphization. Consequently, traits incu…

> 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 programming languages.

Without macros I can't re-implement things like logstage (effortless structured logging extracting context from AST) and izumi-reflect (compile-time refleciton with tiny runtime scala typer simulator).

Post reply on HN