What is the "case" for Gleam? In general, and specifically for the choice of using the Erlang virtual machine?
I read the "Why Gleam" page, and it reads like "Why have static types" and "Why work on a virtual machine" + "Why we're as good as Erlang". That's not much of a pitch (especially if you're not already into Erlang.)
That's a good point, thank you. I am a long time Erlang/Elixir user and I've mostly been trying to attract that community in the past, so the docs are very biased towards already knowing the value of that ecosystem.
It's tricky to condense into a short reply, but the Erlang virtual machine and way of programming are in some respects second to none. It is build with scalability, concurrency, distributed computing, and fault tolerance in mind. It's really good at handling high load. It uses the actor model and it's not uncommon to have hundreds of thousands of actors in an Erlang programs (in fact the creator of Erlang says that's a "boring" scale) without any deadlocks or fiddly race conditions.
Erlang programs also have mechanisms for self healing when errors arise (bugs, hardware failure, whatever). Kind of like k8s style system but very fine grained and baked into the very language and with 35 years production usage.
This is a bit of an off-the-cuff fanboy-y ramble, but basically it's just a really nice ecosysem to work in when making networked services. I've personally found it makes things a lot easier than most other ecosystems I've worked in.
k8s offers some of the same benefits but not to the same extent because the restarting and state shedding happens at the level of the a container on k8s. On the Erlang VM it happens on a per-process (what Erlang calls coroutines/green-threads/fibers), so rather than losing all state and all requests currently happening in a single instance, you only lose the 1 of potentially millions of processes in your program. This means you can handle failure much more gracefully, and within nanoseconds rather than seconds.
I like to say that Erlang's supervisors are to k8s what k8s is to datacenter failover. Similar things, different level of abstraction.
And yes it's common to use Erlang with k8s, though there is a little redunancy. It's still good for all the other k8s features.
1. I'm not much of a VM person, but I'm always doubtful of claims by VM-based languages to be "fast".
2. "the ... virtual machine and way of programming are in some respects second to none" - We don't easily notice any of those respects on the "Why Gleam" page.
3. "It is built with scalability, concurrency, distributed computing, and fault tolerance in mind" <- That's rather vague. Also, is this a benefit of Gleam, Erlang, or the Erlang VM?
4. "It uses the actor model" <- Many, perhaps most, languages, don't "use the actor model", so I wouldn't know why this it is superior to other ways of programming.
5. "it's not uncommon to have hundreds of thousands of actors in an Erlang programs" <- Well, I didn't see actors in the examples, so I can't tell why this is impressive.
6. If Erlang is so nice, what's wrong with it to make me prefer an non-Erlang, but Erlang-sih language?
7. "Erlang programs also have mechanisms for self healing when errors arise" <- In the most general interpretation, this is Turing-complete, so such a feature is impossible. But perhaps you mean something like exceptions and error codes? Transactional data structures? Something else?
I'm not trying to be facetious, just to understand why this is interesting. Also see my comment about the project CoC, it's pretty scary.
1. For sure, "fast" is a bit of a vague term. To be more specific it's not fast at number crunching, but it has a low latency, low standard deviation concurrent garbage collector and it's quite memory efficient. More details can be found online, and WhatsApp etc provide some good case studies.
2. Yes! More documentation will come as the language matures. For now we will have to defer to Erlang and Elixir documentation and studies.
3. All three. Gleam aims to provide scalability with development through excellent tooling and static analysis, Erlang and the VM provide runtime scalability with fault tolerance, concurrency, parallelism, and distribution at runtime.
4. Quite a tricky one to explain quickly but it's concurrency model based around the idea of having many sychronous subsystems working together in a system similar to how people work together. It's often said to be one of the easiest to use concurrency models. To paraphrase one of Erlang's creators: "It's hard to write a web server that can process 1000,000 concurrent requests, it's easy to write a web server that can handle 1 request and run 1000,000 of them".
5. Most languages will only have 1 thread or 1 per CPU on the machine, so having millions is quite unusual. Golang is another language that has this property and it has proven very valuable.
6. I'm sorry, I don't understand this question. What do you mean?
7. It's not analysis, so turning completeness isn't an issue! The fault tolerance is purely a runtime behaviour. It covers exceptions and such, but also works for hardware failure, network issues, memory corruption, etc.
Now if you could just integrate some of this information into the "Why Gleam" page...
Anyway, about No 6: The why Gleam page and your previous posts do not differentiate Gleam from Erlang. The benefits you described are seemingly shared by Erlang and Gleam, and yet a non-Erlang language was created.
Most the details on the home page are specific to Gleam rather than Erlang. If you'd like to hear more this talk from CodeMesh may help -> https://www.youtube.com/watch?v=HaKR2kt-DXI
Seriously, if you're even the slightest bit curious you should watch the talk, I'm very confident that you'll find impressive what the BEAM brings to the table.
As mentioned elsewhere in the thread with more substance; Gleam runs on BEAM and uses curly brackets. I'm not into types, but I might consider it because I like curly brackets. I'm only partly joking.
I read the "Why Gleam" page, and it reads like "Why have static types" and "Why work on a virtual machine" + "Why we're as good as Erlang". That's not much of a pitch (especially if you're not already into Erlang.)