Artur Swiderski (Dec 25 2023 at 11:19): Artur Swiderski (Dec 25 2023 at 11:19):I have this funny thought that exactly one year ago I started my very short journey with Haskell. I was not able to get any kind of proficiency unfortunately. What I think is that Haskell has good and honest fundamentals but it is carried away by hubris. From time to time I have Haskell videos recommended, so I see. People are inventive give them tools they will harm themself, c++ is like that, Haskell is like that. Roc fortunately is not yet there, it is easy to use environment wise (Haskell ecosystem I find just hostile ), in general it i easy to use syntax wise (again Haskell is just hostile), in Roc it is difficult to create something crazy syntax wise ("C" is ideal in that respect ). So overall what I like to convey is the hope, that things will stay that way. I hope that the language will never by swallowed by hubris like (c++, Haskell etc.). If it stays on it's current trajectory, I am next co certain that it will see wider adaptation at some point, it is just to good to be ignored..
Karakatiza (Dec 25 2023 at 11:45):Having messed Haskell for about two years I have to say my only real friction in the beginning was missing an easy IDE UX which made analyzing errors much slower, which later got resolved with VS Code plugin. I support your sentiment on Roc, just wanted to encourage some more time with Haskell if there is a room for that =)
Personally, after watching Richard's interviews I am confident his opinionated approach will ensure Roc will gain features while remaining accessible and non-bloated, which is going to be a fantastic boost for FP in a lot of projects, finally!
Artur Swiderski (Dec 25 2023 at 19:16):I think the problem starts with features, let's compare C and C++. C as it stands today is still good language. (It is good within its niche, low memory microcontrollers, so I would not use it outside of this domain necessarily)
What makes it so good ? In my opinion it has only features required for low level job, few abstraction and memory access. This is basically what I need in practice. When I am working with C code I can in one day become quite familiar with inner workings of given piece of functionality. I attribute it to the fact that it is not so easy to abuse, such a simple language. And yeah people still try to abuse it. Sometimes macro fixated developers makes things a little bit messier but the language prevents it by design in general.
Fortunately for C , C++ came along and all "ingenuity" went there. So as of today while C is still lean and effective, C++ transformed into ugly multi paradigm hybrid. In my opinion it is broken beyond repair, and should be dropped by industry whenever possible. There exists just too many ways in which I can screw my code. C++ almost encourages that. Before you notice the code became horrible pile of templates, lambdas and object oriented abstractions used at random. It just pure pain at some point. I ask myself why I even deal with that? For me programming suppose to be fun, not pain for no reason. Efficiency drops, code quality drops everything gravitates toward huge buggy mess. I put the blame on language here. Allowing to much freedom by adding contradicting highly redundant features, does not benefit anybody.And again I am asking why ? What war we are fighting here?
There is only so many problems I could realistically try to solve. Provide me friendly well crafted toolset, just for that and I will be happy.
Python works in that regard but for me it is soulless not fun at all, especially if I dive into some kind of algorithmic job. Roc as it is today stands out. Capabilities are there I can solve my problems and have fun at the same time.It would be great if the language could somehow avoid fate of C++ and stay just that good, fun, high level language
Andrew C (Dec 27 2023 at 00:27):I think the design goals of roc include simplicity of the roc language, so it's unlikely to fall into the traps of ever more esoteric abstractions that befall haskell. The fundamental ingredients of the roc language itself have learned the lessons of mistakes in the haskell standard library and from the bulletproof basics library of roc's parent leakage elm, so there aren't footguns away from crash (which you can always achieve by exceeding the capacity of your int or dividing by zero). Also, the separation of platform from application code means that if some new, better way to structure your code comes along, like the Elm architecture is better than FRP (which is again better than imperative ui), then no one needs to update the language, you can just release a new package with the simpler, better way of doing things. I see a lot of promise in the roc language. A lot.
Last updated: Jul 06 2025 at 12:14 UTC