Not a fan of the usage of backslashes \
Roc – A fast, friendly, functional language
91–100 of 180 posts
Re: Roc – A fast, friendly, functional language
#92Earlier quoted context omitted.
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).
Re: Roc – A fast, friendly, functional language
#93Looks interesting. I'm a huge fan of F# and think anything working in that hybridish space is the way to go. I'll have to dedicate some more time to this when I get a moment.
> hybridish space I'm sorry, but what do you mean by that? Roc is "as" pure as Haskell (or Koka), if that's your point.
I glanced at the example code and it looked like it allowed side effects, but maybe I was wrong. I haven't had much time to mess with it and seemed to be able to hard crash the repl doing some testing so it's something i'll have to look at later.
Re: Roc – A fast, friendly, functional language
#94I don't know, after having used Elm and seeing the community accused of "hostile attacks" by one of the main contributors (who is the creator of Roc now) [0], I don't feel that it's worth my time to put into learning it, even if it is objectively good; I simply cannot know what the creators will do (or refuse to do, in the case of Elm) in the future, especially in a BDFL governance paradigm. This was in fact why I st…
Everyone has their moments no? In person Richard seemed like a super nice guy and the many lectures he did for Elm really showed a passion for helping improve the day to day experience for developers. He was also super active on the forums and slack helping people out.
Re: Roc – A fast, friendly, functional language
#95Earlier quoted context omitted.
> hybridish space I'm sorry, but what do you mean by that? Roc is "as" pure as Haskell (or Koka), if that's your point.
I glanced at the example code and it looked like it allowed side effects, but maybe I was wrong. I haven't had much time to mess with it and seemed to be able to hard crash the repl doing some testing so it's something i'll have to look at later.
Well, yes, if there are no type annotations because all types are inferred, you don't see the effect "types".
Re: Roc – A fast, friendly, functional language
#96If you are interested, «why yet another programming language?». The unique selling point of Roc is clever optimization to convert purely functional source code to deep-imperative fast machine code, while keeping all the correctness of functional algorithms. See this video of Richard Feldman for details — «Outperforming Imperative with Pure Functional Languages»: https://www.youtube.com/watch?v=vzfy4EKwG_Y Among those…
That sounds a lot like Koka. Is there any relationship?
Re: Roc – A fast, friendly, functional language
#97I don't know, after having used Elm and seeing the community accused of "hostile attacks" by one of the main contributors (who is the creator of Roc now) [0], I don't feel that it's worth my time to put into learning it, even if it is objectively good; I simply cannot know what the creators will do (or refuse to do, in the case of Elm) in the future, especially in a BDFL governance paradigm. This was in fact why I st…
I believe in second chances. From the GitHub link: > EDIT 5 years later: You can see in the edit history of this comment what I originally wrote here; I was upset and said unkind things that I regret, and which nobody deserved to hear. I apologized at the time and I still feel I should apologize again, unequivocally. I was in the wrong here.
Yep, this is good enough for me, and I suspect for anyone who is not hellbent on holding a grudge.
Re: Roc – A fast, friendly, functional language
#98I'm super keen to see how Roc pans out, because it sits at an (IMO) riveting spot in the space of PL design tradeoffs: 1. The typesystem will be sound, ML-like, and so simple that any code that doesn't interact with external data will not need _any_ type annotations. 2. An aim to make it the fastest managed compiled lang around (faster than golang). 3. Functional. 4. A focus on fast compile times from the beginning (…
> 1. The typesystem will be sound, ML-like, and so simple that any code that doesn't interact with external data will not need _any_ type annotations.
I've tried using languages with this promise, such as Haskell, and also spent a lot of time with TypeScript, which makes a different set of tradeoffs, and I feel like I've spent enough time on both to know this is the wrong tradeoff to make. It sounds flashy to be able to say that no type annotations are necessary, but in practice what it ends up meaning is that you end up tracking down errors in the wrong parts of your code because the compiler can't figure out how to reconcile problems.
e.g., you have function A incorrectly call function B. How does the compiler know if A has the wrong arguments, or B has the wrong signature? It can't! I know that's a toy example, but it really does lead to a lot of real-world frustration. Sometimes the type errors are very far away from where the actual issues are, and it can lead to a lot of frustration and wasted time.
The TS approach of "please at least annotate all your function signatures" isn't nearly as flashy, but it strikes a much better utilitarian balance.
Re: Roc – A fast, friendly, functional language
#99Earlier quoted context omitted.
I just did some quick math. If you count all the keywords and operators for F# in microsoft's documentation, you come to 150 symbols. This doesn't include the nullary operators (of which there are 14) Counting all the java operators and keywords, you get 84. This doesn't include assignment operators like "+=" or "-=" (11 such operators). ChatGPT tells me that python has 36 keywords and 28 operators (not including the…
You're right, there actually are more. Interesting, I "feel" the opposite. Haskell (55 + some more, because of the grouping): https://wiki.haskell.org/Keywords F# https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref... OCaml: https://v2.ocaml.org/manual/lex.html#sss:keywords Python: https://github.com/python/cpython/blob/3.12/Lib/keyword.py Java (I think these are the current ones): https://docs.oracle.com/ja…
A few of the Haskell ones are introduced by extensions, so they're not part of the language proper.
Re: Roc – A fast, friendly, functional language
#100Earlier quoted context omitted.
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.