Kasper Møller Andersen (Dec 19 2024 at 21:38): Kasper Møller Andersen (Dec 19 2024 at 21:38):I agree with your reasoning, but I guess I don’t really know how to think of types being opaque or not. As in, with static dispatch pushing people towards building their types in a way that looks a lot like classes, maybe showing that construct up front makes more sense for a sizable portion of the audience out there? Anyway, not super important in itself, but I do personally find it hard to figure what different constructs imply in Roc these days.
Anthony Bullard (Dec 19 2024 at 21:52):My biggest concern with SD (besides silly syntactic changes) is that it will incentivize people to go all in on opaque types
Richard Feldman (Dec 19 2024 at 22:36):I'm totally not worried about that :big_smile:
Richard Feldman (Dec 19 2024 at 22:36):I think it'll actually be a lot more obvious than today when to use one and when not to
Richard Feldman (Dec 19 2024 at 22:36):moved to a different thread so we can discuss there!
Karl (Dec 19 2024 at 23:26):As someone tangentially connected to the project, I think the main complaint will be that the .foo... syntax does a lot of disparate things. I've been following along with most of the proposals and I'm +1 on them so I know the reason but I think that will be the complaint.
The snippet itself looks very Rust at first glance which I find unobjectionable but I do think there's a general desire for a less complex app-oriented Rust so I think that could be appealing. From a different perspective it also kind of looks like JS with a functional library (e.g. Ramda) and a weird lambda syntax. Good for familiarity, less good for novelty.
The most surprising piece of proposed syntax to me is having a for loop and "variables" in a pure functional language. I see that as a signal that that the language is intended to be pragmatic instead of pure/conceptual/doctrinal. I think more people will be coming from the imperative side so they won't be as impressed. I don't have any useful proposals but that's my two cents on the topic at least.
Notification Bot (Dec 19 2024 at 23:31):6 messages were moved here from #ideas > static dispatch - homepage example by Richard Feldman.
Kasper Møller Andersen (Dec 20 2024 at 06:19):Can someone lay out real quick how types look in Roc with all the proposals going on? Was there an opaque record type that was distinct from normal opaque types? I think I saw that somewhere.
Luke Boswell (Dec 20 2024 at 06:33):@Kasper Møller Andersen I think your looking for the Custom Types proposal and discussion.
Luke Boswell (Dec 20 2024 at 06:34):I haven't seen any succinct summaries of what the types will look like in future with all the proposals. It's definitely a bit hard to keep up some (even for me who mostly reads everything in here)
Brendan Hansknecht (Dec 20 2024 at 06:44):Frankly I don't think they will really look that different in practice
Brendan Hansknecht (Dec 20 2024 at 06:44):It will still be a module local opaque that exposes specific functionality to other modules
Brendan Hansknecht (Dec 20 2024 at 06:45):Just with static dispatch and more use for nominal typing instead of just opaque types
Brendan Hansknecht (Dec 20 2024 at 06:45):But I don't think it will look or feel that different typewise from today (past simply having static dispatch (implicit interfaces) instead of abilities (explicit interfaces))
Kasper Møller Andersen (Dec 20 2024 at 09:10):Okay, so I want to just type out what my intuition around the types look like right now:
Custom types plus static dispatch combine to make writing code that feels a lot like you're calling methods on classes, like in Scala for example. Scala even has a pipe function that acts a lot like pass_to. The major difference is in the definitions of the methods.
When you write a class, you have a clear definition for what is a method and what isn't. Static methods are actually functions, and everything else is a method. In Java and C#, you would use the static keyword to denote the statics, and in Scala, the two actually have separate scopes. That is, static methods live on object types, while regular methods live on classes.
But in Roc, the distinction between static methods (that is, functions) and straight up methods is less clear. The method must live in the same module as some custom type, and it must take that type as the first argument. That is, whether a function is actually a method depends on the ordering of arguments.
Coming from OOP languages like this, I would expect people to "custom type all the things", because that's what they're used to, and because it provides the chaining syntax they're used to. So I think there's a notable task in making sure people don't think of custom types as classes, despite the similarities they provide.
Brendan Hansknecht (Dec 20 2024 at 16:44):That is, whether a function is actually a method depends on the ordering of arguments.
This is true in many languages. You have to have a self or this parameter as the first argument
Brendan Hansknecht (Dec 20 2024 at 16:46):So I think there's a notable task in making sure people don't think of custom types as classes, despite the similarities they provide.
I do think that many many things will be custom typed. In most languages, custom types are the only option. Even in rust or zig (which are not too oop), the only option is named types.
Kilian Vounckx (Dec 20 2024 at 16:48):I think having more custom types isn't necessarily bad, because the internals can still be exposed if it is wanted. They are better than opaque types in that regard, for which I would have worries if they became more widely used
Brendan Hansknecht (Dec 20 2024 at 16:52):My biggest concern is definitely overuse, but at the same time, I'm not sure if there are really any downsides to overuse (only major one I can think of is code being split over too many files and maybe some types being less convenient to work with due to hiding too much (but you cal always expose more))
Brendan Hansknecht (Dec 20 2024 at 16:53):Given the baseline in essentially all languages is only nominal types.... It makes it hard to be worried about this (though we don't have the same namespacing of those other languages, but we could add it if it is truly needed)
Kasper Møller Andersen (Dec 20 2024 at 16:58):Although nominal types are the norm, I think it’s also common in many languages to over specify the code due to that. It’s nice in Elm to introduce opaque types more gradually. Similarly to how many people start thinking in terms of building “components” in Elm a la React, even though that’s a bit of an anti-pattern.
Brendan Hansknecht (Dec 20 2024 at 17:37):Yeah, I really don't feel I know enough to be sure. I totally agree with what you're saying, I'm just really unsure how it will feel and play out in practice.
Last updated: Jun 16 2026 at 16:19 UTC