6 ms·

How does this project compare to nekovm? Sounds very similar.

tachyonbeam 10y ago
Not familiar with Neko, but superficially, it seems that VM is designed for a specific programming language. It uses a bytecode IR whereas Zeta uses a textual one. Neko is also farther along, more mature and feature complete than Zeta. I intend to take a more experimental direction with Zeta. It won't have an FFI, for instance. It will only provide a small set of minimalist APIs. The VM will be intentionally designed to avoid code rot and breaking changes. Another thing I would like to experiment with is transparent compilation of pixel shaders to run on GPUs, the ability to run code in any language running on Zeta (given some restrictions) on both the CPU and GPU. I believe I have found a way to make this work, based on my type-specialization research.
- ternaryoperator 10y ago
  >"The VM will be intentionally designed to avoid code rot" How do you plan to do that?
  - tachyonbeam 10y ago
    The IR, once past an initial prototyping state, will not change. Things will be added to it later, but not removed. The IR and semantics will be designed, as much as possible, to eliminate corner cases and undefined behaviors. Zeta will favor robustness over tiny performance gains. I realize that completely eliminating undefined behaviors isn't necessarily possible, but we will do our best. The outside world will be accessible through a set of APIs that are small, have limited surface area. For instance, sound output will be done by writing raw samples. Graphics will be done with pixel shaders (functions which given coordinates return a pixel color). New APIs will be added over time, new versions of APIs will be added, but the older APIs will remain functional. There will eventually be a package manager, and it will have immutable package versioning. That is, you can publish v5 of libtern, and I can depend on it. You can later publish v6 of libtern, but you can't change v5, so you can't break my code which depends on v5 when you publish new versions of your lib. Obvious caveat: Zeta will have no FFI. You won't be able to immediately use all the libraries you could use in another system. I still think that building a huge amount of code that doesn't break could turn out to be a huge advantage. We won't try to satisfy every use case out there... But I think there are a lot of interesting and useful programs which don't need much more than basic keyboard and mouse input, audio and video output, network and file access (think photoshop, audio editing software, IDEs, etc). We will probably end up adding APIs for other things like MIDI, etc later on.
    - __s 10y ago
      What about WebAssembly? It's hit 1.0 now, & it's designed so that 1.0 wasm will never become deprecated My own thoughts have been considering a wasm vm in kernel space. No need to ever exit kernel space; the wasm vm provides sufficient sandboxing. Wasm binaries could run on any architecture. Hopefully come up with a method that browsers can efficiently run wasm in directly in the kernel's sandboxing rather than having wasm-in-wasm. Syscalls could be exposed through wasm's import/export system. Kind of like that Metal idea in "The Birth & Death of JavaScript"
      - tachyonbeam 10y ago
        WASM may remain stable, but it provides no APIs to the outside world AFAIK. The DOM keeps changing, and if the APIs are implementation-dependent, then WASM doesn't guarantee non-breaking at all. Another advantage that Zeta has is that it will come with useful building blocks for dynamic languages. With WASM, you have to implement your own dynamic typing, GC, JIT, etc, and the current WASM implementation doesn't yet support JITting.
    - eropple 10y ago
      > audio editing software In the audio space, it is vital to support FFI for a plugin architecture because I can guarantee you your language isn't the-best-thing-since-sliced-bread for somebody who has stuff you really want available to you. Audio software lives and dies on the VST specification. (Audio Units are substitutable for VSTs--but the same problem remains.) I admire your efforts, but perhaps you should understand the use cases of the things you want to use as examples before you try to employ them. It doesn't instill confidence.
      - tachyonbeam 10y ago
        1. That depends on the audio editing software you want to run. You can build useful audio editing software without plugins. 2. We can build our own plugins 3. It's not impossible to translate or emulate existing VST plugins.
- akkartik 10y ago
  Hmm, I haven't heard this idea before that the FFI or surface area of libraries in a language causes bitrot. Could you elaborate on the connection? I can take version 1 of the C sources of Vim from back in '92 and compile them without trouble. I'm not aware of dynamic languages like Javascript or Python 2 having any bitrot issues either. Backwards compatibility seems like a pretty big constraint for everyone. Edit 16 minutes later: I just tried your benchmark with my VM-like language (https://github.com/akkartik/mu https://github.com/akkartik/mu), and the time taken was almost identical. Interesting exercise! Here's the Mu and Plush/0 programs side by side: $ cat fib.mu def fib n:num -> result:num [ local-scope load-ingredients base-case?:bool <- lesser-or-equal n, 1 return-if base-case?, n n <- subtract n, 1 fib-n-1:num <- fib n n <- subtract n, 1 fib-n-2:num <- fib n result <- add fib-n-1, fib-n-2 ] def main [ local-scope x:num <- fib 29 $print x, 10/newline ] $ cat benchmarks/fib29.pls #language "lang/plush/0" var fib = function (n) { if (n < 2) return n; return fib(n-1) + fib(n-2); }; var r = fib(29); print(r);
  - tachyonbeam 10y ago
    C has been fairly stable across time, but you gave to admit, a C program from 1992 still compiling as-is, that's an exception rather than the rule. The reason Vim from 1992 might still compile is actually because it doesn't have that much dependencies apart from standard C and POSIX APIs. JavaScript has massive bitrot issues. The HTML DOM is huge and constantly changing. I have had my own web apps break multiple times over the years. As for Python and C, if you stick to the core language, and minimize dependencies, you might be Ok. The problem is that the more dependencies you have, if any one of them break, they can render your program broken... And if you're not there to fix it, your program remains broken forever. My argument for reducing API surface and keeping APIs low-level and minimalist is that the smaller an API, the more difficult it is to implement it wrong. It's easier for two implementations to implement a smaller API and have the same behavior. It's also easier to test small APIs for conformance, etc.
    - akkartik 10y ago
      I think I see what you mean. However, all these previous languages would claim that the parts they control have not suffered from bitrot. The dependencies you're thinking of are not considered part of the language in each case. Is that right? How would you keep people from creating new libraries in your language for unanticipated use cases? Say a self-driving car library, or a command-and-control module for all the IoT devices in a house from 2029? It seems to me that bitrot is fundamentally a result of change in the outside world. The only way to opt out of bitrot when the world changes rapidly seems to be to disengage from the world and become irrelevant. I'm fairly certain Mu will not suffer from bitrot in 30 years -- but it'll only be because nobody ever built anything with it :)

Not familiar with Neko, but superficially, it seems that VM is designed for a specific programming language. It uses a bytecode IR whereas Zeta uses a textual one. Neko is also farther along, more mature and feature complete than Zeta. I intend to take a more experimental direction with Zeta. It won't have an FFI, for instance. It will only provide a small set of minimalist APIs. The VM will be intentionally designed to avoid code rot and breaking changes. Another thing I would like to experiment with is transparent compilation of pixel shaders to run on GPUs, the ability to run code in any language running on Zeta (given some restrictions) on both the CPU and GPU. I believe I have found a way to make this work, based on my type-specialization research.

ternaryoperator 10y ago
>"The VM will be intentionally designed to avoid code rot" How do you plan to do that?
- tachyonbeam 10y ago
  The IR, once past an initial prototyping state, will not change. Things will be added to it later, but not removed. The IR and semantics will be designed, as much as possible, to eliminate corner cases and undefined behaviors. Zeta will favor robustness over tiny performance gains. I realize that completely eliminating undefined behaviors isn't necessarily possible, but we will do our best. The outside world will be accessible through a set of APIs that are small, have limited surface area. For instance, sound output will be done by writing raw samples. Graphics will be done with pixel shaders (functions which given coordinates return a pixel color). New APIs will be added over time, new versions of APIs will be added, but the older APIs will remain functional. There will eventually be a package manager, and it will have immutable package versioning. That is, you can publish v5 of libtern, and I can depend on it. You can later publish v6 of libtern, but you can't change v5, so you can't break my code which depends on v5 when you publish new versions of your lib. Obvious caveat: Zeta will have no FFI. You won't be able to immediately use all the libraries you could use in another system. I still think that building a huge amount of code that doesn't break could turn out to be a huge advantage. We won't try to satisfy every use case out there... But I think there are a lot of interesting and useful programs which don't need much more than basic keyboard and mouse input, audio and video output, network and file access (think photoshop, audio editing software, IDEs, etc). We will probably end up adding APIs for other things like MIDI, etc later on.
  - __s 10y ago
    What about WebAssembly? It's hit 1.0 now, & it's designed so that 1.0 wasm will never become deprecated My own thoughts have been considering a wasm vm in kernel space. No need to ever exit kernel space; the wasm vm provides sufficient sandboxing. Wasm binaries could run on any architecture. Hopefully come up with a method that browsers can efficiently run wasm in directly in the kernel's sandboxing rather than having wasm-in-wasm. Syscalls could be exposed through wasm's import/export system. Kind of like that Metal idea in "The Birth & Death of JavaScript"
    - tachyonbeam 10y ago
      WASM may remain stable, but it provides no APIs to the outside world AFAIK. The DOM keeps changing, and if the APIs are implementation-dependent, then WASM doesn't guarantee non-breaking at all. Another advantage that Zeta has is that it will come with useful building blocks for dynamic languages. With WASM, you have to implement your own dynamic typing, GC, JIT, etc, and the current WASM implementation doesn't yet support JITting.
  - eropple 10y ago
    > audio editing software In the audio space, it is vital to support FFI for a plugin architecture because I can guarantee you your language isn't the-best-thing-since-sliced-bread for somebody who has stuff you really want available to you. Audio software lives and dies on the VST specification. (Audio Units are substitutable for VSTs--but the same problem remains.) I admire your efforts, but perhaps you should understand the use cases of the things you want to use as examples before you try to employ them. It doesn't instill confidence.
    - tachyonbeam 10y ago
      1. That depends on the audio editing software you want to run. You can build useful audio editing software without plugins. 2. We can build our own plugins 3. It's not impossible to translate or emulate existing VST plugins.
akkartik 10y ago
Hmm, I haven't heard this idea before that the FFI or surface area of libraries in a language causes bitrot. Could you elaborate on the connection? I can take version 1 of the C sources of Vim from back in '92 and compile them without trouble. I'm not aware of dynamic languages like Javascript or Python 2 having any bitrot issues either. Backwards compatibility seems like a pretty big constraint for everyone. Edit 16 minutes later: I just tried your benchmark with my VM-like language (https://github.com/akkartik/mu https://github.com/akkartik/mu), and the time taken was almost identical. Interesting exercise! Here's the Mu and Plush/0 programs side by side: $ cat fib.mu def fib n:num -> result:num [ local-scope load-ingredients base-case?:bool <- lesser-or-equal n, 1 return-if base-case?, n n <- subtract n, 1 fib-n-1:num <- fib n n <- subtract n, 1 fib-n-2:num <- fib n result <- add fib-n-1, fib-n-2 ] def main [ local-scope x:num <- fib 29 $print x, 10/newline ] $ cat benchmarks/fib29.pls #language "lang/plush/0" var fib = function (n) { if (n < 2) return n; return fib(n-1) + fib(n-2); }; var r = fib(29); print(r);
- tachyonbeam 10y ago
  C has been fairly stable across time, but you gave to admit, a C program from 1992 still compiling as-is, that's an exception rather than the rule. The reason Vim from 1992 might still compile is actually because it doesn't have that much dependencies apart from standard C and POSIX APIs. JavaScript has massive bitrot issues. The HTML DOM is huge and constantly changing. I have had my own web apps break multiple times over the years. As for Python and C, if you stick to the core language, and minimize dependencies, you might be Ok. The problem is that the more dependencies you have, if any one of them break, they can render your program broken... And if you're not there to fix it, your program remains broken forever. My argument for reducing API surface and keeping APIs low-level and minimalist is that the smaller an API, the more difficult it is to implement it wrong. It's easier for two implementations to implement a smaller API and have the same behavior. It's also easier to test small APIs for conformance, etc.
  - akkartik 10y ago
    I think I see what you mean. However, all these previous languages would claim that the parts they control have not suffered from bitrot. The dependencies you're thinking of are not considered part of the language in each case. Is that right? How would you keep people from creating new libraries in your language for unanticipated use cases? Say a self-driving car library, or a command-and-control module for all the IoT devices in a house from 2029? It seems to me that bitrot is fundamentally a result of change in the outside world. The only way to opt out of bitrot when the world changes rapidly seems to be to disengage from the world and become irrelevant. I'm fairly certain Mu will not suffer from bitrot in 30 years -- but it'll only be because nobody ever built anything with it :)