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

The Flix Programming Language

flix.dev

Post reply on HN
Print view View original

81–90 of 126 posts

Re: The Flix Programming Language

#81

Post by zozbot234 »

amelius wrote: post #76
mrkeen wrote: post #62

Earlier quoted context omitted.

It's Rust.

Rust sucks for functional programming because it has no GC. While you get controlled mutation, you don't get anywhere near the ergonomics that it requires. The reason why Haskell and other popular FP languages all require a GC.

The two have very little to do with each other. What one could say is that higher level functional-like patterns are less idiomatic in Rust, because they abstract away from the low-level control that Rust also provides - which is why Rust chooses to provide, e.g. GAT's as a language feature as opposed to HKT's.

But functional programming is fully supported and lack of GC is not an issue, since you can use Rc and Arc where needed. (Support for 'pluggable' tracing Gc will probably be added at some point, but it will need local allocators, which are not a stable feature yet.)

Re: The Flix Programming Language

#83

Post by Yoric »

Oh, Datalog within the language? Exciting!

I've been looking for such a feature for some time. Do I understand correctly that the facts can be established dynamically from, say, IO functions?

Also, are you going to present at FOSDEM?

Re: The Flix Programming Language

#84

Post by amelius »

zozbot234 wrote: post #81
amelius wrote: post #76

Earlier quoted context omitted.

Rust sucks for functional programming because it has no GC. While you get controlled mutation, you don't get anywhere near the ergonomics that it requires. The reason why Haskell and other popular FP languages all require a GC.

The two have very little to do with each other. What one could say is that higher level functional-like patterns are less idiomatic in Rust, because they abstract away from the low-level control that Rust also provides - which is why Rust chooses to provide, e.g. GAT's as a language feature as opposed to HKT's. But functional programming is fully supported and lack of GC is not an issue, since you can use Rc and Arc…

Oh yes, some basic form of FP is supported in Rust, but it's not the real thing. You can't write idiomatic FP because you really need a GC for that as the reference patterns created by closures are always cyclic. There's a reason why Haskell needs a full-fledged GC.

Re: The Flix Programming Language

#85

Post by mikhailfranco »

nextaccountic wrote: post #11

> Region-based Local Mutation > Flix supports region-based local mutation, which makes it possible to implement pure functions that internally uses mutable state and destructive operations, as long as these operations are confined to the region. > We can use local mutation when it is more natural to write a function using mutable data and in a familiar imperative-style while still remaining pure to the outside world.…

I wish Erlang/Elixir would allow this.

An Erlang/Elixir process is single-threaded by definition, so there is no contention and in-place mutation could be allowed.

Re: The Flix Programming Language

#86

Post by archargelod »

> The following design choices may be considered controversial by some:

> Dividing by zero yields zero. https://www.hillelwayne.com/post/divide-by-zero/

That's one interesting point I would love to read any opinions on.

Edit: Here's a HN discussion about the `divide by zero` article - https://news.ycombinator.com/item?id=17736046

Re: The Flix Programming Language

#87

Post by peheje »

qsort wrote: post #7
ashton314 wrote: post #2

Woah, the effect system looks really neat at first glance. Also, “region-based local mutation” so your pure functions can use mutation under the hood for performance? Sweet!

I'd like to see an experimental language that leans hard into the concept of controlled mutation. I always say that purely in terms of design my ideal language is high-level Haskell, low-level C. Conceptually, purely functional design is how programming "should" (note the quotes) be, but doing so down to the level of functions is both not very practical (some algorithms are just easier to express in terms pointers mo…

Have you tried F#? Can recommend you give it s try.

Re: The Flix Programming Language

#88

Post by nrabulinski »

Too wrote: post #66
imoverclocked wrote: post #17

Earlier quoted context omitted.

Your username matches your comment! Also, I agree but I'm not sure what I would propose as a better token. Maybe another colon? def printAndInc(x: Int32): Int32 \ IO = becomes: def printAndInc(x: Int32): Int32 : IO = Or maybe, since functions need something after the \, even for pure functions, we just drop the \ and use the last argument? def printAndInc(x: Int32): Int32 IO =

Why not something human readable? pure vs mut? Other languages already have readable keywords in the function definition; extends, raises, where, having, Optional, and so on. They don’t feel unnecessarily verbose.

Because they’re working on algebraic effects so obviously IO won’t be the only effect out there. Also because “mut” is even more misleading as it doesn’t capture everything an “IO function” can do, in comparison to a pure function.

Re: The Flix Programming Language

#89

Post by karmakaze »

archargelod wrote: post #86

> The following design choices may be considered controversial by some: > Dividing by zero yields zero. https://www.hillelwayne.com/post/divide-by-zero/ That's one interesting point I would love to read any opinions on. Edit: Here's a HN discussion about the `divide by zero` article - https://news.ycombinator.com/item?id=17736046

There's a brief description of the same choice[0] made by the Pony language.

[0] https://tutorial.ponylang.io/gotchas/divide-by-zero.html

Re: The Flix Programming Language

#90

Post by ben0x539 »

globalnode wrote: post #6

do functional languages mainly appeal to computer language enthusiasts/researchers? im just not seeing the benefit personally.

I think for me the appeal is that just that all the big brain programming language research seems to happen in weird new functional languages. I assume they're just a better petri dish for experimenting with weird shit, or maybe they come up with all the weird shit to be able to get things done in the Haskell-du-jour, or maybe weird shit just gets branded as functional programming by default. (These days the fp people always talk about linear types, or effects, or other things that don't seem to involve functions at all, idk what's up with that...)

I assume that all of this gets funding because ten years later it makes C# programmers more productive, not because of mass appeal.

Post reply on HN