(edit) c'n'p from their site:
Why Flix?
Flix aims to offer a unique combination of features that no other programming language offers, including: algebraic data types and pattern matching (like Haskell, OCaml), extensible records (like Elm), type classes (like Haskell, Rust), higher-kinded types (like Haskell), local type inference (like Haskell, OCaml), channel and process-based concurrency (like Go), a polymorphic effect system (unique feature), first-class Datalog constraints (unique feature), and compilation to JVM bytecode (like Scala).
There is also a former thread on HN: https://news.ycombinator.com/item?id=25513397
[0] https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax
But this list actually makes me excited!
(edit) you can import Java, Kotlin and Scala in it too, those are automatically Impure. Would enable purely functional architecture [1] and falling into the "Pit of success" [2].
[0] https://flix.dev/research/ [1] https://blog.ploeh.dk/2016/03/18/functional-architecture-is-... [2] https://www.youtube.com/watch?v=US8QG9I1XW0
[0]: https://github.com/nicuveo/ghc-proposals/blob/master/proposa...
They use "abilities" as a dual to effects. That's imho the crucial part. Most of the other effect systems only implement half the thing.
But I would change two parts: First of all the co-effects should be proper "capabilities" in the sense of "capability security". The other thing would be modelling the co-effects as co-data. They already use some (ad hoc?) notion of "Interfaces". Those look like co-data definitions (resembling OOP Interfaces). I also thing co-data with co-pattern matching could solve some of the problems mentioned at the end of the paper. Inspiration could be taken form: https://www.cs.uoregon.edu/Reports/DRP-201905-Sullivan.pdf
"Do, be, do, be, do" (those who read it will understand)
This paper really opened my eyes for what's possible.
That being said, Rust has a bit of a harder time due to the focus on performance and optimally zero-cost abstraction, whereas other languages are more lenient and focus rather on expressiveness and composability / code reuse.
I can very easily have a fallible, asynchronous, multi-value, stateful, database connected computation that returns a Bool and use it in let’s say ‘filterM’.
Most transformers are already written for me.
Edit: switching between no effect and some effect is the tricky part though.
(Just to add- there's a really wide range of ergonomics that you can support and it's hard to get everything right. And performance is super tricky!)
Maybe also ATS, but I'm unsure if it qualifies
[1]: https://www.janestreet.com/tech-talks/effective-programming/
Last I read, they really want to nail down the entire multi-threaded environment to the last detail first (which mostly means make sure no parallel bugs are introduced + single-threaded code won't become slower; both pretty huge goals).
* Pony - capabilities based language inspired by `E`. Effects are like Rust's (provided by the language, not extensible by end users): https://www.ponylang.io/
* Koka - effects are first class and higher order. `filter` is a higher order function that is "effectfully parameterized" as well as "parameterized over its types". Effects can be discharged at any level of the program and the effects "stack" is manipulable (in what appears to be a principled way) https://koka-lang.github.io/koka/doc/index.html
* Multi-core OCaml is also building parallelism on a version of effects that looks quite a lot like Koka (though I'm not familiar enough with it to say how close they are in practice).
What other ones am I missing?