Gleam 0.14 – Type-safe language for the Erlang VM
gleam.run
gleam.run
Gleam: A statically typed language for the Erlang VM - https://news.ycombinator.com/item?id=22902462 - April 2020 (109 comments)
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)
https://gist.github.com/macintux/6349828#alternative-languag...
LiveView helped a bit.
It looks different, so I don’t fall into old patterns, and there’s practically nothing there. Very concise, minimal, just gets out of the way.
I just can’t get into Elixir because it’s both too familiar and so verbose.
Elixir notoriously looks like Ruby but it doesn't. Idiomatic Elixir is totally different. Programs are written in a different way because of pervasive pattern matching. It doesn't look like anything I used before.
There is some work being done towards better types for Erlang, as well as sharing types between languages on the BEAM. I'm excited to see what comes in future.
For starters, if you look at the BEAM vm, there are, what, 10 different allocators? This is a use case that screams out "use zig". Sure, you can tell rust to use no_std, but if you start pulling in libraries from cargo, there's no guarantee that they will respect you, and you can define a global custom allocator for collections in std, but wrangling more than one global allocator (presumably by making a single flexible global allocator and using macros to select branches of it) is going to be tiresome, and a very easy way to wind up with critical logic errors.
Moreover it's far easier to safe, highly performant things in zig.
https://www.youtube.com/watch?v=UaF6-5BmX2I&t=1h10m
benchmarks of go, rust, and zig at 1h13m
I see what you are saying, but in a way, coordinated groups of Wasm envs can also bring many of the same qualities.
I have no experience with allocators in Rust, that is definitely a gap for me.
I'd love to a see a Zigification of BEAM, Python, etc. That Zig can load header files directly and includes a C compiler is so damn nice.
too much overhead. The way that zap gets so fast as in the video is by decreasing overhead, minimizing coordination, and by allocating on the stack instead of the heap for all allocations related to context switching. One could imagine a BEAM system where you create a custom allocator where FIRST you get allocations on the stack for the first X register refs, then later it reaches out to the heap. This would be blazingly fast for the 99% use case in elixir.
You're also generally going to have a hard time figuring out how to do this in rust, as I don't think it's so easy to mix stack and heap allocations into a single interface for rust.
I am not good enough at Rust to even discuss, let alone debate this.
We can talk about things, Zig and Rust and then go up an abstraction level and talk about systems and communities, I believe both want to address this issue. I think it is more important to outline the problem and them to address it.
The languages are just the reification of a philosophy.
I have thought about this a lot (I'm writing a static typechecking library for Elixir) and really the problem is the dialyzer typesystem. Almost all of the problems stem from the root fact that there isn't a granular concept of how to treat functions in the type system. What does `(int, int) -> int` mean? Dialyzer does not have a good answer for that question.
Mind you I am not a "PL theory" type of guy, I do have a math degree, but my PhD is in the sciences, so I am more approaching this issue from a "discovering what would be truly useful" perspective more than "applying an existing typesystem to the BEAM", which is I think in line with the traditional pragmatism of the BEAM ecosystem.
This is an interesting question. Do you have any thoughts on what a better answer to that question might mean? Or languages you think do better here? Thank you
let's go with a simpler one: int -> int
"I guarantee that if you send me an int then i will return you an int without crashing"
In elixirland: `IO.inspect/1` would satisfy this, as would `Kernel.-/1`. The interesting thing is that `any -> int` is then a subtype of `int -> int` and we need a new type `_ -> int` which is "any one-arity function that emits int".
Then types become a statement of "resistance to crashing" in the BEAM vm, which I think is the useful thing that people are looking for.
I don't have answers to everything; I don't know how to deal with a function that generates random numbers from 1 to 20 and crashes on 13, for example.
We should have a discussion about this! I'll reach out on another channel.
> "I guarantee that if you send me an int then i will return you an int without crashing"
This is a much stronger guarantee than you get in any language except very specialized ones. Coq, for example (not just not crashing, but also guaranteed termination). But even in Haskell an Int -> Int function can crash or decide not to terminate. Reading more into a type opens up cans of worms that are hard to solve.
An effects tracking system can be used to determine things such as use of FFI, `assert`, recursion, and side effects. With these statements like "this function does not crash" is easy, and "this function does not diverge" is also possible, though it will not detect all functions that do not diverge.
The only no_returns otherwise are loops and hibernates. Hibernates are explicit. You might have a hard time analyzing the tail-calls to figure out an ultimate type that captures a no_return loop, but I think ignoring that condition would not be horrible for a BEAM type system (along the same lines as the random number crash scenario that I described).
I'm not sure what you're saying. Crashing "miscodes" (like pattern match failures) are a thing, no? A "well defined" thing, but not one that a type system that doesn't include proper theorem proving will save you from.
Most languages don't have a way to type that, I'm pretty sure it requires dependent types.
The types don't prove the logic doing the right thing or that nothing can break while the function runs, but they prove that you are using it mostly correctly in what you give it and what you do with what it'll return.
Or maybe it just like speaks to you.
Rust (usually) compiles to a single standalone binary, that includes any runtime needed. Concurrency is now usually provided via sync with something like Tokio underneath. You can absolutely do actor programming (see Riker and Actix), but it's not the primary way Rust is intended to be used, and it doesn't offer the same set of management capabilities that the BEAM does
Erlang/Elixir/Gleam run on the BEAM. This is a standalone runtime (VM) that then executes code. Deployment involves a lot more pieces, but once done you get a lot more tooling built in (e.g. the observer to see what actors are running). It is designed from the ground up for actor model concurrency, and concepts like supervisor trees have been proven to be best-in-class for managing code running over long periods of time and handling errors in a self-healing way. Plus the separate VM means you can do things like zero-downtime update ("hot code loading").