Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flix – A powerful effect-oriented programming language

flix.dev

Post reply on HN
Print view View original

21–30 of 197 posts

Re: Flix – A powerful effect-oriented programming language

#21

Post by tome »

hocuspocus wrote: post #13
tossandthrow wrote: post #12

Earlier quoted context omitted.

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.

Effect systems in FP languages give you precisely that: referential transparency.

Funny you mention that because that's exactly how my talk at ZuriHac 2025 started, video published just yesterday:

https://www.youtube.com/watch?v=RsTuy1jXQ6Y

Re: Flix – A powerful effect-oriented programming language

#22

Post by noelwelsh »

tossandthrow wrote: post #12
noelwelsh wrote: post #8

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.

You gotta ask the question: why does FP care about eliminating side effects? There are two possible answers:

1. It's just something weird that FP people like to do; or

2. It's in service of a larger goal, the ability to reason about programs.

If you take the reasonable answer---number 2---then the conclusion is that effects are not a problem so long as you can still reason about programs containing them. Linear / affine types (like Rust's borrow checker) and effect systems are different ways to accommodate effects into a language and still retain some ability to reason about programs.

No practical program can be written without effects, so they must be in a language somewhere.

More here: https://noelwelsh.com/posts/what-and-why-fp/

Re: Flix – A powerful effect-oriented programming language

#24

Post by foxygen »

withinboredom wrote: post #17
jorkadeen wrote: post #7

Earlier quoted context omitted.

The JVM is a state-of-the-art virtual machine with multiple open source implementations, a large ecosystem, and a fast JIT compiler that runs on most platforms. It is hard to find another VM with the same feature set and robust tooling.

Yes… with a million weird environment variables that can affect your runtime.

So don't change them? Parent comment still applies to stock JVM.

Re: Flix – A powerful effect-oriented programming language

#25

Post by Joker_vD »

withinboredom wrote: post #17
jorkadeen wrote: post #7

Earlier quoted context omitted.

The JVM is a state-of-the-art virtual machine with multiple open source implementations, a large ecosystem, and a fast JIT compiler that runs on most platforms. It is hard to find another VM with the same feature set and robust tooling.

Yes… with a million weird environment variables that can affect your runtime.

Which is amazing, you can fine tune the performance of the runtime to your heart's content. Or you can just leave them as-is, the default behaviour is quite reasonable too.

Re: Flix – A powerful effect-oriented programming language

#26

Post by pshirshov »

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 form of Scala traits. Typeclasses are not a replacement for interfaces, an extremely important abstraction is missing from the language (due to H-M typer perhaps), so a lot of useful things are just impossible there (or would look ugly).

Re: Flix – A powerful effect-oriented programming language

#28

Post by tikhonj »

phkahler wrote: post #6

>> Flix is a principled effect-oriented functional, imperative, and logic programming language... >> Why Effects? Effect systems represent the next major evolution in statically typed programming languages. By explicitly modeling side effects, effect-oriented programming enforces modularity and helps program reasoning. Since when do side effects and functional programming go together?

Functional programming à la Haskell has always been about making effects controllable, explicit first-class citizens of the language. A language entirely without effects would only be useful for calculation.

The talk about "purity" and "removing side effects" has always been about shock value—sometimes as an intentional marketing technique, but most often because it's just so much easier to explain. "It's just like 'normal' programming but you can't mutate variables" is pithy and memorable; "it's a language where effects are explicitly added on top of the core and are managed separately" isn't.

Re: Flix – A powerful effect-oriented programming language

#29

Post by tikhonj »

tossandthrow wrote: post #12
noelwelsh wrote: post #8

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.

If you start with lambda calculus you don't have effects in the first place, so there's nothing to eliminate. Lambda calculus and friends are perfectly reasonable languages for computation in the sense of calculation.

A better way to think about general-purpose functional programming is that it's a way to add effects to a calculation-oriented foundation. The challenge is to keep the expressiveness, flexibility and useful properties of lambda calculus while extending it to writing interactive, optimizable real-world programs.

Post reply on HN