Gleam is nothing like Erlang or Elixir (its copying of Rust is so slavish it even has a toml file driven build system) and Erlang and Elixir are not split (the only place where they even sorta are is rebar vs. mix).

I don't particularly want to gatekeep "Rust fans who just want to write lots of Rust" off OTP. Let them have Gleam. Maybe they'll figure out how to lifetime-annotate binaries?

Gleam and Rust are really not alike at all aside from the most superficial ways. A couple bits of syntax, and the use of toml are about all I can come up with.

> Maybe they'll figure out how to lifetime-annotate binaries?

What do you mean by this, I know how lifetimes work in rust, but how would you do it on the binary level ?

Binary is Erlangese for Vec<u8>, hope that helps

There are no lifetimes in gleam though right ? or did i miss the memo.

No lifetimes, absolutely no plans to add anything similar. We’re nothing like rust!

maybe they can add them to guard against copying large binaries too much

Hi, I'm the designer of Gleam!

Beyond being functional and sharing a runtime I don't think Elixir and Gleam have much in common at all. Our recent developer survey showed that the majority of Gleam programmers were not Elixir users and largely were not attracted to that language.

My question is: is how one approaches writing programs in Erlang, Elixir, and Gleam fundamentally different from one another? And is the difference enough for the split in the ecosystem?

> Our recent developer survey showed that the majority of Gleam programmers ... largely were not attracted to that language.

I must admit that I find that fairly bizarre. What do you imagine the source of that lack of desire is?

For context, my favorite language is F# and ML-dialects in general, but I also like what I call "principled" dynamically typed languages like Scheme, Racket, Erlang, and Elixir.

Yes, they are very different. It's not splitting the ecosystem though as the vast majority of Gleam programmers are not former Elixir, Erlang, or LFE programmers, it's people coming from other ecosystems.

Gleam grows the BEAM ecosystem by bringing people in from elsewhere who were not interested in writing Elixir, Erlang, or LFE.

> I must admit that I find that fairly bizarre. What do you imagine the source of that lack of desire is?

They're just very different languages to work with. The programming experience is very different.

There are TONS of JVM languages and nobody is complaining about that. BEAM is much smaller and a very nice target IMO. I learned Erlang but found it too weird for my tastes. Elixir lacked a type system when I evaluated it, and that steered me away from it. Gleam feels kind of like Elm felt. Small, simple, and safe. It feels very intentional and designed for a particular purpose and audience. I did their online tutorial and felt comfortable with the language in one sitting. Can’t say that for many other languages.

Who is choosing anything but Kotlin for new projects on the JVM?

The point is that beyond some basic typing things, programs written in Erlang, Elixir, and Gleam will all have the same core structure. Immutable data plus pattern matching plus BEAM processes has a pretty strong affect on any BEAM language.

> Who is choosing anything but Kotlin for new projects on the JVM?

I dunno... Scala, Clojure, and Groovy users? Small user bases, but the languages are not dead.

That's kind of my point. Does the JVM really need four different general purpose languages with their own ecosystems to split the JVM ecosystem and userbase?

Why not? There's like 483 different application frameworks for the JVM too. The more choices the better - it lets ideas cross-pollinate, and the best ideas get borrowed/stolen. Some people like different syntax, bindings, etc.

I find the opposite more troubling, actually. Take the C# ecosystem and see how there's one de-facto application framework (.NET), one logging lib, one etc... It's usually Microsoft's way or the highway, and 3rd party libraries and frameworks struggle to get any adoption. Consequently, that ecosystem is much smaller, less diverse, and less innovative.