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 particular ghc version and your cabal file. And maybe stack too, because I don't know which package manager is the blessed one these days. Not to shit on Haskell -- it is actually a very fine language.
However, the best feature is a bit buried and I wonder why.
How ergonomic is the integration with the rest of the JVM, from the likes of Java? AFAIK, types are erased by JVM compilers... With the concept of `regions` they have at least first class support for imperative interaction. Note: With the JVM you get billions worth of code from a high quality professional standard library, so that is a huge plus. That is why the JVM and .net core are IMHO the most sane choices for 90+% of projects. I think the only comparable language would be F#. I would love to see a document about Flix limitations in the JVM interoperability story.
__EDIT__
- There is a bit of info here. Basically all values from Flix/Java have to be boxed/unboxed. https://doc.flix.dev/interoperability.html
- Records are first-class citizens.
oh my i just know you're going to love unison
Not in all the cases (it keeps type parameters for anonymous classes) and there are various workarounds.
Also, essentially, it's not a problem at all for a compiler, you are free to render applied type constructors as regular classes with mangled names.
Caveat: Flix sometimes has to box values on the boundary between Flix and Java code -- e.g. when calling a Java library methods that requires a java.lang.Object due to erasure in Java.
The goal of Flix -- and typically of any high-level programming language -- is to provide powerful abstractions and constructs that make programming simple, concise, and (often) less error-prone. Here Datalog fits perfectly.
Now that said -- looking through the Flix documentation -- I think we need to do a better job at selling the use case for Datalog. Partly by adding arguments such as the above and partly by adding better examples.
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.
For your second point, I don't know if they could achieve that without type level programming. This is the Box of Pandora the designer of F# tried [0] not to open.
____
0. https://github.com/fsharp/fslang-suggestions/issues/243#issu...
>> 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?
(I am one of the developers of Flix)
It's usage is almost equivalent to using IORefs, except we can escape ST using runST to get back a pure value not in ST, which we cannot do for IO because there is no `IO a -> a`.
There's no requirement to contain ST to a single function - we can split mutation over several functions, provided each one involved returns some `ST a` and their usage is combined with >>=.
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.
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.
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.
For example for a type system,
let a: Int // this says 'a' has the type Int
a = 5 // compiler allows, as both 'a' and 5 are of Int.
a = 5.1 // disallowed, as 'a' and 5.1 are of different types.
let a: Int
let b: Int!Div0 // 'b' is of type Int and the Div0 effect.
let c: Int
...
a = 1 / c // disallowed, as '/' causes the Div0 effect which 'a' not supported
b = 1 / c // allowed, as both '/' and 'b' support the Div0 effect.
compute1(..) on effect(Div0) {
// handle the Div0 effect.
}The book uses Scala & ZIO but intends to be more about the concepts of Effects than the actual implementation. I'd love to do a Flix version of the book at some point. But first we are working on the TypeScript Effect version.
All the examples are editable, though not as text.
I thought it was going to be something like contracts or dependent types or something.
But if you're interested: https://www.reactivesystems.eu/2022/06/24/flix-for-java-prog...
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.
C++, C#/Typescript, Dart, etc all have strong roots in that one small area in Denmark.
In general, I am curious what makes some of these places very special (Delft, INRIA, etc)?
They aren't your 'typical' Ivy League/Oxbridge univ+techhubs.
Is it the water? Or something else? :)
In general, programming language theory is pretty strong in Denmark, with lots of other contributions.
For example, the standard graduate textbook in static program analysis (Nielson & Nielson) is also Danish. Mads Tofte made lots of contributions to Standard ML, etc.
> They aren't your 'typical' Ivy League/Oxbridge univ+techhubs.
Aarhus is an outstanding university. There are a couple of dozen universities in Europe that lack the prestige of Oxbridge but offer high quality education and perform excellent research.
I also think there's a noticeable bias toward the US in how programming language research is perceived globally. Institutions like Aarhus often don't invest heavily in marketing or self-promotion, they just focus on doing solid work. It's not necessarily better or worse, but it does make it harder for their contributions to break through the layers of global attention.
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).
Flix does not yet have macros-- and we are afraid to add them due to their real (or perceived) (ab)use in other programming languages.
We are actively looking for library authors and if you are interested, you are more than welcome to stop by our Gitter channel.
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).
I think the abuse is not that much of a problem. It's rather that it makes it much much harder to change the language later on because it will break macros (like it did between Scala 2 and 3, causing many people to be stuck on Scala 2 due to libraries using macros heavily).
If I might add a suggestion: add type providers to the language (like in F#). It solves a lot of the problems that macros are often used for, such as generating code from SQL DDLs, API specs, etc. (or vice versa).
[1] https://doc.flix.dev/chains-and-vectors.html#vectors
[2] https://flix.dev/principles/ See also "Bugs are not recoverable errors"
"Bugs are not recoverable errors" is such a fuzzy idea. On the one hand, indexing an array with an out-of-bounds integer could just be considered a program bug. On the other, the point of making the indexing operation return an optional value is to force the program to handle that scenario, preventing it from being a bug. One of the examples they give of a "recoverable error" is illegal user input, but in the case of "the user enters an index and it might be invalid", the language does nothing to keep the recoverable error from turning into an unrecoverable program bug.
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.
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.
// Computes the delivery date for each component.
let r = query p select (c, d) from ReadyDate(c; d)
query p from ReadyDate(c; d) select (c, d)
Path(x, z) :- Path(x, y), Edge(y, z).
query p select (x, z) from Path(x, y), Edge(y, z).
A. Keep the logic rules and `query` construct consistent (i.e. read from right-to-left).
B. Reverse the logic rules and query construct-- thus breaking with decades of tradition established by Datalog and Prolog.
C. Keep the logic rules from right-to-left, but reverse the order of `query` making it from left-to-right.
We decided on (A), but maybe we should revisit at some point.
1. I think way more people coming to your language will be familiar with SQL and it's problems than with logic programming and Horn clauses.
2. I think many people are now familiar with functional pipelines, where filters and transforms can be applied in stages, thanks to the rise of functional programming in things like LINQ and Java's Stream API. This sort of pipelining maps naturally to queries, as LINQ has shown, and even to logic programming, as µKanren has shown.
3. People don't type programs right-to-left but left-to-right. To the extent that right-to-left expressions interfere with assisting the human that's typing in various ways (like autocomplete), I would personally defer to helping the human as much as possible over historical precedent.
4. Keeping the logic fragment separate from the query fragment (option C) seems viable if you really, really want to maintain that historical precedent for some reason.
My two cents. Kudos on the neat language!
Realistically, one could argue it's not the right choice overall, but still, it's an application which would push the boundaries of what those languages have been perceived to have the greatness weakness in. An application which is mostly about handing mutable state with high performance.
Isn't Rust ML/functional inspired? The original compiler was in Ocaml, if I'm not mistaken.
Isn't Rust at least somewhat close to being usable for game engines? https://arewegameyet.rs/
While rust has traits, borrowing etc, it doesn't have a lot of things with regard to types and optimization. Things like:
- A lack of GADTs, or a stronger version, dependent types, or similar type system which would allow one to encode natural relationships, recursive ones, invariants etc.
- Tail call optimization guarantees, to allow for mutual recursion and optimization since game engines are just huge state machines, and it would allow to pass functions around which could call each other via mutual recursion, while allowing it to be optimized as well.
- Efficient structural sharing of immutable state, which would be memory layout and cache friendly
- Built in profiling from the getgo which the language developers would use and refine, so you could get information about how the program behaves over time and space.
enum Shape {
case Circle(Int32),
case Square(Int32),
case Rectangle(Int32, Int32)
}
def area(s: Shape): Int32 = match s {
case Circle(r) => 3 * (r * r)
case Square(w) => w * w
case Rectangle(h, w) => h * w
}
def area(s: Shape.Circle(r)) = { 3 * (r * r) }
def area(s: Share.Square(w)) = { w * w }
def area(s: Shape.Rectangle(h, w)) = { h * w }
area(Shape.Rectangle(2, 4))
I have to admit I don't see the distinction here in terms of DRYness--they are basically equivalent--or why the latter would somehow lead to mismatching the types--presumably if Flix has a typechecker this would be a non-issue.
I use Elixir now at work and I have used Haskell and PureScript personally and professionally, which both support analogs of both the case syntax and function-level pattern matching, and in my experience the case syntax is often the better choice even given the option to pattern match at the function level. Not that I'd complain about having both options in Flix, which would still be cool, but I don't think it's as big of a benefit as it may seem, especially when type checking is involved.
enum Shape {
case Circle(Int32),
def area(s: Shape): In32 = match s {
I think that is multi-methods
that being said, bearing in mind that i’m not a Java/JVM developer and only rarely have to use it, for the few nontrivial projects i have shipped with it the build system was by far the most challenging and frustrating. it’s so complex and has such a large surface area.
no hate at all, and the trade offs are completely reasonable, but i am hoping during my career we’ll start seeing either a massive simplification of JVM builds or a lot of innovation that would make native compilers easier to build.
(as a side note, it is nice to have langs like this for when JVM is the only option)
you can build basic java with "javac myfile.java". done.
each jvm language has its own build tools and some build tools cover jvm languages in between others.
the main pain points for me are dependencies, packaging, and configuration. best i can tell, those pains are shared between anything that targets JVM, especially those that want to have good interop.
It's a very fun time
Then we just need to wait for the functional languages to become mainstream.
This is not just aspirational. It is an iron-clad guarantee; it is what is formally called "effect safety" and it has been proven for calculi that model the Flix type and effect system.
To sum up: In Flix:
- If a function is pure then it cannot perform side-effects.
- If a function has the Console effect then it can only perform operations defined on Console.
- If a function has the Console and Http effect then it can only perform operations defined on Console and Http.
and so on.
Looking at their code however, I'm realizing one thing Elixir got "right", in my view, is the order of arguments in function calls.
For example, in Elixir to retrieve the value associated with a key in a map, you would write Map.get(map, key) or Map.get(map, key, default).
This feels so natural, particularly when you chain the operations using the pipe operator (|>):
map
|> Map.put(key, value)
|> Map.get(key)
def main(): Unit \ IO =
Map.empty() |>
Map.insert("Hello", "World") |>
Map.get("Hello") |>
println
Subject First:
Map.put(map, key, value)
Map.get(map, key)
Map.get(map, key, default)
Map.del(map, key)
Map.put(key, value, map)
Map.get(key, map)
Map.get(key, default, map)
Map.del(key, map)---
# Did You Know?
## Language
Did you know that:
- Flix offers a unique combination of features, including: algebraic data types and pattern matching, extensible records, type classes, higher-kinded types, polymorphic effects, and first-class Datalog constraints.
- Flix has no global state. Any state must be passed around explicitly.
- Flix is one language. There are no pragmas or compiler flags to enable or disable features.
- Flix supports type parameter elision. That is, polymorphic functions can be written without explicitly introducing their type parameters. For example, `def map(f: a -> b, l: List[a]): List[b]`.
- the Flix type and effect system can enforce that a function argument is pure.
- Flix supports effect polymorphism. For example, the `List.map` function is effect polymorphic: its purity depends on the purity of its function argument.
- in Flix every declaration is private by default.
- In Flix no execution happens before `main`. There is no global state nor any static field initializers.
- Flix supports full tail call elimination, i.e. tail calls do not grow the stack. Flix -- being on the JVM -- emulates tail calls until Project Loom arrives.
- Flix supports extensible records with row polymorphism.
- Flix supports string interpolation by default, e.g. "Hello ${name}". String interpolation uses the `ToString` type class.
- Flix supports the "pipeline" operator `|>` and the Flix standard library is designed around it.
- In Flix type variables are lowercase and types are uppercase.
- In Flix local variables and functions are lowercase whereas enum constructors are uppercase.
- Flix supports set and map literals `Set#{1, 2, 3}` and `Map#{1 => 2, 3 => 4}`.
- Flix supports monadic do-notation with the `let*` construct.
- Flix supports "program holes" written as either `???` or as `?name`.
- Flix supports infix function applications via backticks.
- Flix compiles to JVM bytecode and runs on the Java Virtual Machine.
- Flix supports channel and process-based concurrency, including the powerful `select` expression.
- Flix supports first-class Datalog constraints, i.e. Datalog program fragments are values that can be passed to and returned from functions, etc.
- Flix supports compile-time checked stratified negation.
- Flix supports partial application, i.e. a function can be called with fewer arguments that its declared formal parameters.
- the Flix type and effect system is powered by Hindley-Milner. The same core type system that is used by OCaml, Standard ML, and Haskell.
- the Flix type and effect system is sound, i.e. if a program type checks then a type error cannot occur at run-time. If an expression is pure then it cannot have a side-effect.
- the Flix type and effect system supports complete type inference, i.e. if a program is typeable then the type inference with find the typing.
- The Flix "Tips and Tricks"-section https://doc.flix.dev/tipstricks/ describes many useful smaller features of the language.
- Flix has a unique meta-programming feature that allows a higher-order functions to inspect the purity of its function argument(s).
- Flix names its floats and integers types after their sizes, e.g. `Float32`, `Float64`, `Int32` and `Int64`.
- Flix -- by design -- uses records for labelled arguments. Records are a natural part of the type system and works for top-level, local, and first-class functions.
- Flix -- by design -- has no implicit coercions, but provide several functions for explicit coercions.
- Flix -- by design -- disallows unused variables and shadowed variables since these are a frequent source of bugs.
- Flix -- by design -- disallows allow unused declarations. This prevents bit rot.
- Flix -- by design -- does not support unprincipled overloading. Instead, functions are given meaningful names, e.g. `Map.insert` and `Map.insertWithKey`.
- Flix -- by design -- does not support variadic functions. We believe it is better to pass an explicit array or list.
- Controversial: Flix defines division by zero to equal zero.
- Controversial: Flix defines String division as concatenation with the path separator. For example, `"Foo" / "Bar.txt" => "Foo\Bar.txt"` on Windows.
## Standard Library
Did you know that:
- Flix has an extensive standard library with more than 2,600 functions spanning more than 30,000 lines of code.
- the Flix Prelude, i.e. the functions which are imported by default, is kept minimal and contains less than 20 functions.
- most higher-order functions in the Flix standard library are effect polymorphic, i.e. they can be called with pure or impure functions.
- the Flix type and effect system enforces that equality and ordering functions must be pure.
- the Flix standard library uses records to avoid confusion when a function takes multiple arguments of the same type. For example, `String.contains` must be called as `String.contains(substr = "foo", "bar")`.
- the Flix `List` module offers more than 95 functions.
- the Flix `String` module offers more than 95 functions.
- the Flix `Foldable` module offers more than 30 functions.
- the Flix standard library follows the convention of "subject-last" to enable pipelining (`|>`).
## Ecosystem
Did you know that:
- Flix has an official Visual Studio Code extension.
- Flix has an official dark theme inspired by Monokai called "Flixify Dark".
- the Flix website (https://flix.dev/) lists the design principles behind Flix.
- Flix has an online playground available at https://play.flix.dev/
- Flix has online API documentation available at https://doc.flix.dev/
- the Flix VSCode extension uses the real Flix compiler.
- the Flix VSCode extension supports auto-complete, jump to definition, hover to show the type and effect of an expression, find all usages, and more.
- the Flix VSCode extension has built-in snippets for type class instances. Try `instance Eq [auto complete]`.
- the Flix VSCode extension supports semantic highlighting.
- the Flix VSCode extension has built-in "code hints" that suggests when lazy and/or parallel evaluation is enabled or inhibited by impurity.
- Flix has community build where Flix libraries can be included in the CI pipeline used to build the Flix compiler.
- Flix has a nascent build system and package manager based on GitHub releases. Today it is possible to build, package, and install Flix packages. Dependency management is in the works.
## Compiler
Did you know that:
- Flix -- by design -- has no compiler warnings, only compiler errors. Warnings can be ignored, but errors cannot be.
- the Flix compiler uses monomorphization hence primitive values are (almost) never boxed.
- the Flix compiler supports incremental and parallel compilation.
- the Flix compiler has more than 28 compiler phases.
- the Flix compiler contains more than 80,000 lines of code.
- the Flix compiler has more than 13,500 manually written unit tests.
- the performance of the Flix compiler is tracked at https://arewefast.flix.dev/
## Other
Did you know that:
- Flix is developed by programming language researchers at Aarhus University (Denmark) in collaboration with researchers at the University of Waterloo (Canada), and at Eberhard Karls University of Tübingen (Germany), and by a growing open source community.
- Several novel aspects of the Flix programming language has been described in the research literature, including its type and effect system and support for first-class Datalog constraints.
- Flix is funded by the Independent Research Fund Denmark, Amazon Research, DIREC, the Stibo Foundation, and the Concordium Foundation.
- more than 50 people have contributed to the Flix compiler.
- more than 2,000 pull requests have been merged into the Flix compiler.
In addition to the imperative `foreach` construct, Flix has two constructs for applicative[1] and monadic[2] comprehensions: `forA` and `forM`. Since applicatives and monads are related, it is useful that their syntax is similar, since it makes it easy to switch between the two. While having camelCase keywords may seem strange, in this case there is a feeling that it works out well. Certainly, `form` or `fora` would be much worse.
Applicative and monadic programming is not a big part of Flix, but it is something we want to support and make ergonomic. Also, these features may have scary names, but the concepts are not too difficult. See [1] and [2] for simple examples of how these features can be used for e.g. error handling.
[1] https://doc.flix.dev/applicative-for-yield.html [2] https://doc.flix.dev/monadic-for-yield.html
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!
"Flix also features full tail call elimination which has some run-time performance cost."
This is unavoidable when (a) the runtime enviroment, here the JVM, does not support tail calls, and (b) the language wants to guarantee that _any_[1] tail call does not grow the stack.
[1] Any call. Not just a call to the same function.
I, uh, think your math might need some checking :)
[0] https://www.cs.ioc.ee/tfp-icfp-gpce05/tfp-proc/21num.pdf
Some gems:
---
Q: Wait, division by zero is zero, really?
A: Yes. But focusing on this is a bit like focusing on the color of the seats in a spacecraft.
---
Q: "This site requires JavaScript"
A: People who have criticized the website for using JavaScript: [1], [2], [3], [4], [5].
People who have offered to help refactor the site to use static html: 0.
---
Q: I was disappointed to learn that Flix has feature X instead of my favorite feature Y.
A: We are deeply sorry to have let you down.
---
Q: This is – by far – the worst syntax I have ever seen in a functional language. Semicolons, braces, symbolic soup, et al. It is like if Scala, Java and Haskell had a one night stand in the center of Chernobyl.
A: Quite an achievement, wouldn't you say?
in the section:
What features are not supported by Flix?
this Feature on the left side:
No Code Before Main
does not match the Reason on the right side:
In Flix, no code is ever executed before main. Flix has no static initializers (or similar constructs) which are difficult to reason about, error-prone, and often lead to buggy code.
you should change the Feature name to:
Code Before Main
match File.exists(f) {
...
match File.stat(f) {
[1]: The page seems to randomize which one is shown. I got the "File information" one in the dropdown.