gleam VS otp

Wow. I invite everyone to go actually read the Gleam’s homepage: https://gleam.run/

After reading the discussion here, with our poor community being “blinded by pathetic posturing” and such, I was expecting some kind of political polemic plastered over everything.

Here’s the sum total of everything that could be considered political from the page:

Friendly

As a community, we want to be friendly too. People from around the world, of all backgrounds, genders, and experience levels are welcome and respected equally. See our community code of conduct for more.

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

Which part of that can you possibly find objectionable? It seems the mere mention of anything political is seen as a transgression somehow. Like, Can’t we just go back to pretending we’re entirely apolitical, while the technologies we build reshape the political landscape of the entire planet?

Gleam GitHub Repository

Official Gleam Documentation

- https://without.boats/blog/revisiting-a-smaller-rust/

It's also niche, but https://gleam.run/ might be a candidate alternate language, depending on your use-case.

Not the other commenter, but my team has been using Elixir in production (soft real-time distributed systems) for several years to great success. The approachable syntax has been great for folks new to the language coming on board and sort of, not realising they’re “doing FP”.

Generally I’d say Elixir’s lack of “hard” static typing is more than made up for what you get from the BEAM VM, OTP, its concurrency model, supervisors etc.

That said if you’re interested in leveraging the platform whilst also programming with types I’d recommend checking out Gleam (https://gleam.run), which I believe uses an HM type system.

The BEAM runtime demonstrates the power of building concurrency and fault tolerance into the core runtime. While other languages can approximate these capabilities through frameworks, the elegance and robustness of having it built into the runtime remains compelling. I believe that’s why Gleam decided to use the BEAM when it was being built.

Gleam

Gleam as it says in their website is a friendly language for building type-safe systems that scale!.

One language that really gave me that feeling was Gleam, it managed to wrap everything I liked about languages such as JS, Rust and even Java into one brilliant type-safe package. Not for a long time before I met Gleam had I wanted to try creating so many different things just to get to the bottom of how this language ticked, as it were.

I thought that since Gleam is build for BEAM, it should be good at concurrency? I thought that was its whole angle, but there's not a mention of concurrency at all in the docs, it's not built into the standard library, and apparently this is all they offer: https://hexdocs.pm/gleam_otp/

If Gleam is good at concurrency why aren't they telling anyone about it, and if it's not good at concurrency what even is the point of it?

Modern type system over BEAM sounds great but unfortunately OTP is still not 100% supported https://github.com/gleam-lang/otp?tab=readme-ov-file#limitat...

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.

Looks like it is an external library[^1]. Readme states it is experimental and lists some limitations.

[^1]: https://github.com/gleam-lang/otp

We have a fully type safe and OTP compatible implementation of actors and supervisors here https://github.com/gleam-lang/otp

No primitives as it's not possible to have them when compiling to JavaScript, but we do have them as types and functions in the OTP library https://github.com/gleam-lang/otp

On the advice of u/WrongJudgment6 I'm reading the Gleam OTP tests. But I can't compile, and hence can't test, the code. (I'd like to do that so I can tweak the tests to do my own experiments.) Whenever I try I get an error like this:

And docs at https://hexdocs.pm/gleam_otp/