7 ms·

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

by tromp 3y ago

yashrk 3y ago
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.
- tromp 3y ago
  > 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
- satvikpendem 3y ago
  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 https://github.com/HigherOrderCO/hvm
  - weatherlight 3y ago
    i thought the orders of magnitudes faster benchmarks were around lazy evaluation, and probably wouldn't apply here.
  - tkz1312 3y ago
    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.
deleted 3y ago
[deleted]
adjav 3y ago
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.
- lambda_garden 3y ago
  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#issuecomment-916079347 https://github.com/fsharp/fslang-suggestions/issues/243#issu...
  - bbkane 3y ago
    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"
    - tome 3y ago
      Not just in the Go community! Everyone believes in "as simple as possible". The disagreement is about "but no simpler".
- tkz1312 3y ago
  Given its strict purity and use of typeclasses over modules I would say roc is more like haskell than it is ocaml.
TwentyPosts 3y ago
Convenience instead of historical baggage, maybe?
- epgui 3y ago
  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.
  - tkz1312 3y ago
    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.
    - epgui 3y ago
      > I don’t think you can claim it’s baggage free. Did I?
wk_end 3y ago
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.
- tkz1312 3y ago
  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?
  - ReleaseCandidat 3y ago
    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 https://www.youtube.com/watch?v=TE48LsgVlIU
    - tkz1312 3y ago
      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).
      - ReleaseCandidat 3y ago
        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-delimited-continuations-a-deep-dive 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.
tkz1312 3y ago
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.
zem 3y ago
strictness!

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

by tromp 3y ago

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

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.

tromp 3y ago
> 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
satvikpendem 3y ago
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 https://github.com/HigherOrderCO/hvm
- weatherlight 3y ago
  i thought the orders of magnitudes faster benchmarks were around lazy evaluation, and probably wouldn't apply here.
- tkz1312 3y ago
  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.

deleted 3y ago

[deleted]

adjav 3y ago

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.

lambda_garden 3y ago
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#issuecomment-916079347 https://github.com/fsharp/fslang-suggestions/issues/243#issu...
- bbkane 3y ago
  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"
  - tome 3y ago
    Not just in the Go community! Everyone believes in "as simple as possible". The disagreement is about "but no simpler".
tkz1312 3y ago
Given its strict purity and use of typeclasses over modules I would say roc is more like haskell than it is ocaml.

TwentyPosts 3y ago

Convenience instead of historical baggage, maybe?

epgui 3y ago
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.
- tkz1312 3y ago
  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.
  - epgui 3y ago
    > I don’t think you can claim it’s baggage free. Did I?

wk_end 3y ago

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.

tkz1312 3y ago
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?
- ReleaseCandidat 3y ago
  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 https://www.youtube.com/watch?v=TE48LsgVlIU
  - tkz1312 3y ago
    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).
    - ReleaseCandidat 3y ago
      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-delimited-continuations-a-deep-dive 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.

tkz1312 3y ago

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.

zem 3y ago

strictness!