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

Roc – A fast, friendly, functional language

roc-lang.org

Post reply on HN
Print view View original

81–90 of 180 posts

Re: Roc – A fast, friendly, functional language

#81

Post by petepete »

cooperadymas wrote: post #46
satvikpendem wrote: post #13

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

Seriously ppl, go use a language where the creator is a paradigm of humanity. Maybe Python is a good choice? Seriously, tho, that's the comment that "made the Elm community a hostile and unwelcoming place" and is still being dredged up after 5 years? That comment can barely even be considered harsh, and is nowhere near hostile. Is it really worth tearing down someone's life, monitoring the internet for any time their…

A paragon of humanity?

Re: Roc – A fast, friendly, functional language

#83

Post by pjmlp »

shortrounddev2 wrote: post #44

Has anyone else noticed that functional languages go heavy on the special keywords and operators? It feels like theres a larger cognitive load (more specific keywords to memorize) when learning languages like F# or OCaml compared to C or Python or Java

Still way better than doing C++, speaking as someone that likes C++ since the Turbo C++ for MS-DOS days,

Re: Roc – A fast, friendly, functional language

#84

Post by Eji1700 »

whalesalad wrote: post #55
Eji1700 wrote: post #38

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

I've been on the F# website for 5 minutes now looking through damn near every page and I cannot find a single page that shows me a simple example program or the syntax at all. Everything is hidden behind some kind of "let's get started!" wizard. https://dotnet.microsoft.com/en-us/learn/languages/fsharp-he...

Oh yeah. A key hindrance of F# is that MS treats it like a side project even though it's probably their secret weapon, and a lot of the adopters are dotnet coders who already know the basics so the on-boarding is less than ideal.

https://fsharp.org/ is the best place to actually start, although i'm guessing you did and went to the hello world which leads back to ms's nightmares.

https://fsharpforfunandprofit.com/ is the standard recommendation from there but there's finally some good youtube and other content out there.

They have a browser repl as well https://try.fsharp.org/

Re: Roc – A fast, friendly, functional language

#85

Post by quaunaut »

asplake wrote: post #64

Having a play with Gleam right now. Roc's managed effects sounds interesting, maybe Gleam could layer something similar atop Erlang's OTP? Right now, outside a database, it's not clear to this newbie how state is meant to be managed in Misty, the Gleam web framework I am kicking the tyres of. If I can be bothered, I was seeing myself having to delegate state management to a separate process (which Gleam seems to supp…

I imagine state should be managed via GenServers[1][2], since that's the general BEAM way of doing that.

1. https://www.erlang.org/doc/man/gen_server.html 2. https://hexdocs.pm/elixir/1.12/GenServer.html

Re: Roc – A fast, friendly, functional language

#86

Post by satvikpendem »

weatherlight wrote: post #74
satvikpendem wrote: post #43

Earlier quoted context omitted.

Sure, but there are also a lot of languages to learn, in a vacuum I might learn Roc but now there are other options that don't have such history, it is not near the top of the list.

> other options that don't have such history Roc isn't Elm. RF is one person in that community, and he said something he regretted 5 years ago and has since not repeated that mistake. Do you know the moral dealings of every developer of every piece of technology you use? When it comes to Roc and It's community..ask yourself. “Am I sure that what I am going to say is true?” “Is what I'm going to say a good thing?”, an…

It's not about moral dealings, it's about whether I can trust the creators to not mess up a second time if they had already messed up once. We were shipping Elm in production and we moved away because any issues that were brought up that we wanted to see solved were swept away. Eventually it wasn't worth keeping the Elm codebase around. So, why should I trust one of the same people again? We already learned an expensive lesson one time around.

> When it comes to Roc and It's community..ask yourself.

Sorry, but this kind of faux niceness is precisely what stopped people from asking about issues, as it was always argued that asking about such issues was not "useful," after some time. So yes, I do feel the need to bring up this topic if only for others to evaluate the creators themselves rather than only have "good" things to say that "really need" to be said.

Re: Roc – A fast, friendly, functional language

#88

Post by ReleaseCandidat »

tkz1312 wrote: post #76
wk_end wrote: post #67

Earlier quoted context omitted.

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

Re: Roc – A fast, friendly, functional language

#89

Post by fourteenminutes »

davidatbu wrote: post #80

I'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 (…

It's unlikely that macros will be supported. Regarding editors, it's unlikely that effort on the advertised Roc editor will start in earnest some time soon. I actually recently merged an LSP implementation into the mainline compiler ([details on how to integrate here](https://roc.zulipchat.com/#narrow/stream/304902-show-and-tel...)), and that's likely to develop more in the near future, before a standalone Roc editor is available.

Re: Roc – A fast, friendly, functional language

#90

Post by rtfeldman »

davidatbu wrote: post #80

I'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 (…

Glad you've been enjoying Software Unscripted, thank you for the kind words!

> 1. Whether they'll support macros,

The plan is not to support macros. A major reason is that macros tend to conflict with editor tooling, and I definitely have big plans for Roc's editor tooling!

> 2. Whether their decision to build a whole new IDE will take away from the work that will go into an LSP (it will take a lot to pry away neovim from my hands).

The IDE project has been deprioritized a lot (e.g. I don't expect any work to be done on it in 2024) because we realized there's a way to build the editor plugin ecosystem we want to build in a way that works across multiple editors.

There already is a preliminary language server, and there are instructions in the VS Code extension for how to get it set up [0]. I assume something similar should work for neovim!

EDIT: I just noticed that while I was typing this, the author of the Roc language server responded too...hi, Ayaz! Thanks for all your excellent contributions to Roc!

https://github.com/ivan-demchenko/roc-vscode-unofficial#conf...

Post reply on HN