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

161–170 of 197 posts

Re: Flix – A powerful effect-oriented programming language

#161

Post by daxfohl »

cap11235 wrote: post #114
daxfohl wrote: post #98

Earlier quoted context omitted.

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.

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.

Re: Flix – A powerful effect-oriented programming language

#164

Post by wk_end »

jrrrp wrote: post #159
miniBill wrote: post #86

Very cool language. The standard library looks mostly sane, although it does have `def get(i: Int32, a: Array[a, r]): a \ r` which means that it must have some kind of runtime exception system. Not my cup of tea, but an understandable tradeoff

Just looking at the language myself, but it seems that it treats out-of-bounds array access as a non-recoverable bug and panics [1, 2], whilst map access returns Option [3]. Exceptions are a language construct only to enable Java compatibility and not recommended otherwise [4], but that's not to say you couldn't implement your own try/catch using the effect system. `r` is a region variable as the sibling comment says…

I agree with OP that this seems a little unfortunate, even though it's pretty par for the course.

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

Re: Flix – A powerful effect-oriented programming language

#166

Post by fc417fc802 »

jorkadeen wrote: post #110
fc417fc802 wrote: post #93

Earlier quoted context omitted.

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.

Not sure I agree. A simple example: If your language has null as a subtype of every type then you will have null ptr exceptions everywhere. If your language does not have a null value then you won't. The situation is not as clear cut as you suggest. Yes, you can write spaghetti code in any language. But a good language design can help (a) reduce errors and (b) nudge the developer towards writing better code.

I feel like that example doesn't fit except in the specific case that the language designer restricts the usage of null in a way that reduces the overall expressiveness and power of the language. Whereas (but one example) the operators provided by Kotlin don't do that.

Obviously how exactly you structure a particular end result is going to involve lots of fuzzy tradeoffs. My point wasn't about such nuance but rather the sort of reasoning that leads the the dismissal of an entire feature (in this case proper macros) on the basis of saving developers from themselves.

There should be (at least IMO) a clear delineation between a language design that makes it possible to do things in a sensible manner versus the realm of style guides, linters, and pre-commit hooks that enforce restrictions intended to maintain sanity on large projects. I shouldn't feel compelled due to deficiencies in the design of the language to reach for constructs like goto but those constructs should still be there if I have a need for them. People shouldn't feel compelled to waste time patching their tools to work around the opinions of the designers being forced on them. [1][2]

That said, it would be nice if compilers themselves universally provided native linting facilities, possibly even enabled by default.

[1] https://github.com/kstenerud/go

[2] https://github.com/tpope/heroku-fucking-console

Re: Flix – A powerful effect-oriented programming language

#167

Post by cdaringe »

littleroot wrote: post #36
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…

>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

Re: Flix – A powerful effect-oriented programming language

#168

Post by pshirshov »

gavinray wrote: post #139
jorkadeen wrote: post #110

Earlier quoted context omitted.

Not sure I agree. A simple example: If your language has null as a subtype of every type then you will have null ptr exceptions everywhere. If your language does not have a null value then you won't. The situation is not as clear cut as you suggest. Yes, you can write spaghetti code in any language. But a good language design can help (a) reduce errors and (b) nudge the developer towards writing better code.

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 completely impossible in most other languages without a preprocessor/compiler plugin.

Re: Flix – A powerful effect-oriented programming language

#169

Post by FieryTransition »

achenet wrote: post #145
FieryTransition wrote: post #143

I'm looking forward to the day where an ml/functional inspired language can be used for real time rendering and game engines, how far are we from that? 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 w…

possibly a stupid answer (and if so, someone please invoke Cunningham's law and correct me) but - 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/

Rust is a good candidate, but it lacks some crucial aspects when it comes to what I would consider 'nice to haves' from a modern language in this territory.

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.

Re: Flix – A powerful effect-oriented programming language

#170

Post by exceptione »

sparkie wrote: post #92
jorkadeen wrote: post #9

Earlier quoted context omitted.

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 u…

What do you mean with 'cannot'? We have this in [0]

  unsafePerformIO :: IO a -> a
Do you mean "cannot do with safety guarantee"? Strangely enough, the haskell docs use the same language as you:

  The ST monad allows for destructive updates, but is escapable (unlike IO).
___

0. https://hackage.haskell.org/package/base-4.21.0.0/docs/Syste...

Post reply on HN