I hate lot of keywords.
Flix – A powerful effect-oriented programming language
91–100 of 197 posts
Re: Flix – A powerful effect-oriented programming language
#92>> 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?
In Flix all effects are tracked by the type and effect system. Hence programmers can know when a function is pure or impure. Moreover, pure functions can be implemented internally using mutation and imperative programming. For example, in Flix, one can express a sort function that is guaranteed to be pure when seen from the outside, but internally uses a quick sort (which sorts in place on an array). The type and eff…
Haskell can do the same kind of thing (local mutation), using the ST monad.
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 >>=.
Re: Flix – A powerful effect-oriented programming language
#93Earlier quoted context omitted.
Flix supports type classes (called "traits") with higher-kinded types (HKTs) and with associated types and associated effects. A Flix trait can provide a default implementation of a function, but specific trait instances can override that implementation. However, Flix has no inheritance. The upshot is that traits are a compile-time construct that is fully eliminated through monomorphization. Consequently, traits incu…
> The upshot is that traits are a compile-time construct that is fully eliminated through monomorphization. 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 progra…
The reality is that careless programmers will do bad things with any tool they happen to pick up. Using that as an excuse to reduce the power of a tool is poor form.
Another way of putting it is to point out that removing goto from a language isn't going to reduce the occurrence of spaghetti code. The average skill and care of the developers who happen to be using that language is what does that.
Re: Flix – A powerful effect-oriented programming language
#94Earlier quoted context omitted.
> 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 cod…
Java shouldn’t have boxing “soon”. If we ever see the results of Valhalla.
Re: Flix – A powerful effect-oriented programming language
#95Earlier quoted context omitted.
Because I might write enum Shape { case Circle(Int32), def area(s: Shape): In32 = match s { Not only I had to write something that the compiler already knows, but I typed a compilation error. The second type definition is there only to make developers write it wrong. It does not add any information.
> The second type definition is there only to make developers write it wrong. Int32 is the type of the return value for the function ( https://doc.flix.dev/functions.html ), which is distinct information not implied by the type being passed in (Shape), so I dispute this characterization--the fact that this type is the same type as the parameter given to all of Shape's terms is specific to this example. Furthermore I…
> Int32 is the type of the return value for the function [...]
You are right. That part of my argument is wrong.
Re: Flix – A powerful effect-oriented programming language
#96Earlier quoted context omitted.
Targeting JVM means not having to roll your own garbage collector. And bonus, you get a huge world of third party libraries you can work with. It's been over a decade since I worked on the JVM, and Java is not my favourite language, but I don't get some people's hate on this topic. It strikes me as immature and "vibe" based rather than founded in genuine analysis around engineering needs. The JVM gets you a JIT and G…
The JVM is a large and complex system with tons of configurable options. If you don't need it, why add all that cognitive overhead when you have perfectly good options that don't. And the benefits you gain are very limited if you aren't integrating with other JVM based systems.
You genuinely don’t need to think about any of the configurable options, especially if you’re running a client program. At most for server programs you just set the max memory percentage and soon you won’t have to do that.
Re: Flix – A powerful effect-oriented programming language
#97Any code agents work well with this or do we have to start thinking with our own brain again?
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.
Re: Flix – A powerful effect-oriented programming language
#98I 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 partic…
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.
Re: Flix – A powerful effect-oriented programming language
#99Awesome, 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…
Flix supports type classes (called "traits") with higher-kinded types (HKTs) and with associated types and associated effects. A Flix trait can provide a default implementation of a function, but specific trait instances can override that implementation. However, Flix has no inheritance. The upshot is that traits are a compile-time construct that is fully eliminated through monomorphization. Consequently, traits incu…
> 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.
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).
Re: Flix – A powerful effect-oriented programming language
#100I 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 partic…
Indeed. I even like the syntax.
Really? The mix of :/indentation-significant functions and braces for everything else seems extremely questionable.