Hacker News Reader

Comment by tromp | Hacker News Reader

Does Roc have any features that a Haskell programmer could consider improvements?

I think it boils down to:

  - simplicity
  - strict evaluation model
  - devx
  - faster runtime
  - built in effect system

I love haskell and write it every day, but I have the feeling that the language is probably too complex to really cross over to the mainstream. I remain convinced that the advantages of a pure functional approach are so compelling that we will one day see roc or something like it be the default choice for most programming tasks, and am really excited to see so much progress being made on the language.

Not really, no. Like Elm, it strips away practically everything that wasn't already in 1970s-era ML. It's much closer to a trimmed-down Ocaml than it is to Haskell.

Some in the ML community think a simpler language has advantages over a more expressive one, in some cases.

For example: https://github.com/fsharp/fslang-suggestions/issues/243#issu...

Not just the ML community. Go's simplicity is often derided, but I think the best in class tooling (dev tooling like gopls, golangci-lint, deployment tooling like ServiceWeaver, Goreleasor, etc) and easy understandability more than make up for "what yuu can't do"

Not just in the Go community! Everyone believes in "as simple as possible". The disagreement is about "but no simpler".

Given its strict purity and use of typeclasses over modules I would say roc is more like haskell than it is ocaml.

Haskell programmers tend to love their monads, but the treatment of effects here ("Tasks"), looks to be - and this is highly subjective - more intuitive and straightforward.

ETA: Also if I'm reading this right Roc appears to natively support some kind of row polymorphism. That's a nice-to-have.

I think algebraic effects usually just compile down to monads under the hood? As I understand it, it’s more like a cleaner interface to model side effects, than some new approach compared to the tools that haskell gives you out of the box?

No, not necessarily (that's just how some(?) of them are implemented in Haskell, and that's slow too). Since 9.6.1 GHC has primitives for delimited continuations, with which effects should be implementable in a more straightforward and performant way.

Alexis King, who added these primitives to GHC, on (delimited) continuations https://www.youtube.com/watch?v=TE48LsgVlIU

I had understood that the delimited continuations stuff was more like performance optimisation for the (slow) free monadic effect systems than a fundamentally different theoretical foundation for modelling effects in a pure language?

fwiw we also have fast effect systems in Haskell these days that are more like fancy type sugar on top of the ReaderT over IO style of things (effectful seems to be the most popular).

I've thought that all "native" (in the compiler instead of a library) implementations use (more or less) delimited continuations (some kind of temporary stack moving/copying). OCaml : https://github.com/ocaml-multicore/ocaml-effects-tutorial#3-... And Koka: I haven't found the paper/docs right now.

I know about effectful, but that doesn't use Reader (but provides one) but more or less directly IO (Ref) and "evidence passing", that's why it is faster than the other ones, the drawback is not being able to use non-deterministic effects and noo such thing as coroutines. But I talked about eff ("native" delimited continuations) should be more or less the same, maybe a bit faster, than effectful, but enable non-determinism and coroutines.

First of all — way faster machine code.

Many other things are features or bugs depending of your preferences. For me, for example, eager evaluation is a big improvement, but YMMV.

> eager evaluation is a big improvement

Does it have any support for laziness? E.g. could one define the list of all fibonacci numbers similarly to Haskell's

    fib = let f a b = a : f b (a+b) in f 0 1

How does it compare to HVM [0]? It is an alternative to GHC that in some cases is orders of magnitudes faster, at least from their benchmarks.

[0] https://github.com/HigherOrderCO/hvm

Roc uses perceus, which is a reference counting model that allows for opportunistic in place mutation if it is safe to do so. HVM is more like a fundamentally new evaluation model that is parallel by default. They are both very exciting, but HVM is much more radical and probably needs at least a few more years until it starts to be seriously practical.

i thought the orders of magnitudes faster benchmarks were around lazy evaluation, and probably wouldn't apply here.

strictness!

Convenience instead of historical baggage, maybe?

All languages have some amount of historical baggage, but I'm not sure what you're referring to here.

If anything, Haskell gets a lot of eyerolls for its slow moving pace and for trying to build a language from mathematical first principles.

It's not perfect (eg.: Monad was not designed to be a special case of Applicative in the beginning, I believe) but it's better at "avoiding baggage" than many other languages I know of.

Haskell is a wonderful language, but I don’t think you can claim it’s baggage free. It’s certainly accumulated it’s fair share of technical debt (more in the standard library than the core language to be fair). The endless proliferation of often complex and hard to understand extensions also certainly raises the bar for beginners.

> I don’t think you can claim it’s baggage free.

Did I?

Reply on news.ycombinator.com