Gleam: a type safe language on the Erlang VM | Hacker News Reader

Gleam: a type safe language on the Erlang VM

gleam.run

325 pointsljlolel236 comments

I'm really impressed by the syntax. I have yet to find a piece of syntax I wouldn't like. Labelled arguments for example are delightful:

    pub fn replace(
      in string: String,
      each pattern: String,
      with replacement: String,
    ) {
      // The variables `string`, `pattern`, and `replacement` are in scope here
    }

    replace(in: "A,B,C", each: ",", with: " ")

FYI Swift did this years ago.

Swift probably did it for ObjC compatibility, and ObjC got it from Smalltalk.

The only part that rubs me the wrong way is,

> The pipe operator will first check to see if the left hand value could be used as the first argument to the call, e.g. a |> b(1, 2) would become b(a, 1, 2).

Optimizing for one less _ typed is a really bad trade-off in terms of clarity here.

I actually agree, this is the most questionable piece. I prefer (and have argued for in JS) Hack-style pipes, where the value "placement" always has to be specified.

That allows arbitrary expressions on the RHS of the pipe, so for example this would be valid Gleam:

pub fn main() { io.println( "Hello" |> (_ <> " world") ) }

Gleam has curried functions by default so F# style pipes make sense imo.

Gleam doesn't have auto currying! Often folks find this (currying) a bit confusing to wrap their head around when learning functional programming and we don't feel like it really affords you much that couldn't already be achieved with just a little bit more work by the programmer.

Applicative builder APIs are the only thing we've found would be much much better if we had auto currying.

Ah my mistake. So this is a deviation from Elm?

I think you are confusing Gleam with Gren (a fork of Elm)?

Gleam did used to have this, but the community collectively decided that it was actually quite annoying in practice to always have to write `_, ` after every function

How does this work if you rename a variable? Does it break all callers?

In this example, the local variables are `string`, `pattern`, and `replacement`, and are implementation details; only the names `in`, `each`, and `with` are part of the public API. Renaming the local variables doesn't break anyone. Renaming the labels would break callers, just as changing the names of keyword arguments in other languages.

Why are there both labels and variable names?

They serve different purposes.

Without labels—i.e., with only traditional positional arguments—the example would simply be a function taking three string parameters:

    replace(String, String, String)

Of course, the documentation should specify which arguments are which, but still at call sites it would be easy to accidentally permute the arguments:

    replace("https://[^/]*", "", url)  // wrong!

(In this case, the problem is exacerbated since different languages/libraries pick different orders here! For instance, the incorrect ordering above is correct for Python's `re.sub`, so it's easy to see how mistakes might arise.)

Labels solve this problem by making the binding explicit at the call site:

    replace(each: "https://[^/]*", with: "", in: url)  // now correct!

(Looking at the Gleam docs [1], it seems that labeled arguments "can be given in any order".)

Now, how does the implementation of this function look? The obvious first approach is to require the labels to be the same as the local variable names, but this often leads to awkward "grammar", because (in the convention of Gleam and some other languages, like those in the Smalltalk/ObjC/Swift heritage) good label names tend to be more like prepositions, whereas variable names like to be nouns:

    pub fn replace(in: String, each: String, with: String) {
        // variables `in`, `each`, and `with` in scope...
        in.split(each).intersperse(with).join()  // hmm...
    }

Now, of course, the implementation can simply re-bind its arguments to new names:

    pub fn replace(in: String, each: String, with: String) {
        let string = in, pattern = each, replacement = with;
        string.split(pattern).intersperse(replacement).join()  // better.
    }

And labeled arguments are sugar for precisely that:

    pub fn replace(in string: String, each pattern: String, with replacement: String) {
        string.split(pattern).intersperse(replacement).join()
    }

[1]: https://gleam.run/book/tour/functions.html#labelled-argument...

Isn't this solvable just by using types and instances rather than just calling top level/static functions? If you have a "replace" function off of String and use a Pattern type instead of a raw string, the compiler will enforce the correct type and ordering.

    val p = Pattern("https://[^/]*")
    val in = "https://google.com/some/path"
    val path = in.replace(p, "") // /some/path

In fact this specific example is solved just by having a dedicated type, for example URI:

    val path = URI("https://google/com/some/path").path; // /some/path

This feels like to me an answer in search of a problem.

For me personally that's the part of syntax I don't like and don't understand the value of.

Generally stems from the philosophy that code is read more than written, and this helps readability.

Does it? Instead of a single parameter you now have two names, and a type info to boot

    pub fn replace(
      in string: String,
      each pattern: String,
      with replacement: String,
    ) {
      // The variables `string`, `pattern`, and `replacement` are in scope here
    }

    replace(in: "A,B,C", each: ",", with: " ")

    pub fn replace(
      in: String,
      each: String,
      with: String,
    ) {

    }

    replace(in: "A,B,C", each: ",", with: " ")

Wouldn't you have replace("A,B,C", ",", " "), which is quite unreadable.

Not if you go the C# way: https://learn.microsoft.com/en-us/dotnet/csharp/programming-...

When argument variable names and labels are combined you have two problems:

1. Labels are accidental. If all arguments automatically create labels then the programmer has not considered and deliberately designed the API. Gleam is designed to make sure that APIs are always carefully thought about and designed as appropriate.

2. Renaming a variable becomes a breaking change. We don't believe that renaming a variable should ever result in a semver major version bump.

> Labels are accidental. If all arguments automatically create labels then the programmer has not considered and deliberately designed the API.

1. Not every code is an API. And APIs exist in multiple languages that don't have labels

2. If you wanted named parameters, you could go the C# way: https://learn.microsoft.com/en-us/dotnet/csharp/programming-...

3. Since Gleam doesn't enforce labels or check labels in any way, it doesn't "make sure APIs are carefully thought out". Labels will be just as random and accidental as parameter names following the whims of the programmer who decides to use them

> Renaming a variable becomes a breaking change.

So does renaming a label.

1. Every class/method/function/whatever declaration is an API, doesn't matter if it's internal or which language it's written. 2. Why do you think it's better? It looks like it tries to cater to everyone, and leads to inconsistent API usage and requires teams to agree on linting rules and use tools to enforce consistent coding standards. 3. It's a tool for _you_ to design good APIs that are clear. Languages without named arguments don't give you this tool.

> So does renaming a label.

In languages without this feature, any renaming breaks the API, unlike the ones with distinct internal and external names. This is not the same.

the idea is that within the function body you would rather refer to the variables as e.g. `for s in string.match(pattern)` than `for s in in.match(each)`

Then call them that.

`replace(string, pattern)` is just as (if not more) readable as `replace(in, each)`.

I was specifically replying to the claim about readability.

It separates "names as public-facing API design decisions" from "names as developer conveniences for expressing intent and clarifying their code".

These are often very at odds. And if you don't want to repeat yourself twice with two identical names... you don't have to.

And unlike Smalltalk, in Swift at least, externally unnamed but internally named is easy (just make the external name _).

> It separates "names as public-facing API design decisions" from "names as developer conveniences for expressing intent and clarifying their code"

How often is this an issue?

> And unlike Smalltalk, in Swift at least, externally unnamed but internally named is easy (just make the external name _).

So, visual clutter for very little gain. IMO

> How often is this an issue?

In our opinion, almost always.

As wikipedia would say, [citation needed].

Having shipped code in nearly two dozen different programming languages, there were very few times when I wanted my internal parameter name to be different from my external parameter name. The reasons are very simple:

- if your function is simple, you just use the params immediately, like in your `replace` example. It doesn't matter what they are called as long as their names make sense

- if your function is not simple, the parameters are usually immediately transformed into something else (mapped to different data, split to different data etc.), and their original name doesn't matter.

So this leaves a small weird case of "somehow parameter names don't make sense for the caller of the function", and I can't for the life of me come up with such an example (the example with replace in Gleam docs is not convincing, to say the least).

Two dozen programming languages shipped in or not, almost no languages support this.

It is something that you start appreciating a lot more once you have used it significantly. It helps a lot with writing more self-documenting interfaces that are legible at a glance.

Another detail I did not mention is that _public names are part of the interface_. This means that two functions that differ only in the public names are distinct overloads.

To give an extremely simple example (taken from Apple's docs):

class Counter {

    var count = 0

    func increment() {
        count += 1
    }
    
    func increment(by amount: Int) {
        count += amount
    }
    ...

}

This starts becoming even more valuable when you have more complex objects, and allows you to move (e.g. on some kind of repository class) mangling of overload names into more readable named argument overloads.

swift has that - it's smart. helps with documentation, and simplifies refactoring. I'm up for any features that reduce changes upstream.

Javascript has supported this for many years.

It definitely hasn't, JavaScript doesn't even have named arguments.

If you pass your arguments as an object they are named and you can rename them. So for all practical purposes that's the same thing.

It doesn't have labelled arguments. It can roughly simulate them using an object, but there's a slight performance cost to doing so.

Things I like about Gleam's Syntax - https://news.ycombinator.com/item?id=38031342 - Oct 2023 (54 comments)

Gleam v0.29 – Gleam gets autocompletion - https://news.ycombinator.com/item?id=36044484 - May 2023 (1 comment)

V0.28 released of Gleam, a type safe Erlang-family language - https://news.ycombinator.com/item?id=35425855 - April 2023 (4 comments)

Gleam v0.25 – Introducing use expressions - https://news.ycombinator.com/item?id=33731871 - Nov 2022 (4 comments)

The Gleam Language Server - https://news.ycombinator.com/item?id=31143792 - April 2022 (1 comment)

Gleam v0.18 Released (gleam language on the erlang vm) - https://news.ycombinator.com/item?id=29464307 - Dec 2021 (1 comment)

Gleam 0.16 compiles to JavaScript - https://news.ycombinator.com/item?id=27538919 - June 2021 (24 comments)

Gleam 0.15 - https://news.ycombinator.com/item?id=27061500 - May 2021 (78 comments)

Phantom Types in Gleam - https://news.ycombinator.com/item?id=26284976 - Feb 2021 (11 comments)

Gleam 0.14 – Type-safe language for the Erlang VM - https://news.ycombinator.com/item?id=26185690 - Feb 2021 (51 comments)

Lean HTTP Server for Gleam - https://news.ycombinator.com/item?id=24265936 - Aug 2020 (5 comments)

V0.10 of Gleam, a statically typed language for the Erlang VM, is out - https://news.ycombinator.com/item?id=23706211 - July 2020 (1 comment)

Gleam: A statically typed language for the Erlang VM - https://news.ycombinator.com/item?id=22902462 - April 2020 (109 comments)

Hello, Gleam - https://news.ycombinator.com/item?id=19686413 - April 2019 (1 comment)

An interview with the creator of Gleam: an ML like language for the Erlang VM - https://news.ycombinator.com/item?id=19547418 - April 2019 (0 comments)

Looks decent. I somehow missed the previous thousand discussions.

I’d love to hear from anyone running it in production.

I have always been BEAM-curious, but never felt comfortable running it in production, as it feels like a big black box, and I’m not confident that I’d be able to diagnose problems as readily as I can in .NET, Go, or Node. I’m not sure why I feel that way about BEAM.

I'm not sure either why you feel that way. The BEAM has amazing tools to debug at runtime and explore/modify your system while it's running.

Yeah you'd need to learn it, but it's like any other tool.

Some comments about the prospect of using Phoenix with Gleam:

https://news.ycombinator.com/item?id=38037082

> I’m not sure why I feel that way about BEAM.

unfamiliarity? Plus the problem of 'nobody ever got fired for running IBM' plaguing your work.

I think it might actually be easier to inspect the BEAM over those other VMs. For one, it is much older and stable. And secondly, the BEAM has a lot of self-introspection features.

I highly recommend the talk The Soul of Erlang and Elixir by Sasa Juric which shows off the essence of the BEAM.

https://youtu.be/JvBT4XBdoUE

Definitely way easier than tracing Node for any type of async exceptions.

I transferred from Node.js to elixir for that reason.

Uncaught throws, hanging errors - while someone much smarter than I could have done it better, I was doing a lot of async/retry of APIs with high failure rate and the BEAM just made it easy.

You can put node into debug mode after launch (SIGUSR1) and remote debug it as well, with sources, which is really incredible. This BEAM demo is rad, but chrome/v8 debug is actually really good too if you take the time to learn all the remote debug tips n tricks.

WHAT. I will catch up with you after the rabbit-hole.

I’ve got massive hopes for things like Bun, but especially Deno’s architecture of message passing, but I’m now humbled by my not knowing that existed in V8.

Since you brought up Sasa Juric, I will second that and also mention their book Elixir in Action. It really helped me get from toy examples to feeling confident running the BEAM in production. This is of course Elixir-centric, but the parts about OTP, inspecting running applications, etc. are really about the BEAM.

Yes, that book is excellent, and I definitely recommend it to anyone new to Elixir. I'd also recommend Joe Armstrong's Erlang book, even if one is eventually wanting to use Elixir.

What is BEAM's version of Visual VM, JDK Flight Recoder or ETW?

Great question, check out Erlang’s “Observer”, it’s incredibly powerful, one of my favorite parts of the BEAM :)

Thanks.

To extend, the answer is the BEAM itself. It ships with these tools built in.

From the whole zoo of system probing stuff or the downright amazing dynamic tracing.

Have a quick look at https://www.erlang-in-anger.com/

Which is also available in JVM and CLR, with amazing graphical tooling, which was the main focus from my question, hence the examples.

In my experience... Nope it is not really. Not to that extend. But sure i get you.

If you compare running a monolith on a singel server then you might be better off diagnosing problems in .Net. Though I think that is uncertain.

If you are writing a distributed system with plenty of microservices BEAM will be magnitudes easier to debug if you write the same system in BEAM native

This hits the mark for me, good type system, backed by Erlang and BEAM, access to Phoenix live view, but doesn’t have (imho Terrible) ruby syntax

As someone who loves ruby syntax, I'd be very interested to hear which parts of it you don't like.

I haven’t used Elixir but I used Ruby as my main programming language for a few years and my biggest complaint with Ruby syntax is decision fatigue. There’s almost never a single clear and obvious way to do something. Overall I find Ruby syntax to prioritize cutesy aesthetics over practicality.

If you use Elixir for a while you may find that there is a lot more consistency, and almost no ‘cutesy’ code around. Elixir’s syntax only looks a little like Ruby at first glance.

Yeah, as a seasoned Ruby dev I found the "similarities" between Elixir and Ruby to be surface-level. They're very different languages. Even the syntax isn't that similar once you get past your first impression.

But don't listen to me - take it from none other than José Valim, Elixir's creator:

> Folks tend to understate the influence of Erlang and overstate the influence of Ruby on Elixir. … Ruby did influence the syntax and the names in the standard library, but the latter was also done in a more "democratic" fashion: I would look into Ruby, JavaScript, Clojure, Haskell, and choose a name that was common and closer reflected the semantics that would fit Elixir (for example, the term "protocol" come from Clojure).

https://news.ycombinator.com/item?id=36604054

That’s encouraging to hear.

> There’s almost never a single clear and obvious way to do something.

You hit the nail with this one

"end" doesn't help.

The ambiguity caused by optional elements is what bothers me most. For this reason Ruby doesn't even have first class function calling syntax, since you are forced to use invoke on block objects.

What’s wrong with Ruby syntax?

One day humanity will recognize that people have divergent tastes in programming languages syntax that have no obvious rational basis.

Me curly brackets, you no curly brackets. Etc.

Today is not that day.

I was wondering if it's Hindely-Milner, and yes it is according to this interview:

https://blog.lambdaclass.com/an-interview-with-the-creator-o....

I browsed the docs and found no mention of OTP. I might have missed it but it would be strange to have a language on BEAM with no native interface to those modules. I looked for examples of supervision trees and gen servers.

OTP is a work in progress available in the gleam_otp [0] package, supplemented with the lower level gleam_erlang [1]. Or you can call OTP things manually with FFI.

[0] https://hexdocs.pm/gleam_otp/index.html

[1] https://hexdocs.pm/gleam_erlang/index.html

https://github.com/wmealing/gleam-otp-design-principals/blob...

This is what I wrote regarding using otp in gleam. One of the issues I'm working on next is to send typed messages to processes, which has me a little stumped.

At the moment the typed channels work, you can't register () a channel or a pid.

I will likely continue working on this document once I have my current project completed.

They seem to have rewritten/wrapped OTP, but it's not production ready. https://github.com/gleam-lang/otp

YMMV, but a BEAM language without OTP severely limits its appeal and usability.

It is being used in production by a good number of people, and the webserver made using it is faster than Cowboy, the most popular Erlang webserver.

All OTP is usable from Gleam.

Not sure I understand then, the OTP library says "This library is experimental and will likely have many breaking changes in the future!".

So you can use untyped OTP as you would from (say) Erlang?

I really hope gleam takes off. We need more typed scripting options.

You could use F# for that purpose.

Does F# compile to distributed Erlang?

Not practically.

There are some one-person attempts at compilers from F#/OCaml to BEAM, but they haven’t seen an update for some years.

Caramel is a very similar language (ML dialect) that builds for BEAM.

https://caramel.run/

No updates on GitHub since Aug 2022. Isn't it abandoned?

Supported and battle-tested OCaml or StandardML for BEAM would be great, of course. I'm waiting for something like this for years.

I want something more like rust or typescript. Not Haskell.

Then F# it is. :)

Rust was partially inspired by F# and OCaml and actually had a much more ML-like syntax early on. Probably something similar goes for Typescript. And actually, the same for Gleam as well.

F# doesn't really relate to Haskell at all. They are very different languages. F# is a multiparadigm language that easily supports concise code in the imperative, OOP, and functional styles.

It sounds like you maybe don't know much about F# if you think it's like Haskell, which is okay. But that's also why I would recommend checking it out.

F# is not Haskell at all. If you want to write non functional code you can. It's functional first but it has side effects, mutable variables and a host of features you get in other languages. I really recommend trying it.

I use ReScript for this. Bindings for node are very complete and for deno they're enough for the most common uses.

+1 to this.

Love Rust and everything about it.

However, to script something small/casual I would like all the rest of Rust but with automatic garbage collection, without having to worry about lifetimes.

Mmm... Erlang isn't particularly good for scripting. It has an elaborate deployment process. It doesn't like OS interfaces very much, and usually tries to offer alternatives, which are often better designed, but it also means there's a thick layer between you and the system you are scripting. While Erlang support for native code is a lot better than, say, in Python, it's better in terms of quality of the output not in terms of how easy it is to accomplish. In scripts you rarely care about quality or generalizations.

I don't see how working with types in scripts would be helpful. To me this looks like a bad idea. Everything being a string is a very valuable feature of Unix Shell. Once you have to spell out types interactively your life becomes a misery. I had similar experience having to do some testing for a mostly Linux-based product on MS Windows (an iSCSI portal that I needed to check if the MS side can connect to).

Using PowerShell is like talking to a very pedantic and a very stupid army bureaucrat, where each time you speak you have to define every word you use afresh, declare the titles of all people involved in a conversation up-front and in the end, all while being unable to connect two obviously related pieces of information because the said bureaucrat has no folder that can contain both.

So, IMO, Erlang or any other Beam language would be awesome for infra automation, and it only gets better the bigger is the organization that infra is supporting. I'm not sure there's any benefit to having ML-style explicit typing in a Beam language though. To explain this better: in the times Flash was relevant, AVM -- Flash' virtual machine was written in such a way that it had to perform runtime type checks almost every other instruction. If you could prove types statically (which Haxe did), then you could generate much tighter bytecode which lead both to smaller memory footprint and somewhat faster execution.

I don't think Beam works in the same way. So, being able to statically prove something about your code doesn't give you the same kind of benefits. And the remaining benefits could be eclipsed by the effort necessary to support the code containing type assertions (i.e. the extra testing that you need to do to assure the type assertions are correct, the increased refactoring cost and valid functionality prevented by lack of insight on the part of the programmer writing type assertions might not be worth the correctness guarantees given by these assertions).

If this piqued your interest you might also be interested in: https://github.com/leostera/riot

Gleam is written in Rust and is a nice example (besides Rust itself) of what it looks like to write a language in Rust. By my own tracking (https://github.com/alilleybrinker/langs-in-rust) Gleam is one of the most popular languages written in Rust and is one of the few top languages in that list which isn't a reimplementation of an existing language!

I feel like making programming languages is an area where Rust can really make use of its advantages without the commonly cited pitfalls. You won't be dealing with any I/O other than filesystem APIs (outside of making a standard library or something), so you can entirely avoid needing to decide whether to use async or not, and you can go pretty far just using value types and copying without it being a likely performance bottleneck. Most languages won't use much concurrency in their compiler either; Rust itself parallelizes builds per crate with Cargo, which invokes rustc separately for each compilation unit.

I'm sure some people might read all this and conclude that they might as well just use OCaml or Haskell, and those are really good languages for compilers too! The tooling and ecosystem make Rust more appealing to me personally though, and I suspect that there are probably others who would find Rust's ecosystem a bit more approachable as well.

Modern compiler tooling that supports IDEs are almost all incremental, so all that async machinery and multithreading can be put to use there as well.

I think Haskell or OCaml would do a better job on the ADTs for a parse tree. When doing this, I found Rust's enums... anemic... and got very annoyed by the awkwardness of having to Box recursive types. I was reaching for the ability to continue to be able to pattern match on nodes while attaching common attributes (line numbers, etc.) and ended up having to bury everything 1 level deep in a struct which ended up feeling awkward.

That and Rust's iterators are terrible at introducing ownership agony.

In any case, I've ... done it (https://github.com/rdaum/moor/blob/main/crates/compiler/src/...) but can't say I liked it.

I do really like "pest" as a parser generator though. In general, yes, the Rust ecosystem is bigger/richer, and growing.

You are not wrong on that level, i have been slowly writing a language in Rust anc all these point are deeply felt.

And yet... The Rust ecosystem win. Easily. For a simple reason.

Salsa. Oh and also clap. Lsp bindings. Ungrammar. Miette. Clap. Parsers. Etc

At every level the Rust packages are far better and allow to drastically reduce the cost of building this stuff.

Haskell has equivalents to all of those libraries, and much more. And they are probably easier to use and more powerful.

Can you link some of those libraries? I’ve always found it harder to find well-maintained libraries that solve compiler problems in Haskell as opposed to Rust.

I spent 6 months exploring the Haskell ecosystem for these. The answer is no.

They are nowhere as easy. At the very least because their documentation is usually non existent or non comprehensible.

> Rust itself parallelizes builds per crate with Cargo, which invokes rustc separately for each compilation unit.

Rust’s frontend now has support for running in parallel on nightly (they haven’t announced on the blog yet). But your point stands, Rust got pretty far all these years while keeping things simple and single threaded.

Are you seriously touting "make -jN" as an amazing rust benefit?

A side note:

There are a lot of new languages coming out these days, which I find interesting and positive. It gives hope for evolution and better solutions to come along.

A problem is that on the surface they have similar syntax and keywords.

I can get confused as to what language I am programming in since some syntax nearly transfers between more than one programming language.

There are of course differences, and those differences can be profound which is what gives us a richer eco system but my brain gets confused by it.

and you never know which party you're trusting when you download those thousands of unvetted code into your build dependency

Can I write time critical functions in Rust and make it available to gleam as a module? This would be an interesting way of building a distributed framework (e.g., on a cluster for scientific computing like ML) in rust.

Yes, the BEAM VM allows you to write native code in a few different ways and call it from BEAM-native languages. For Rust there is a library called Rustler that simplifies the process a lot.

Nice! Thanks

To expand somewhat on the other comment. The experience of writing such functions is quite different if you have ever done this for something like Python.

Processes are central to how Beam works, and you would have to incorporate this notion into design and execution of your bindings when interfacing with Beam from native code. I.e. you'd have to consider that the scheduler needs to be able to suspend / resume your function, think about how work can be done in small time slices, preferably w/o blocking and w/o starting own processes or threads.

If you are interested in practical guidance, search for Erlang port drivers and NIFs. Often times when interfacing with eg. Python from native code, you'd run into marshaling problem. I.e. when you need to pass large and/or structured data to the native code, you'd have to do a lot of packing and unpacking of Python objects before you get something usable out of them in the native land, similarly, the other way around.

Erlang's ports are designed with some idea about how to deal with this problem. NIFs are intended for simpler things, where continued / stateful communication between two worlds isn't necessary.

Gleam is awesome

It really is. A typed BEAM language (that also compiles to Javascript), a fantastic community, and a growing ecosystem. I’m really excited for the future of Gleam!

Gleam is a fantastic language but I didn't see much about testing apart from a very small package called gleeunit which is a binding to Erlang eunit. If I don't know anything about Erlang, how do I do tests in Gleam? I need some more guidance on this.

Gleeunit also works on the JS target so you can run tests on Node.js (if you're targeting JS).

Gleeunit seems a bit sparse. I just see a few functions. For example how do I do mocks? Is this the the whole testing story assuming I am not targeting JS?

Mocks are deliberately not supported by Gleeunit as I (the maintainer) believe they are strictly worse than using dependency injection, and often result in dramatically lower quality code.

Fair enough. In your opinion, is Gleeunit sufficient as a testing framework for Gleam or is it a work in progress which is also understandable as the language is still relatively young?

At a glance the type system is quite barebones and nominative.

I'd like to see Gleam add support for structural types and maybe set theoretic [1]

[1] https://arxiv.org/abs/2302.12783

For what purpose? Is Gleam today unable to do things you’d like to be able to do?

Gleam is looking to be a nice alternative to Rescript.

The docs are a little sparse on this (being initially focused on BEAM), but the discord & community is very helpful which makes up for it.

It's a very neat and well thought out language.

related: what is the state of the Erlang VM in Wasm?

So no one is disappointed gleam dropped function overloading, that was one of my favorite parts of elixir

Can anyone comment on Gleam's type system? Is it similar to Haskell's?

No, it is not. It has no plans to introduce type classes and allows for impure (effectful) functions. It is perhaps most similar to OCaml.

Haskell's is much deeper but Gleam gives you algebraic types, generics and type aliases.

I believe Gleam offers deeper pattern-matching facilities. That is of course not the type system, but feels closely related to me.

I know a company that has built their entire technology stack on some Erlang VM based language.

There was really no reason to do so at all - it's an ordinary company building an ordinary application. But some CTO or dev lead years ago thought it important to use whatever the fancy tech of the day was to build a fairly ordinary business application.

But now they have trouble hiring people because there's a tiny pool of people who know that language. And it is years down the track and all their technology is built with whatever that language/framework is - too expensive to easily bail out, but probably necessary anyway.

In 2023 you've got to have really good reasons for not using C#, or Java, or Python, or TypeScript for building your web project. Maybe Golang - it's getting some good traction in the DevOps space.

If you make decisions about technologies and this latest thing appeals to you - maybe use it for your personal projects. The CEO has employed you to make responsible decisions not play toys.

I hire based on ability/intelligence, not knowledge.

>> I hire based on ability/intelligence, not knowledge.

Well, yeah that's really your only choice if the experience you need is not easily available.

Don't tell me, you are the guy who puts in the not mainstream technology and needs to defend that with justifications such as "when we use (non mainstream technology X) we get super motivated job applicants because anyone with an interest in non mainstream technologies is inherently passionate and interested".

That's not a sound hiring strategy.

And you are the guy who left Visual Basic, COBOL, Perl, and FORTRAN off their "obviously safe choices for hiring in the future" list, despite them all having once been perceived as such.

These inconvenient counterexamples blow up the entire thesis. In practice, the "safe choice" for longevity is only evident in hindsight.

If anyone is hiring for TypeScript in 2050 I'll eat my hat

I'm in sympathy with your main argument, but given that people still, in 2023, hire for COBOL, a language made in 1959, makes me think you'll be eating your hat.

Notwithstanding that I'm effectively forecasting the decline & fall of TypeScript as javascript-flavour-of-the-month, note that I shrewdly also granted myself the better part of three decades to launch an edible headwear startup

Most of the perceived value that Typescript brings will probably fade once js gets type annotations [1], though Typescript will always have more advanced syntax and capabilities.

There are interesting discussions about Typescript becoming more of a run-time type checker, which would be opt-in and have significant performance penalties, but would give more guarantees of type safety.

[1] https://github.com/tc39/proposal-type-annotations

This sounds fun until your entire stack is on Perl in 2023 (which, is fine-ish when your CTO was the perl project lead). But then you have a bajillion dependencies that aren't really updated anymore, you end up owning most of the Mail::Toolkit libraries, etc. and nobody really knows perl that well. I mean, a lot of us can jimmy around in Perl, but of the real Perl Gurus in the world, you will end up hiring 50% just to keep your company going

I think I'm rather able and intelligent, but there are just so many footguns in golang that my team doesn't have the knowledge to avoid.

Just curious, what are some of those footguns your team is encountering? Only thing that comes to mind is the somewhat tedious error handling imposed by the language. Which language would you say had _less_ footguns than go? Or was this sarcasm and it went straight over my head?

I guess I am just bad at golang.

Loop variable pointer and nil struct is not nil interface are the two that continue to hound us.

Also:

type MyError {}

var _ error = (&MyError)(nil)

errors.As(err, &MyError{})

---

Panicking because it needs to be &&MyError{} instead is a similar gotcha.

"Ability" by itself is a bit vague here, but I will say that having a proven trackrecord in their ability to learn is something I specifically look for in a candidate. Not only learning new tech, but also learning from mistakes and experiences over time.

However, I don't think raw "intelligence" is the right metric for hiring. Unless you specifically mean emotional intelligence, which can curtainly contribute to improving communication skills on the team.

I've also found that when hiring someone with mostly expertise outside your current stack it's critical to provide good feedback loops and mentoring early on so they can "get up to speed" and contributing valuable, idiomatic code as fast as possible without feeling as though your entire onboarding experience is trial by fire. This mentoring takes up extra resources and is a net drain on your team in the short term, but pays off in the long term.

It’s very easy to teach a good developer a new language. We use Nim for embedded firmware development at my work, and have been expanding our team. It’s been simple: hire good C/C++ devs who are interested in learning something new but related, and teaching them. Takes about two weeks before they’re comfy, sometimes less (python experience seems to help a little due to some surface level syntactic similarities)

What if you can't find an expert to teach the other developers?

You are hiring too late.

So if you end up joining one of these companies, run for the hills, no?

Where did the rest of the code come from, or who made the decision to start that way? They should at least be able to spearhead it. Obviously it's different for tiny organizations, but generally, if someone inexpertly made architectural decisions without building the institutional knowledge to continue without them, the language they chose will just be one of many big problems.

People who build things are not necessarily able to teach things. These are two different skill sets.

And those people shouldn't be in executive roles, even in smaller organizations. Being able to mentor people is a basic management skill and is why blindly making engineers into dev managers based on seniority is idiotic. If you have someone incapable of mentoring people unilaterally making those decisions without a counterpart that can, that's not a problem with the stack-- that's a problem with management that will manifest itself in countless other ways.

You are describing the honeymoon period of choosing a non mainstream approach.

In time, it starts to become clear that this non mainstream thing hasn't really picked up the steam to become mainstream. Your developers are starting to realise there are no jobs advertised for Nim, so this isn't good for their career. Then the Nim project starts to stagnate. But you've written so much code in it that it's hard to turn back. But the person who decided on the non-mainstream technology - if they are still there they are defending it to avoid losing face. if they have moved on and left you the problem then the new CTO is explaining to the CEO the bind the company is in. Time to start planning the budget for a complete rewrite in the language that is standard practice for the industry for this sort of thing.

At this point, C++ ain't looking so bad for this sort of project.

You are describing programming as if the language being used is the primary work skill and as if devs are somehow “trapped” by the language they happen to be paid to use at the time.

I live in a very different world and over the past 13 years have been paid to write Obj. C, Python, PHP, CSS, JS, Ruby, Elixir, Golang and a small amount of Rust. All are still useful skills that I’m likely to encounter again.

In a few cases, I used languages that later lost steam (Flash, CoffeeScript and Elm). It wasn’t a disaster, though. I just took what I’d learned and moved on.

Whereas not a single shop has gone down the road of picking some Javascript framework which stagnates or significantly changes over major versions and requires a lot time/money/effort to migrate.

These types of problems are pretty common.

We’re multiple years into it lol

The point of Nim is that we’re exercising all of their C and C++ skills as one of its venefits is being able to leverage existing drivers and modules for peripherals. Nim is C, at the end of the day.

I’m not some fresh faced 20 something, I’ve got nearly two decades in industry at this point, and I just frankly disagree with your assessment.

>There was really no reason to do so at all

Please - I can do a ton of stuff in Elixir without having to reach for some weird/paid third party service. https://twitter.com/ryanrwinchester/status/15806523244057763...

Now with Liveview I can even ditch the grotesque React toolchain entirely.

Also, in my experience as defacto CTO of a unicorn YC company (Papa), hiring was not insanely difficult. I hired about ~45 engineers Great Ruby/Go devs translated pretty easily into Elixir after minimal training. The language is beautiful and simple.

Agreed, it’s been so easy to onboard people onto Elixir we’ve just looked for raw talent knowing they’d be up on Elixir quickly.

As long as you have one experienced elixir engineer to guide the people learning I think it’s easy to move fast.

You're posting on a website built in its own Lisp variant and inhabited by people who think it's fun to write compilers.

This is completely insane because at the same time go on any elixir forum and you will find lots of highly talented developers looking for jobs.

As usual the problem is that leadership has no fucking clue how to hire.

>> go on any elixir forum and you will find lots of highly talented developers looking for jobs

Sure, in a downturn after a year of waves of layoffs, and maybe in San Francisco, but the non-mainstream tech will live longer than a few economic employment ups and downs.

Last 2 companies I’ve worked at have been elixir shops. Both of them had no trouble at all hiring elixir devs. At my previous company we hired close to 30 in a 6 month period in 2021. At my current bigco job we had more elixir devs pass the interview process than we have open slots (and we had a ton of slots).

I’ll also add that over many years of doing this, the elixir devs I’ve interviewed tend to be far above average, which makes up for the lower number of candidates.

If you want to hire thousands of fresh grads each year and don’t want to spend any time on training, sure go for something they teach in school.

No it's been pretty much that way for years.

i've shared this story on here before, but years ago i worked for a startup where we had a janky homegrown distributed system cobbled together from a mix of python, rabbitmq and state stored in postgres tables. four of us, two senior and two junior engineers, decided to see if we could learn erlang and build a more coherent and well-engineered replacement for it. it took us four months, starting from never having used the language, to learn our way around it and set up a proof of concept that was both more performant and more stable than the existing system. and this was all while doing our regular work as well. erlang is an extremely simple language to learn and become productive with, especially if the task you're trying to do fits the grain of the language and beam environment.

(ironically, the erlang solution never went anywhere because management decided they did not want to take a chance on a lesser-used language. but from a getting employees standpoint it's perfectly feasible to hire people who are simply good engineers in whatever language and give them a month to learn erlang.)

Are you talking about WhatsApp? Discord?

I can't speak for Discord, but at WhatsApp, we chose Erlang for a very good reason: ejabberd is a very clear base to start with if you want to run a chat server, and ejabberd runs on Erlang. At least Facebook, WhatsApp, Riot Games, and Discord have done it, and I think there's plenty more.

While I was there, I was the third most Erlang knowledgeable server hire, because I rememebered Ericsson open sourcing it decades ago, but hadn't used it before. We hired two people I can recall who were experienced with Erlang (well, and a client developer who used Erlang in school but didn't use it for WhatsApp).

This wasn't a big deal, Erlang is a small language, and smart developers pick up enough to be useful pretty quickly. There's a learning curve for distributed systems challenges, but IMHO, message passing concurrency makes a lot of things a lot simpler than shared memory concurrency, and you can get a lot of good work done where the new person does the bulk of the work and a mentor helps with distributed systems bits.

Anyway, Facebook chat decided to abandon Erlang for hiring reasons, and transitioned to a C++ server, and I don't think it was that hard; Erlang wasn't some boat anchor holding them back when they decided to switch, like the GP suggested. Even if it was, that's kind of an amusing complaint: this thing is so awful, and we can't even replace it because ??? it's too good?

> Even if it was, that's kind of an amusing complaint: this thing is so awful, and we can't even replace it because ??? it's too good?

Obviously they were suggesting that rewrites/changing your tech stack for a project is expensive and not everyone has the luxury to do it. Facebook does.

>But now they have trouble hiring people because there's a tiny pool of people who know that language

>In 2023 you've got to have really good reasons for not using C#, or Java, or Python, or TypeScript for building your web project. Maybe Golang

In my country, very few people know Go, so we hire devs without requiring them to know Go - we teach them the language, and after a few weeks, they already feel pretty confident with it. In fact, most devs are actually interested in trying something new, some new language.

Maybe your employer's problem is that they are only looking for CVs where the language is mentioned as a keyword, and don't consider anything else?

There's always a good reason not to use C#. That's actually the number one language that is crossed out of the candidate lists due to the company behind it and very "uneven" platform support.

As for using a unpopular language. My (mostly untested) conviction is that if this unpopular language is still popular among an albeit small group of programmers, it's a blessing. While hiring is difficult, you get much higher quality human resources. You get to enjoy working with smart people.

I've known a company whose business was to track real estate values. They had a Web site and some backend that did somewhat complicated statistics trying to predict prices or rent based on all kinds of factors they aggregated. A lot of the functionality of the backend was in scraping local news, city authority documents etc.

They wrote everything in Clojure (including front-end, which was Clojure-script). Great people, created a great, useful and successful business.

I've worked in companies early adopters of Go and Rust. It was a great experience. I've learned a lot during that time from my coworkers. I also briefly worked for a company whose main product was written in D. It was another great place to work in terms of quality of human resources and the quality of code I had to work with.

> People from around the world, of all backgrounds, genders, and experience levels are welcome and respected equally.

Except that if you don't agree with the authors political opinions:

> Black lives matter. Trans rights are human rights. No nazi bullsh*t.

Yet another project run by people who shoves politics into unnecessary spaces. I would never dare to use a project run by people that pushes their personal agendas on their website for a programming language.

I do believe that there is only two genders, man and female. Am I a nazi now or what do Gleam mean by this message? Don't use projects like this.

Personal projects are driven by personal agendas. Also water is wet. If you don't like it and you can't find the motivation to build something better, perhaps that's because your agenda doesn't drive you enough.

Why would I build something better? I am maybe not in the business nor have the interest of making a programming language.

I don't really care that they have this message (except that I find it to be pretty insulting), I just think it's an unnecessary thing to do if you want people to use what you've made. I won't and I will encourage people not to use it just because of this.

> I don't really care that they have this message (except that I find it to be pretty insulting), I just think it's an unnecessary thing to do if you want people to use what you've made. I won't and I will encourage people not to use it just because of this.

Sounds like you care a lot if you're gonna actively discourage people from interacting with the project.

> Sounds like you care a lot if you're gonna actively discourage people from interacting with the project.

If someone would ask me in the future if I heard anything about Gleam, yes then I would actively discourage people from interacting with the project. If I read about it in a positive manner in the future here or in other forums, yes then I would probably write a comment warning people about it.

If you think that is caring a lot then I care a lot. I don't consider that to be caring a lot though.

But you're also inserting politics in a technical discussion. The real issue is not that someone is putting politics in a technical place, it's that it contradicts yours.

If I say I'm interested in using Gleam and you tell me there's only two genders, I do not see how that makes you any better.

> But you're also inserting politics in a technical discussion.

The discussion is about everything about the language not just the technical aspects so no I am not.

> The real issue is not that someone is putting politics in a technical place, it's that it contradicts yours.

No I wouldn't care whatever political agendas the author hadn't he put it straight on the website calling me a nazi.

> If I say I'm interested in using Gleam and you tell me there's only two genders, I do not see how that makes you any better.

Why would you assume I would say anything about genders if you asked me about gleam?

I would say it's run by political extremists that use their programming language to push political agendas and that due to that, they are probably untrustworthy. I would say I would refuse to use it because of that but encourage you to make up your own mind.

> Why would you assume I would say anything about genders if you asked me about gleam?

Because nobody asked you about Gleam and you still brought up gender. And then you said you would continue to bring up politics whenever the language came up.

> I would say it's run by political extremists that use their programming language to push political agendas

I find it comical you think a programming language can be used to push a political agenda. That's got to be the least effective way to spread political ideology I've ever heard. You make it sound so sinister.

> No I wouldn't care whatever political agendas the author hadn't he put it straight on the website calling me a nazi.

Nobody called you a Nazi.

> Because nobody asked you about Gleam and you still brought up gender. And then you said you would continue to bring up politics whenever the language came up.

No I read on the website hacker news, someone submitted a link to the language website. The website brought up gender and centered in in the page about community guidelines.

> I find it comical you think a programming language can be used to push a political agenda. That's got to be the least effective way to spread political ideology I've ever heard. You make it sound so sinister.

Well it is because it is sinister imo. Maybe it's ineffective but it's still there which is kind of undeniable. A lot of technical projects have had political agendas on their websites. React, Go, Node.js, Emberjs etc etc. I kind of get it and support the anti-war stuff for Ukraine but for normal everyday politics that's mainly american? C'mon.

> Nobody called you a Nazi.

Yes the website kind of did, since I don't adhere to the ideology that they do.

Stop being so god damn naive dude, it's ridiculous.

> I kind of get it and support the anti-war stuff for Ukraine but for normal everyday politics that's mainly american? C'mon.

Right, so it doesn't align with your politics.

> Yes the website kind of did, since I don't adhere to the ideology that they do

This is a pretty conservative website and even most people disagree with you here, which is why your comment about "these people" was removed.

> Stop being so god damn naive dude, it's ridiculous.

I'm just gonna end it here since you're clearly looking for reasons to get offended.

> Am I a nazi now or what do Gleam mean by this message?

There is a dot there, so they're separate issues.

Reply on news.ycombinator.com