Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flix – A powerful effect-oriented programming language

flix.dev

Post reply on HN
Print view View original

171–180 of 197 posts

Re: Flix – A powerful effect-oriented programming language

#171

Post by jorkadeen »

remon wrote: post #153

Interesting project but whoever decided "forM" is a good name for a language keyword should be made to gurgle Tabasco sauce for a few minutes.

That's me. But I must admit that I prefer Cholula Hot Sauce.

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

Re: Flix – A powerful effect-oriented programming language

#172

Post by jorkadeen »

throwthrow0987 wrote: post #158

If you have an effect ReadsFromDB, you can't enforce statically that someone will not come along and change the ReadsFromDB effect to write to the db. That's why I think Haskell got it right in the first instance, functions are either pure or IO.

What do you mean? In Flix, if a function has "Bool" as a return type then it can only return a Boolean value. That's what a type system ensures. Similarly, in Flix if a function has the "ReadsFromDB" effect then it can call operations that cause "ReadsFromDB"-- but it cannot cause any other effect. In particular, if there is also a "WriteToDb" then it cannot perform that effect.

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.

Re: Flix – A powerful effect-oriented programming language

#173

Post by jorkadeen »

rixed wrote: post #165

"Flix also features full tail call elimination which has some run-time performance cost." What are the run time costs being refered to here?

In the uncommon case, some stack frames must be heap allocated.

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.

Re: Flix – A powerful effect-oriented programming language

#174

Post by jorkadeen »

daxfohl wrote: post #98
exceptione wrote: post #32

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 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.

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.

Re: Flix – A powerful effect-oriented programming language

#175

Post by jorkadeen »

plainOldText wrote: post #125
jorkadeen wrote: post #43

Earlier quoted context omitted.

Cool blog post! With your permission, I would be happy to add it here: https://doc.flix.dev/blog-posts.html 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.

Heads up, the links to Paul Butcher's datalog posts are broken. The series can be found here now: https://paulbutcher.com/datalog1.html

Thanks-- I fixed the links!

Re: Flix – A powerful effect-oriented programming language

#176

Post by jorkadeen »

daxfohl wrote: post #102

Minor nit: the semicolons! Especially in the yield examples, since there's no "return" on the last line, the disparity looks weird. 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!

We plan to explore semicolon inference in the future; but there are a lot of dangerous corner cases to consider.

Re: Flix – A powerful effect-oriented programming language

#178

Post by jorkadeen »

cdaringe wrote: post #167
littleroot wrote: post #36

Earlier quoted context omitted.

>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 :-)

Re: Flix – A powerful effect-oriented programming language

#179

Post by lucyjojo »

idle_zealot wrote: post #135
jorkadeen wrote: post #109

Earlier quoted context omitted.

There is no significant indentation. What leads you to be believe that?

The Python-esque looking function defs.

looks like def x = expression

no indentation involved. did not dig in though

Re: Flix – A powerful effect-oriented programming language

#180

Post by gavinray »

pshirshov wrote: post #168
gavinray wrote: post #139

Earlier quoted context omitted.

I fully agree with you here. I primarily write JVM applications these days, and my go-to is Kotlin. Not because I think it's the "best" JVM language -- quite the opposite, I think Scala 3 is potentially the best-designed pragmatically useable language at the moment. But Scala 3 gives you "too much rope to hang yourself with". If you're the only person touching a codebase that's fine, but if you have to work with othe…

> But Scala 3 gives you "too much rope to hang yourself with". No, you use it wrong way. It gives you capability to write cleanest code possible. As with any expressive language you have to select a subset of features and a specific style and maintain it. Unmaintainable code can be written in any language, expressive ones provide you with tools to keep code maintainable. HKTs and macros make possible things which are…

I don't have the mental energy to review every line of code and argue with co-workers that they're "using it the wrong way" unfortunately.

Maybe in my younger years, but not after the first decade...

This is why Rob Pike designed Go the way he did, I think.

Post reply on HN