3 ms·
The limitations of Dialyzer and typespecs were a big motivator for creating Gleam. They were not reliable or fast enough for my taste. There is some work being
by lpil 6y ago
The limitations of Dialyzer and typespecs were a big motivator for creating Gleam. They were not reliable or fast enough for my taste.
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.
- rubyn00bie 6y agoDo you have any links where I could read up on the work being done for type sharing? Sounds awesome to me.
- lpil 6y agoI don't think anything has been published yet. It's very much in the early ideas stage, but there's a couple private mailing lists with some discussion going on.
- dnautics 6y agoI don't know if this counts as "publishing" but I've made several videos on my personal gripes (warning, super wonky, super BEAM-specific), with accompanying code for a type system that 'fixes' the problems. https://www.youtube.com/watch?v=_XSRsYSwNpQ https://www.youtube.com/watch?v=_XSRsYSwNpQ https://youtu.be/VynXxiXPmG8 https://youtu.be/VynXxiXPmG8 https://youtu.be/2ooSWOCBTPQ https://youtu.be/2ooSWOCBTPQ https://youtu.be/qv-GR4sEsd4 https://youtu.be/qv-GR4sEsd4
- lpil 6y agoThis is the first time I've come across your work! Very cool stuff.
- dnautics 6y agothanks! work on my typechecker has slowed recently due to excitement with nerves + zig, and then nx + zig, so my plan is to do a bit more work with the typesystem starting next week.
- sitkack 6y agoI see where you are going with Zig, and I don't want to dissuade you, but consider adding lumen https://github.com/lumen/lumen https://github.com/lumen/lumen to our train set.
- dnautics 6y agoI think lumen (and especially rust) is the wrong way to go for a BEAM reimplementation. 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 https://www.youtube.com/watch?v=UaF6-5BmX2I&t=1h10m benchmarks of go, rust, and zig at 1h13m
- sitkack 6y agoI do think there are some things that Rust can learn from Zig. One of the biggest wins for the BEAM is that each process has its own heap, so GC pauses only impact a process and they are often short lived, so another reason it is less of an issue. 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.
- dnautics 6y ago> coordinated groups of Wasm envs 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.