All you need is data and functions

I disagree with the post. The goal of traits, or any similar mechanism in other languages, is not to implement a given functionality. It is to describe and enforce a common way and API to expose the functionality.

To take the example given for gleam, there is nothing enforcing that the conversion to string is called to_string, what are its arguments, how formatting works. So you're left to just-so compatibility for each type. They only happen to be the same by accident, and nothing enforces consistency.

Programming language and code in general is about communication between programmers. When I design a trait, or an interface, I'm telling everyone else what are the requirements.

This is a bit of a rabbit trail, but something I’ve been wondering about lots of these new languages. Who uses them and why? I’m genuinely asking here. I have a hard time imagining going to a team or customer and saying “c#/go/java/python/javascript are the wrong approach for this project. We need to all learn this new language and use that instead.” Don’t get me wrong: I’m glad people are innovating, and I get that personal curiosity and growth might be good reasons to build a new language. But I just wonder about the real world uses and actual stories behind new and lease known languages. Why did someone create Gleam and how is it being used in production today? What are the long term goals for it? What would be the argument for using it on a company’s projects?

I've just built a piece of software and realized it would be a lot better if it could save/restore its state when it restarts. I already have all state isolated in state objects, but they're not plain JSON, they contain instances of classes and things like that. But in virtually all cases I could replace classes with TypeScript interfaces (i.e. just use pure JSON and still get the type-checking benefits).

There are some exceptions where classes need to be instantiated, and I'm thinking, instead of writing a bunch of ser/de, I can just make them static, Replace-All `this` to `self` and add a `self` param. Boom, suddenly save/load is a simple as JSON.stringify() and JSON.parse()

Then I realized I'd reinvented C (plain old data) and Python (explicit self param). Nothing new under the sun!

> Instead of a trait, just make a type that implements the generic behavior you want, and then write a function to convert your data-type into your trait-type

Well, yeah, obviously, when you have a single implementation of a trait/interface, then you can do away with this additional indirection, sure. But what if I have vastly different types implementing the same trait and I want to collect them all in a single list?

> If you need some data-type specific logic, then pass around functions as necessary (usually from your conversion function).

That... basically amounts to manually bundling values of the concrete type together with the implementation of trait and then passing them around together (also manually), isn't it?

I mean, on one hand I get the message: you don't really need any fancy type systems, having integers and bytes and arrays of integers and arrays of bytes for types, ability to declare constants, global and local variables, and functions (not closures) is quite enough already to implement anything. Structs then can be emulated either as short integer arrays of fixed lengths, or with SoA approach: all enums are just integers, and pointers are also but an integer index in some globally known array so yeah, there is nothing much else you need to store in a struct's field.

But let me tell you, programming this way is not very pleasant if you've spent majority of your life writing Python or Haskell. Having common patterns of data and code organization baked straight into the language is nice.

As usual, simplicity of this type basically means making the programmer write the boilerplate that the compiler could generate for you. The complexity has to live somewhere, and with "simple" languages, it lives inside your own source code, and that of each of your libraries, instead of living inside the compiler.

I'm not sure why this appeals to so many people, but still: it clearly does. So, best of luck to the Gleam team, I hope it lives up to your needs and desires!

I don't know Gleam at all but doesn't this beg the question here...

    |> iterator.from_list()
    |> iterator.map(Friend)
    |> iterator.map(friend.to_display)
    |> print_things_from_an_iterator()

This only prints Friend types. How would you loop through a collection of several types and display them? In other languages they could all implement the interface. Perhaps you could have several to_display functions that handle each type but I'm not sure that's valid in Gleam. It would need runtime type checking. In this example to_display is a member function.

It looks like the author is confused about or unaware of the difference between static and dynamic dispatch. Their Display and Iterator types are really just vtables; the correct comparison to Rust would be the `dyn Display` and `dyn Iterator` trait objects (which are types).

In some ways, in Haskell, type-classes are passing around "dictionaries". You can implement a similar pattern as in Gleam, in Haskell, by explicitly passing around those dictionaries. In Haskell it makes for some pretty ugly code though.

But type-classes get a dual use also as constraints for parametric polymorphism. This gives you some more immediate feedback from the type checker and also lets the programmer extend type checking with their own rules.

Never the less I sometimes use this pattern of grouping functions together into a record along with pointers and handles they need to shared resources to make running those functions, passing them around, and cleaning them up easy and explicit -- when it is called for.

From experience I find I doubt that we tend towards complexity or enjoy writing complex code. Most people I know find complex code takes quite a lot of effort to write, understand, test, and make useful. The majority of people I've worked with want to write simple, elegant code and find joy in understanding a problem. It happens that some times we either judge the problem to be more simple than it is or we can't formulate a succinct specification of the solution. This leads to code needing some solution to the inherent complexity in the former case. And in the latter it means we don't know what we're doing and are getting lost in the weeds. In both cases a liberal application of good-old-fashioned thinking tends to do the trick.

When thinking is insufficient it always helps to have coding guidelines, mentors, and access to experienced colleagues. The last ditch effort of course is searching the good, old Internet.

I usually say my favourite abstraction is the function. :) It's one we use a lot.

I use Rust, C, Python.

I've realised a long time ago that all of programming essentially consists of two things: data, and procedures that operate on that data. Everything else is in function in one or both of these two things.

For example - functions and methods organise the procedures in smaller, more manageable (from human perspective) chunks, types formalise and limit the data to make them easier to transfer and organise, and classes (are supposed to) do both.

Well a function is like an interface (or trait as newer languages like call them for some reason) with one member. The problem the article seems to totally skip over inexplicably is that the point of an interface (trait) is when you have more than one implementation.

Rust's Display is superior to everyone else's To string precisely because it is stream-oriented rather than allocation-oriented. Allocating f-strings are a major language smell.

Might be over-simplifying. Seems like F#'s type system did this.

Like many good posts, this one got me thinking, and elicited a visceral reaction.

The idea of traits as types is potentially interesting from a pedagogical perspective, since it gives us another way of thinking about things. But whether it is simply analogous or is in fact homologous is the key question: If simply analogous, then we need to understand the limit of the analogy, where it works, where it fails. If homologous, then we have a powerful tool to draw upon, much like how mathematicians can switch analytic techniques equivalent over whatever category they are working with, or how physicists change coordinate systems to make the math and understanding easier for particular types of motion.

I tend to think it is simply an analogy, but I don't yet know where its limits lie.

> 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.... Instead of a trait, just make a type that implements the generic behavior you want, and then write a function to convert your data-type into your trait-type.

Aaaand here's where my gut twists. Why? Why would you do that? Why would you ever do "instead of... -> just" where the compiler will do it for you?

Twice in that quote the author espouses writing more code because reasons, and, honestly, I don't think the reason is any better than "Gleam doesn't haven't traits and we're all OK with doing the extra work".

That's fine. If that's how someone wants to work, and if their code works for them and is as maintainable as they need it to be, great! I cannot gainsay that.

And I'll note that for someone who hasn't yet grokked generics and traits, the Gleam code may be more readable, because things are more spelled out.

Sort of reminds me of my early Javascript, before I got comfortable with promises, composition, lambdas, and a few other things: Very readable blocks of code, often many lines long, that I would now replace with a single line.

But once one understands traits and constraints, one can write very powerful, and, thanks to how Rust works, safe code that other (oh, I do have to use that term? oh, ok) Rustaceans will grok quickly, code that will likely also be performant.

If I can save myself time and screen space AND make it clear to others what's happening AND make it safe and performant, I'm in.

(I'll just remember to add comments as to why this is a single line and why that isn't.)

(EDITS: Typos)

Well, traits is basically an interface, and an interface is implemented by a type, so yeah.

Aside: Can someone please tell me the name of the coding font in the OP?