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.
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.
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.
I'm OK with not being able to replace every audio program ever written. That's an impossible goal. I also know that I can never satisfy every possible use case.
I'm also quite sure that an audio program with a plugin architecture will be feasible in Zeta, once it's more mature. The system is built for scripting, multi-language support and dynamically loading packages. It will be an excellent platform for plugins. You'll be able to define your own custom plugin language(s) easily, and then you'll be able to dynamically browse and load plugins from the package manager.
Let's put it this way: WHEN (and IF) Zeta works, people can discuss its suitability for audio work, and how it would cater to the VST crowds. Until then, this is beyond premature discussion...
I think people fail to understand, too, that I'm OK with having modest goals for Zeta. This system is going to be an experiment. If it doesn't become hugely popular, it's not the end of the world. If some things don't work out, we can try something different. At the end of the day, I think some things really have to be tried out before we can decide if they're viable/useful or not.
I suspect that some of that confusion comes from the fact that you directly compare yourself to LLVM, and that you haven't mentioned much about ParrotVM or NekoVM, which are both efforts in this space. It's also worth saying that the CLR and DLR are both efforts here as well.
When you compare yourself to LLVM, you phrase the comparison as only an advantage (Zeta will be easier to use than LLVM), rather than a tradeoff (Zeta will aim for ease of use before performance, as opposed to LLVM).
I don't suggest that you start hedging your writing, but am just pointing out that if you make big comparisons, people will assume great ambition on your part.
@eropple Replying to myself since HN doesn't let me reply to your comment.
As previously stated, my goal with Zeta is not to replace all existing VMs and to satisfy every use case. It's an experiment, it's an opinionated system. I'm going to do things differently from other implementations and try to demonstrate interesting things along the way. Even if Zeta never becomes popular, I know it will make people talk, and I hope it inspires other systems.
elm is a good example here - there is no ffi for somewhat similar reasons (specifically, that it can make safety guarantees about not crashing at run-time if you don't allow arbitrary javascript code to be called), and that has both helped write reliable code, and hindered it's usefulness in larger applications that have to play with the existing world of js libraries and components
I'm not telling you not to have opinions, to be clear. I'm suggesting maybe you shouldn't adjust those pince-nez and pronounce so hard. Many systems exist the way they do for reasons that Software Developer That Guy cannot divine from outside; you just happened to hit on one that I know a little bit about.
(Photoshop is another example; professional-level tools require professional-level expansion. Because everybody's definition of "professional" is different.)
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"
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.
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.