Comment by exceptione
3 days ago
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 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.
>a single executable is both the package manager, LSP and the compiler
oh my i just know you're going to love unison
the silly insane pythonic whitespace significance and lack of formatter drove me nuts. LSP didnt work half the time. Loved the idea, will visit again, but it resisted me expressing my program. If they get rid of the whitespace malarkey (why do i have to say it it!?) and the dev tools spruce up, im all in baby
Flix does not have significant whitespace. Where did you run into trouble? You are welcome to swing by Gitter if you need help. We are friendly :-)
Thanks for giving me homework. :-)
> AFAIK, types are erased by JVM compilers...
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.
The parent poster is correct. We do monomorphization, hence Flix types are unboxed. For example, a `List[Int32]` is a list of primitive integers. There is no boxing and no overhead. The upshot is that sometimes we are faster than Java (which has to do boxing). The downside is larger bytecode size-- which is less of a factor these days.
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.
Java shouldn’t have boxing “soon”. If we ever see the results of Valhalla.
The logic programming / datalog feels a bit gimmicky on top of everything else. All the other features, I can see exactly how they'd improve the type soundedness of a codebase. But logic programming is really niche and I'd almost rather it be independent of the language.
The counter-point is the following: Functional programming is great for working with lists and trees. But functional programming (and imperative programming) struggle with succinctly, correctly, and efficiently expressing queries on graphs. Datalog, on the other hand, is excellent for working with graphs. It is simple, expressive, and (can be) very fast. It is a power tool. Most of the time it should not be used, but when it fits the problem domain its benefit can be 10x or 100x. It is also worth pointing out that Datalog is strictly more powerful than SQL (modulo various extensions).
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.
But lists and trees aren't really "built into" languages. They're part of the standard library, not the language itself. Maybe one could say "foreach" syntax builds lists into a language, but in many languages you can foreach non-lists, others have foreach as a method instead of syntax, and it still doesn't say anything about trees.
I do see your point, I'm just not so sure I think it'd be the right thing to do. It feels like too big and arbitrary to be a core language feature, better left to a library. If there are some core features that would make building such a library easier, I'd focus on those rather than the logic programming itself. Something like how Rust did async. (Though contrarily, I think Rust should have built async into the language, since it's pervasive and hard to interop different implementations. Unlike async, logic programming is typically self-contained, and there would rarely be a need to interop multiple implementations).
Anyway, great work so far. I look forward to seeing it progress.
1 reply →
Right, it feels like a standard example of a Lispy library (Datalog), and a Prolog monad is standard teaching material. I am of the opinion that Flix is strictly worse than Idris2
> I am of the opinion that Flix is strictly worse than Idris2
That seems irrelevant to my original comment. Idris is a fully dependently-typed language that compiles to native code, and seems to be in maintenance mode. Flix is built on JVM, uses effects rather than dependent types, which I think makes an 80/20-rule sacrifice of type safety for ease-of-use, and seems to have a more active community (for now).
But yeah, the datalog thing feels unnecessary. Like the SQL built into Linq/C#, cute, but doesn't really scale for real-world use cases, so there's still a need for independent ORMs. I see a similar thing here. No need for building this into the language. There are plenty of logic libraries, services, persistent stores, etc that can do datalog, so let users use them the way they want. Building it in just feels gimmicky at best, potentially troublesome at worst.
It gives me a similar feeling as the old language / web platform, Opa. It was a really cool language for the time, and had client-server functionality (similar to meteor) built into the language itself. But as web client-server frameworks fell out of favor, so went the language itself.
Here, I think the built-in datalog makes it seem like a language that's hinging too much on a gimmick, and takes away from the impression it gives as a serious language.
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.
Right, they have something like computation expressions, but they are not composable.
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...
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.
3 replies →
It seems to have borrowed heavily from Rust, which got a lot of these details right.
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?
2 replies →
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.
Plus that you regretted having `+` as a concatenation operator.
src: https://flix.dev/blog/design-flaws-in-flix