While it’s true that “all you need is data and functions”, you could also say that “all you need is mov”, since “mov” is Turing complete. Type classes / traits, like many other PLT advancements, allow speaking more precisely and expressively about the desired semantics. Bounded quantification is strictly more expressive than universal quantification.

I’ve seen this principle in a few different guises. In Haskell there is an approach called Scrap Your Type Classes (https://www.haskellforall.com/2012/05/scrap-your-type-classes.html), where you replace a type class (which is equivalent to a trait in Rust) with a type that represents the behaviour, eg

class Eq a where
  eq :: a -> a -> Bool

-- becomes:

data Eq a = Eq { eq :: a -> a -> Bool }

Instances of the class then become normal values.

instance Eq Bool where
  eq True True = True
  eq False False = True
  eq _ _ = False

-- becomes

eqBool = Eq { eq = f }
  where f True True = True
        f False False = True
        f _ _ = False

A type class constraint on a function becomes a normal function parameter, and type class instances are passed explicitly

notEq :: Eq a => a -> a -> Bool
notEq x y = not (eq x y)

-- becomes

notEq :: Eq a -> a -> a -> Bool
notEq eqa x y = not (eq eqa x y)

The obvious downside is that you have to explicitly pass around these instance values, but the upside is you drastically simplify the language, getting rid of an entire separate namespace, syntax and many typechecking rules.

The problem of having to explicitly apply instances can be alleviated by introducing implicit arguments to the language - this is what Agda does, and is something I’m exploring with my own language, which is aiming to be a simplified Haskell. I’ve written a little bit about the design here: https://github.com/hmac/kite/blob/main/docs/implicits.md

I imagine the tricky bit is going to be when you need to satisfy two traits simultaneously. What comes to mind is a directed workflow, which is simultaneously an executable and a graph.

to_display has a typo:

--- old
+++ new
@ -1,2 +1,2 @
-pub fn to_display(self: Friend) -> String {
+pub fn to_display(self: Friend) -> Display {
  Display(fn(options: DisplayOptions) { ... })
}

Really the only difference is that we manually convert from Friend to Display in Gleam, where Rust already knows how to use Friend as a Display.

You can improve the representation of the “trait record” to get rid of this manual conversion. The result is known as the “dictionary passing” translation of type classes.

Here’s how you you’d translate the Display example (I don’t know Gleam, I’m just making it up based on what you wrote in your post):

// trait Display {
//   fn format(self, DisplayOptions) -> String; 
// }
pub type Display<Self> {
  Display(format: fn(Self, DisplayOptions) -> String)
}

// impl Display for Friend {
//   fn format(self: Friend, options: DisplayOptions -> String { ... }
// }
pub const display_friend : Display<Friend> =
  Display(fn(value: Friend, options: DisplayOptions) { /* use options and value.name */ });

A function that takes a Display-able type gets this signature: fn my_function<A>(display_impl: Display<A>, value: A, ...) -> ....

This also solves hwayne’s comment about using types at multiple traits. A function that takes a Display + Ord-able type gets this signature: fn my_function<A>(display_impl: Display<A>, ord_impl: Ord<A>, value: A, ...) -> .... You’ve gestured in a similar direction in this comment, and I think improving the representation of the “trait record” helps.

This is basically the path that lead me to low-key reinvent ML modules for Garnet, yes. However, “just” implementing a generic type that contains generic functions is not always trivial.

What erlang/gleam do for resource management? How do I not “leak the socket”? Is the following picture correct:

• a resource is more-or-less just a number (eg, nothing prevents you from using a socket after it is closed)
• resources are registered with processes, so, if the whole process dies, resources are automatically cleaned up. Is there a way to send resources between processes? Can I have user-defined resource, or do I need a NIF or something?
• I assume there’s some with high order function which makes not leaking the socket past the close call syntactically obvious? And, in Erlang, it’s wrapped in try/catch/rethrow, while Gleam just doesn’t have exceptions?

What if a function needs its arguments to have more than one trait? :^)

And if you’re dynamically typed, you don’t even need the types 😌

[Comment removed by author]

I do not think Rust would have been that successful without a packaging system, LLVM backend, documentation, concurrent programming primitives, etc. R without matrices as first-class citizens, would also probably not be that successful.

I understand that the author is looking for the most ‘compact’ easily worded explanation of ‘what is a good’ language. I think defining a perimeter of use cases where the most compact definition of ‘expressivity’ applies – would help.