Stream: beginners

Topic: question about tutorial and some comments

Sławek Brzózka (Dec 30 2025 at 03:38):

Musician : { first_name : Str, last_name : Str }
Musician has the type { first_name : Str, last_name : Str }."
is
Doesn't that suggest we have a hierarchy of types here? Why isn't alias simply =

In general my impression after reading the tutorial and FAQ is that the language is quite well thought out. It's very obvious that it wants to be beginner-friendly (e.g., the comment about else-if), but maybe that's a good thing. I understand the decision about Optional and HKP, but the one thing that I very disagree with is currying.
I've already shown functional programming to several of my colleagues, programmers and mathematicians, and I was able to explain currying to each of them in a few minutes. Even if they found it strange at first, they were able to appreciate the advantages. Why just don't support both styles? I know it's already decided, but it's sad, especially since I like the rest of the language.
Besides, my suggestion is to add some technical information about the language (e.g. about type system) in some intuitive place on the website. Most of these things are pushed into the "fast" section. This is particularly useful because the language does not yet have a Wikipedia page where one could see a summary table.

Luke Boswell (Dec 30 2025 at 03:46):

There is a WIP language reference https://github.com/roc-lang/roc/tree/main/langref

Luke Boswell (Dec 30 2025 at 03:47):

But a lot of detail is yet to be fully documented

Luke Boswell (Dec 30 2025 at 03:47):

I think the focus right now is building the compiler -- and soon we will really flesh out the docs

Luke Boswell (Dec 30 2025 at 03:48):

Adding nice technical information is very much on the roadmap .. we just have limited hands contributing so these things take time

Richard Feldman (Dec 30 2025 at 04:02):

Foo = Foo
Ok(a) = Ok({})

These are already valid expressions, so if = were the syntax for type aliases, it would always be ambiguous whether they were expressions or type aliases :smile:

Richard Feldman (Dec 30 2025 at 04:03):

also, welcome!

Anton (Dec 30 2025 at 09:52):

I understand the decision about Optional and HKP, but the one thing that I very disagree with is currying.

Hi @Sławek Brzózka,
It's common for newcomers to be surprised by the lack of currying :)

I've already shown functional programming to several of my colleagues, programmers and mathematicians, and I was able to explain currying to each of them in a few minutes. Even if they found it strange at first, they were able to appreciate the advantages.

This will sound condescending; I believe Richard taught currying numerous times in a practical setting and noticed difficulties when people had to use it. So the experience may be different from explaining the concept.

Why just don't support both styles?

• It lowers error message quality, because there can no longer be an error for "function called with too few arguments.". Calling a function with fewer arguments is always valid in curried functions; the error the user gets instead will unavoidably be some other sort of type mismatch, and it will be up to them to figure out that the real problem was that they forgot an argument.
• We experience a lot of benefits from minimizing the number of features and concepts in the language.
• Perhaps most importantly, once people gain some experience with Roc they never miss currying. We've had zero reports from people still wanting currying after using Roc for a couple of months.

Sławek Brzózka (Dec 30 2025 at 20:58):

Thanks for all the replies. I'll be keeping an eye on how this language develops.

Norbert Hajagos (Jan 02 2026 at 08:26):

But also, currying isn't prohibited. If you need it, because it makes the particular problem you're dealing with easier, you can manually curry the functions, the community isn't going to yell "we don't do that here". It's just not the default, since the assumption is that you need it way-way less than always. If you're interested, I suggest giving it a try. Many have walked this path before and arrived with the conclusion that they actually like it that way. You may do the same:smile:

nandi (Jan 02 2026 at 19:46):

Norbert Hajagos said:

If you need it, because it makes the particular problem you're dealing with easier, you can manually curry the functions

Im curious about how one even goes about doing this

Brendan Hansknecht (Jan 02 2026 at 20:34):

just explicitly take one arg and return a lambda

Brendan Hansknecht (Jan 02 2026 at 20:35):

uncurried = |x, y| {
    x + y
}

curried = |x| {
    |y| {
        x + y
    }
}

nandi (Jan 02 2026 at 20:36):

oh I thought they were talking about currying existing functions

Richard Feldman (Jan 02 2026 at 20:37):

you can also do |x| |y| { ... }

Sławek Brzózka (Jan 02 2026 at 20:37):

I guess it's also possible

Sławek Brzózka (Jan 02 2026 at 20:38):

+ is also existing function after all

Brendan Hansknecht (Jan 02 2026 at 20:39):

curried = |x| |y| existing(x, y)

Brendan Hansknecht (Jan 02 2026 at 20:40):

You can also write a curry2 function if you really want (have to write a different version for very arg count: curry2(existing) where curry2 = |fn| |x| |y| { fn(x,y) }

nandi (Jan 02 2026 at 20:49):

roc has currying Q.E.D.

Sławek Brzózka (Jan 02 2026 at 20:50):

C++ also has:)

Last updated: Jan 12 2026 at 12:19 UTC