5 ms·

This is the first time I've come across your work! Very cool stuff.

by lpil 6y ago

dnautics 6y ago
thanks! 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 ago
  I 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 ago
    I 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 ago
      I 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.
        sitkack 6y ago
        > 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.

This is the first time I've come across your work! Very cool stuff.

by lpil 6y ago

This is the first time I've come across your work! Very cool stuff.

thanks! 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 ago
I 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 ago
  I 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 ago
    I 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.
      - sitkack 6y ago
        > 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.