6 ms·

>"The VM will be intentionally designed to avoid code rot" How do you plan to do that?

tachyonbeam 9y 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 9y 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 9y 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 9y 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 9y 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.
    - eropple 9y ago
      You can make useful audio software for a very tiny slice of a very picky market without a plugin architecture. Even crap like Audacity has a plugin architecture for a reason: because they know they don't support what people need and want. And yes, you can build your own plugins. You cannot replace the thousands upon thousands of VSTs out there. You aren't replacing, for example, RealStrat, which is a supersampled virtual instrument, without re-recording the entire thing (do you know how? Is anyone going to bother doing it when they can use existing, conventional software?) and simultaneously reverse-engineering the algorithms used internal to it. You aren't replacing even something comparatively simple like an Amplitube without heavy-hitting, lots-of-money algorithmic research in the first place. (And, on top of that, I sure wouldn't want to deal with the patent encumbrances!) And pardon my skepticism, but emulating latency-sensitive, CPU-intensive stuff like audio processing strikes me as a pretty foolish idea. When milliseconds count, your emulation layer just gets in the way. What benefit are you bringing to make additional failure cases and additional latency worth a user's time? You aren't reinventing the entire audio world; as with many other fields, the lingua franca is C and not you and no matter how much you yell at the mountain the mountain's not gonna move. If you want to play, you have to play with (good metaphor for music in general, now that I think about it). Maybe you should rethink some of your decisions, or better constrain your ambitions. Because right now--and this may sound harsh but I'm saying it because I like seeing people succeed--it sounds like you're doing the software engineer That Guy thing and handwaving away difficult things because they aren't conducive to the postulates you're starting with.

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 9y 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 9y 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 9y 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 9y 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.
  - eropple 9y ago
    You can make useful audio software for a very tiny slice of a very picky market without a plugin architecture. Even crap like Audacity has a plugin architecture for a reason: because they know they don't support what people need and want. And yes, you can build your own plugins. You cannot replace the thousands upon thousands of VSTs out there. You aren't replacing, for example, RealStrat, which is a supersampled virtual instrument, without re-recording the entire thing (do you know how? Is anyone going to bother doing it when they can use existing, conventional software?) and simultaneously reverse-engineering the algorithms used internal to it. You aren't replacing even something comparatively simple like an Amplitube without heavy-hitting, lots-of-money algorithmic research in the first place. (And, on top of that, I sure wouldn't want to deal with the patent encumbrances!) And pardon my skepticism, but emulating latency-sensitive, CPU-intensive stuff like audio processing strikes me as a pretty foolish idea. When milliseconds count, your emulation layer just gets in the way. What benefit are you bringing to make additional failure cases and additional latency worth a user's time? You aren't reinventing the entire audio world; as with many other fields, the lingua franca is C and not you and no matter how much you yell at the mountain the mountain's not gonna move. If you want to play, you have to play with (good metaphor for music in general, now that I think about it). Maybe you should rethink some of your decisions, or better constrain your ambitions. Because right now--and this may sound harsh but I'm saying it because I like seeing people succeed--it sounds like you're doing the software engineer That Guy thing and handwaving away difficult things because they aren't conducive to the postulates you're starting with.