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.
Thanks for explaining that term. That sounds really bad indeed. Maybe this is way too technical, but representing them as stack pointers was unfeasible?
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.
I'm not a compiler dev, but I know that many functional programming languages struggle with this in the same manner if the target platform does not support TCE itself, and therefore require trampolining.
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.
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
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.
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.
Going a little further, what I'd really like to see is the core concepts implemented in a way that allows a standard implementation to follow straightforwardly from the type system, but also allow for doing nonstandard things. Like, "here's a logic language built in" is kind of boring. What's more enticing is "Here are the components. Here's a nominal implementation based on these components. Here's a weird thing you can do that we hadn't actually designed for, but could fit certain use cases."
And sure, now I know it's all kind of fancy but fairly trivial stuff you can do with monads (and I guess free monads in the Linq-to-SQL case), but it was fascinating to me at the time.
So yeah, for "selling" purposes, I think rather than selling datalog built into the language as a front-page feature, a series of "how to build a datalog" posts would go further in showing off the power of the components of the language that it's built from.
(And FWIW I do like the way C# has built-in support for "important" monads like iterators (foreach), generators (yield), async (await), optional (null propagation operators), etc., even though a language purist would argue against it. I think it provides an easier on-ramp for newer developers, and helps make common things more concise and readable. So it'd be interesting to see where that line would best get drawn for logic programming, what gets special-but-extensible syntax support, and what is purely implementation and functions).
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.
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.
Not sure if you have some idea on how, but it feels like an unsolved problem to me. E.g. It is easy to theme a data structure, but if the layout matters it can be very hard to theme while also allowing free form edits.
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.
However, I believe an even better design choice would be to forgo string concatenation and instead rely entirely on string interpolation. String interpolation is a much more powerful and elegant solution to the problem of building complex strings.
I think of it less as hybris and more of a (failed) experiment. It was deliberately built as a 'stupid' language for fresh undergrads, lacking design experience.
It is a technical solution for a people problem. It is better to guide and to mentor people in designing the right abstractions. What we should learn from this experiment is that this is the wrong approach.
> It is a technical solution for a people problem. It is better to guide and to mentor people in designing the right abstractions. What we should learn from this experiment is that this is the wrong approach.
Nah, it was just the wrong solution.
People problems are basically intractable in the grand scheme of things. Whenever you can turn a people problem into a technical problem, that's an opportunity for progress.
Imagine telling everyone to be a professional and being careful not to break our program when they edit the code? Sounds like a big people problem!
Instead, we give everyone their own copy to muck around with (instead of a shared folder), and we only allow changes to be integrated into the 'master copy', if they pass automated tests.
A good manager and really motivated and professional workers can help cope with people problems. But there's a limit to their ability. So the more we can offload to technological solutions, the more 'professionalism' (for lack of a better word) we can spare for other task that aren't feasible to be solved via technology, yet.
And I agree that not all technical solutions work! You need to experiment, and make judgement calls.
I agree it was the wrong solution. The problem is that Go is quite popular and lots of code has been written in a language that cannot be fixed. And that is also a people problem, because living daily with a programming language feels like a marriage.
People keep fixing the unfix-able rather than moving on. I see the same happening with Python.
Python has gotten a lot better over the years. Though I'm not sure exactly which problem(s) with Python you are talking about, there are still plenty left.
Or "the earliest copier". Someone writes a story from an oral tradition down. It gets copied. Someone else copies the copy, and adapts the story to fit his own narrative.
The second order effects are were the real dangers lie: people will lose the ability to understand their own reality.
You see it at Twitter, where community notes are being replaced by AI. Stupid users asking "@grok is it true that ...?" People are gullible, putting trust where they absolutely shouldn't.
Musk wasn't happy about some facts, so grok changed. "Sorry, I was instructed to.."
These tools are seen by the clueless populace, whether it is your own aunt or some HN'ers, as an objective, factually correct oracle, free of influence.
Then there are lobby groups pushing for AI in the judiciary. Always under the banner of "cost savings". Sure, guess who gets their case being handled better.
A debate about what a healthy society would be, what people share as a common cause, is urgent as ever. Without reality distortion from autocratic interest groups an allied talking heads. The AI flood is unstoppable, but with the current culturally engineered crises in many democratic countries, it will most likely result in serious catastrophe.
> it's the richest people in the world holding on to power while the
> neoliberal house of cards that made them rich comes crumbling down.
Bingo. With al their tax rulings, exemptions, privatizations of public services, disinvestment in education, the ecosystem starts to suffer. They either reverse course, share power, go to a win-win mindset, or... double down and hollow out the last institutions, while distracting people with rage about imaginary transgenders and people with melanin. When the host dies, they jump onto the next victim. There are already sightings of Vance in Germany.
What we are seeing time and time again, the parasites are able to reprogram the host, steering it towards its own death.
... the reason you are able to chat on the internet instead of doing low paid, hard work. But don't discount the upside of immigration. It is a great subject to spread narratives about. "Others" is a matter to which people are very sensitive to. The Irish are absolute trash, as are the Italians. But what we really could do without are the Catholics, they are a direct threat to society.
There is always crime to report. But notice the narratives are never about white collar crime. That might come to close.
As a lukewarm defense of their statement, mass immigration has indirect effects too, it's not merely a reflection on the immigrants themselves.
There is a global rise in far right populism, and a large part of the justification and rhetoric they use points directly to mass immigration policies. There's a myriad of things they blame: crime, demographic or culture shift, economy.
To be clear, that isn't to say they're right blaming immigration. But its existence has put an enormous burden on democracies in The West. Just look at what a promise to get rid of immigrants did to the US 2016+: a captured, sycophantic, authoritarian government that disregards the rule of law regularly. Leading to regular mass protest and public opposition to LEO.
In Europe it's common to see people point to token heinous crimes - that pregnant woman raped into a miscarriage and her attacker given 12 months, the pedophile gang in the UK - and then use the demographics involved to radicalize people (especially young men - see the Alt Right Pipeline).
There is a shortage of courageous people. Military analysts and generals have sounded the alarm about serious gaps in capability, but they are all __retired__. The maga slogan is apparently just enough for media and public. The US doesn't build ships and is lacking the industrial capacity to sustain a prolonged war.
The Biden program's to onshore certain industries seemed to work, but those programs have been thrown in the toilet. The tariff scams have scared people to invest and expand production in the US.
It is one more example of how the concept "nation" or "common good" is meaningless for the 0,01%. You burn the village for personal profit. When the host dies they move to the next victim to parasite on, and so on.
Autocracies can't sustain themself, they will eventually collapse because without freedom sustainable and efficient productivity is not possible in the long term. It is why the Putin clan needs to parasite on other countries (Transnistria, Georgia, Ukraine etc). And this is why the Republicans are talking about annexing other countries.
0. https://hackage.haskell.org/package/base-4.21.0.0/docs/Syste...
reply