Coming from Elixir, I gave Gleam a try for a couple of days over the holidays. Reasons I decided not to pursue:

- No ad-hoc polymorphism (apart from function overloading IIRC) means no standard way of defining how things work. There are not many conventions yet in place so you won’t know if your library supports eg JSON deserialization for its types

- Coupled with a lack of macros, this means you have to implement even most basic functionality like JSON (de)serialization yourself - even for stdlib and most popular libs’ structs

- When looking on how to access the file system, I learned the stdlib does not provide fs access as the API couldn’t be shared between the JS and Erlang targets. The most popular fs package for erlang target didn’t look of high quality at all. Something so basic and important.

- This made me realise that in contrast to elixir which not only runs on the BEAM („Erlang“) but also runs with seamless Erlang interop, Gleam doesn’t have access to most of the Erlang / Elixir ecosystem out of the box.

There are many things I liked, like the algebraic data types, the Result and Option types, pattern matching with destructuring. Which made me realize what I really want is Rust. My ways lead to Rust, I guess.

> Gleam doesn’t have access to most of the Erlang / Elixir ecosystem out of the box.

Gleam has access to the entire ecosystem out of the box, because all languages on the BEAM interoperate with one another. For example, here's a function inside the module for gleam_otp's static supervisor:

    @external(erlang, "supervisor", "start_link")
    fn erlang_start_link(
      module: Atom,
      args: #(ErlangStartFlags, List(ErlangChildSpec)),
    ) -> Result(Pid, Dynamic)

As another example, I chose a package[0] at random that implements bindings to the Elixir package blake2[1].

    @external(erlang, "Elixir.Blake2", "hash2b")
    pub fn hash2b(message m: BitArray, output_size output_size: Int) -> BitArray

    @external(erlang, "Elixir.Blake2", "hash2b")
    pub fn hash2b_secret(
      message m: BitArray,
      output_size output_size: Int,
      secret_key secret_key: BitArray,
    ) -> BitArray

It's ok if you don't vibe with Gleam – no ad-hoc poly and no macros are usually dealbreakers for certain types of developer – but it's wrong to say you can't lean on the wider BEAM ecosystem!

[0]: https://github.com/sisou/nimiq_gleam/blob/main/gblake2/src/g...

[1]: https://hex.pm/packages/blake2

Isn’t this the proof of my point - How does the need of writing „@external“ annotations by hand not contradict the point of being „out of the box“ usable?

Hayleigh, when I asked on the discord about how to solve my JSON problem in order to get structured logging working, you replied that I’m the first one to ask about this.

Now reading this: > It's ok if you don't vibe with Gleam – no ad-hoc poly and no macros are usually dealbreakers for certain types of developer

Certainly makes me even more feel like gatekeeping.

I don't think Hayleigh was trying to gatekeep, just noting that some developers prefer features that Gleam intentionally omits.

As for the @external annotations, I think you're both right to a degree. Perhaps we can all agree to say: Gleam can use most libraries from Erlang/Elixir, but requires some minimal type-annotated FFI bindings to do so (otherwise it couldn't claim to be a type-safe language).

How does it contradict it? Without any modification/installation you can interop with Erlang/Javascript. How is that not out of the box usability of the Erlang/JS ecosystem? Syntax isn't as seamless as Elixir, but we need a way to tell Gleam what types are being passed around.

Why do you feel like a gatekeeper? Your opinion is valid, it's just that the interop statement was wrong.

That's FFI bindings. I need to provide the function signature of every API, because Erlang isn't statically typed. It's okay if some library provides it (like the linked , but I don't want to write this by hand if I can avoid it. And it's definitely not out of box, someone has to write the bindings for it to work

It would be different if I didn't have to write bindings and Gleam integrated automatically with foreign APIs. For Erlang that's probably not possible, but for the Javascript ecosystem it could make use of Typescript signatures maybe. (it would be very hard though)

Yeah, it's there out of the box but it's certainly not seamless. For an Elixir dev, it is more friction than you're used to. It is the cost of static types.

This is the same as Elixir, you need to specify what Erlang function to use in that language if you want to use Erlang code. The only difference is that Gleam has a more verbose syntax for it.

In Elixir you just call the Erlang function directly. It's basically the same as calling an Elixir function, just with a different naming convention.

In Gleam, you first have to declare the function type and THEN you can call the function directly.

This is probably the lightest way you can bridge between statically and dynamically typed languages, but it's not the same as Elixir.

Sorry, I've been unclear.

The runtime behaviour and cost of calling an Erlang function is the same in Elixir and Gleam, however the syntax is more verbose in Gleam as it asks for type information, while in Elixir this is optional.

I'm a bit torn on ad-hoc polymorphism. You can definitely do cool things with it. But, as others have pointed out, it does reduce type safety:

https://cs-syd.eu/posts/2023-08-25-ad-hoc-polymorphism-erode...

The same point holds of interfaces. And it’s not clear what the alternative is. No type system I’m aware of would force you to change all occurrences of this business logic pattern, with or without ad hoc polymorphism.

But at least ad hoc polymorphism lets you search for all instances of that business logic easily.

ML languages have a "types, modules, types-of-modules, and functors" approach to ad-hoc poly. It's a bit strange compared to what other languages do. I am wondering whether it's ever been seen outside of SML and OCaml.

For JSON deserialisation, you would declare a module-type called "JSON-deserialiser", and you would define a bunch of modules of that module-type.

The unusual thing is that a JSON-deserialiser would no longer be tied to a type (read: type, not module-type). Types in ML-like languages don't have any structure at all. I suppose you can now define many different JSON-serialisers for the same type?

The article provides a contrived example and doesn't prove that ad-hoc polymorphism reduces type-safety. Even when `Maybe [a]` is being folded via `Foldable f` the claimed type-safety isn't reduced, it's the context of the folding that's being changed from `[a]` to `Maybe a`, and everything is type-safe. Secondly, if you really want to distinguish between the empty list and disabled allow-lists within your type-system you do define your own data type with that representation, and you don't declare it foldable, because the folding algebra doesn't make sense for any practical use-case of the disabled allow-lists. The language actually provides you with the means to reduce evaluation contexts your types can be part of.

I’ve been doing Elixir for 9 years, 5 professionally. Nobody cares about ad-hoc polymorphism. The community doesn’t use protocols except “for data”. Whatever that means. Global singleton processes everywhere. I’m really discouraged by the practices I observe but it’s the most enjoyable language for me still.

>I’ve been doing Elixir for 9 years, 5 professionally. Nobody cares about ad-hoc polymorphism.

That’s true for Elixir as practiced, but it’s the wrong conclusion for Gleam.

Elixir doesn’t care about ad-hoc polymorphism because in Elixir it’s a runtime convention, not a compile-time guarantee. Protocols don’t give you universal quantification, exhaustiveness, coherence, or refactoring safety. Missing cases become production crashes, not compiler errors. So teams sensibly avoid building architecture on top of them.

In a statically typed language, ad-hoc polymorphism is a different beast entirely. It’s one of the primary ways you encode abstraction safely. The compiler enforces that implementations exist, pushes back on missing cases, and lets you refactor without widening everything into explicit pattern matches.

That’s exactly why people who like static types do care about it.

Pointing to Elixir community norms and concluding “nobody cares” is mixing up ecosystem habits with language design. Elixir doesn’t reward those abstractions, so people don’t use them. Gleam is explicitly targeting people who want the compiler to carry more of the burden.

If Gleam is “Elixir with types,” fine, lack of ad-hoc polymorphism is consistent. If it’s “a serious statically typed language on the BEAM,” then the absence is a real limitation, not bikeshedding.

Static types aren’t about catching typos. They’re about moving failure from runtime to compile time. Ad-hoc polymorphism is one of the main tools for doing that without collapsing everything into concrete types.

That’s why the criticism exists, regardless of how Elixir codebases look today.

Well, for the specific example I gave (JSON serialization), you certainly do care whether Jason.Encoder is implemented for a struct.

Yes, I just ranted, sorry. I share your view about Gleam.

IMHO this is an education problem.

Problem which plagues 90% of the people? How to overcome it?

It's an education problem on two fronts. People inside the ecosystem need to know about it. And also people too deep in the elixir ecosystem who don't know how ad-hoc polymorphism is supposed to be used in a statically typed language.

Both overcome it by admitting they don't know and need to learn.

I think this is just an extension of "Fuck you money"

I think you're very close to being right...

But I think "Fuck you money" implies, "I honestly don't have to worry about money, ever again."

Now, we all have different definitions for that, but the kind of thing I was talking about is definitely not "Fuck you money," to me.

I think if I had "Fuck you money," my best friends and close family would all have their medical debts paid off. I think my parents and in-laws would have their mortgages paid off.

That is what they call "fuck me money". As in, fuck me I'll just pay it.

FUM is the freedom to walk away. FMM is the power make your own terms.

It’s more than just money, it’s how you set up your life to be resilient to contingencies. For example finding a compatible life partner. For example finding happiness without lifestyle inflation and breaking free from the hedonic treadmill. Or perhaps having a good lifestyle business for some people. Or having extended family support nearby. I call these things unfuckwithability. Money is a big part of it, but may not be the biggest missing piece for many people.

> It's like they are building tech for made up in corporate conference room use cases.

Totally felt the same during the live-translation demo, when these two casual business folks were talking about "the client will love the new strategy". Dystopian corporate gibberish.

The lack of authentic examples diminishes the impressive tech. Great design is all about function. Why is it so hard to show how this would actually be used in the real world?

I've been writing Elixir on-and-off since 2017 for personal projects and since 2024 professionally, at a big tech company.

The two experiences couldn't be more different. While I loved the great development speed for my personal projects, where I am writing more code than reading it, joining an existing project needs the opposite, reading more code than writing it. And I can only repeat what many people say, dynamic typing makes this so much more difficult. For most code changes, I am not 100% certain which code paths are affected without digging a lot through the code base. I've introduced bugs which would have been caught with static typing.

So in my conclusion, I'm bullish on gleam, but also on other (static) languages embracing the cooperative green-thread/actor model of concurrency like Kotlin (with JVM's virtual threads). (On another note, I personally also dislike Phoenix LiveView and the general tendency of focusing on ambiguous concepts like Phoenix Context's and other Domain Driven Design stuff)

I worked a year or so at an Elixir shop, and this mirrors my experience. I had to navigate to call sites to understand what I was being passed and type hints were not sufficient. Dynamic typing fails larger orgs/teams/codebases.

Fun to develop and solo administer. Small teams with a well known codebase can do amazing things. I work at orgs with multiple teams and new hires who don't know the codebase yet.

For me, the sweet spot is Go.

Out of curiosity, at the tech company, did the team use typespecs and dialyzer?

The lack of type hint for function parameters is definitely a productivity killer (in my case).

There are type hints for function parameters. With some care and guards, Dialyzer can be somewhat helpful.

What actually drove me nuts was absence of guards and meaningful static analysis on return values. Even in my small but nontrivial personal codebase I had to debug mysterious data mismatches after every refactor. I ended up with a monad-like value checking before abandoning Elixir for my compiler.

Fully agree with this based on similar experiences. IME most devs hired without previous Elixir/Phoenix experience don’t end up liking the tech stack very much, even though they become productive quite quickly and don’t struggle too much with Elixir. A lot of Elixir/Phoenix fans make the mistake of thinking that everyone is going to love it as much as they do once they get up to speed.

Isn't there some kind of optional typing in Elixir?

What you're describing are the same uncertainties I've used to have writing PHP a long time ago, but since using optional types and PHPStan checker, it kind of serves as a compiler pass that raises those issues. The benefit being that I still can be lazy and not type out a program when I prototype the problem on my first pass.

>Isn't there some kind of optional typing in Elixir?

It’s in the works and recent versions of the compiler already catch some type errors at compile time, but it’s nothing remotely close to what you get from Typescript, or from any statically typed language like Go, Rust, Java, etc.

> Isn't there some kind of optional typing in Elixir?

Sort-of. Developers provide typespec which is like a hint and use dialyzer to find issues before runtime.

This is why Gleam exists.

Also, Gleam fully supports Elixir packages.

I am now super curious which big tech company is betting on Elixir?

Nubank, Latin America's most valuable bank, relies heavily on Elixir and even acquired Plataformatec, the company where Elixir was created.

A blog post by them about this: https://building.nubank.com/tech-perspectives-behind-nubanks...

Wasn't Nubank the Clojure posterchild not long ago?

Are they moving from Clojure to Elixir, or adding it?

The referenced post is from 2020, and nubank still posts clojure content and sponsors the big clojure conference, so I’d be shocked if they were dropping clojure.

Their tech stack is probably enormous, it wouldn’t surprise me if they’re using both for different things

Also the referenced post is about them acquiring plataformatec, not about using elixir. Jose Valim (the creator of elixir) left plataformatec after the nubank acquisition in order to continue developing elixir, I've never heard of nubank using elixir, afaik they're solidly a clojure shop with no plans on changing.

it's just an internal I/O-bound project, where BEAM concurrency makes lots of sense. Grown from an engineer's side project as it was useful and working well, not a company-wide effort to bet on Elixir

Having worked as Cloud Solution Architect at Microsoft Germany/Azure, let me tell you:

Nope this gap can not be closed by any US company alone due to the Us Patriot Act - which forces any US company (including e.g. a German subsidiary) to allow access to all data for national security purposes.

Having worked at AWS, no, it's a separate partition under a separate legal entity, and the EU framework is specifically designed to counter Patriot Act, CLOUD Act and the like. It's gonna be similar to AWS China, and potentially more restrictive in some senses. That leaving aside regions we're not allowed to talk about.

> Having worked at AWS

This should be disclaimer at your first message when you compared AWS with UPCloud.

TBH, I would not trust AWS with countering the Patriot Act.

> This should be disclaimer at your first message when you compared AWS with UPCloud.

Fair, my bad. Still obviously misleading.

1. DB instances "starting at $144", I have a $63 in my basket at the moment, and also Aurora Serverless charges on resources used and can be potentially cheaper depending on the workload.

2. "$82.8 /mo" for a 2 core 8GB server is actually just under 50.

3. European DC locations: 8 for both. Unsure what UpCloud means for them here[0], they look like actual, individual DCs, but AWS has 8 European regions. Each region has normally 3 AZs which are physically separate DCs (which can be in proximity or not) and can be composed of multiple DCs each. Plus there are localzones depending from certain regions, each with at least one DC (and there are 11 of those). So the AWS number is certainly over 30 if we compare apples to apples.

The rest I don't have time to dive in, or are just opinions (certifications needed for proficiency? really?)

>TBH, I would not trust AWS with countering the Patriot Act.

AWS China wouldn't have happened if they didn't offer enough safeguards. Complying with Patriot Act will guarantee enormous fines for AWS in the EU, so I'm sure legal and finance did their homework for AWS not to end up between a rock and a hard place.

[0] https://upcloud.com/data-centers

> AWS China wouldn't have happened if they didn't offer enough safeguards.

AWS China vs. AWS EU: Data centers in China are managed by Chinese companies, whereas DCs in the EU are managed by USA companies.

From a regulatory perspective, it's two different worlds. The Patriot Act can happen in the EU, not in China.

This is why GDPR does allow that EU user data is transferred to non-EU countries, but not to the USA.[0]

Furthermore, a discernible trend has emerged, attributable to the inadequacies in privacy regulations and suboptimal Trump geopolitical strategies with the EU, the EU is actively seeking better cloud services [1].

[0] https://gdpr-info.eu/issues/third-countries/

[1] https://www.wired.com/story/trump-us-cloud-services-europe/

From the thread:

  @discardableResult
  public init(priority: TaskPriority? = nil,
      operation: sending @escaping @isolated(any) () async -> Success)

> Take just the operation argument. It's a closure that is sending, escaping, declares any isolation (I don't understand this part very well yet), it's async and it returns Success. That's a whole bunch of facts - 7 to be precise - you need to know about just one parameter of this constructor. I understand that all 7 make sense and there's nothing you can do about it within the current strict concurrency model.

two of the three coalition parties are against it - the greens and the FDP (the social democrats are in favour), thus the government doesnt support.

they are neither far left/right

> they are neither far left/right

Are Linke and AfD are for chat control? They're by whom the coalition is being threatened.

The current government coalition is threatened by the CDU (centre-right), not by Linke (that has almost no voters left) or AfD (who no other party wants to form a coalition with).

The most likely outcome after the next election at this point looks like a coalition between the CDU and the Green party.

Unfortunately, CDU is probably in favour (they're pretty "law and order") and the Greens probably won't care enough to oppose strongly.

there already is an lsp available (officially from Apple).

Tried it out a month ago (on Linux using neovim) and the autocompletion was on par with golang lsp in terms of speed. Didnt check the lsp capabilities though.

Since 99% of people have to study hard to pass LC (medium/hard), it effectively acts as a selector for employee conformity. People who play by the rules imposed upon them, who work long hours if corp wants them to etc.

All the talk about diversity, but no diversity of thought. Only LC chasers. I genuinely believe this decreases innovation massively.

They're certainly proxies for other things.

>All the talk about diversity, but no diversity of thought. Only LC chasers. I genuinely believe this decreases innovation massively.

Nice belief, but good luck proving it.

I imagine the people grinding LC are harder working/more innovative than people who watched TV instead.

Yes, those are the only two options. I'd rather spend time with my kids than grind for 4 hours a day to get ghosted after the 5th round of interview.

If you spend your free time with kids you are outlier. Average adult in US watches 3 hours/day of TV (stats which frankly amazed me) which if spend more productiveky is more than enough to grind for interview

You were on to something with the GP's unprovable assertion.

Then you provided your own false dichotomy and the argument went all wrong.

Why are the two choices LC or TV? What about those who have a family, hobbies, etc?

The average American spends 3-4 hours per day on TV or Internet entertainment.

Sooo... its not much of a leap.

>I imagine the people grinding LC are harder working/more innovative than people who watched TV instead.

I suspect the original author of the article that spawned this comment thread prepared for the interview somewhat rather than watching TV instead - and still got sickened of the LT style interview.