Your tone could be improved.

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.

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.

You're not parsing so I'm done trying. Good luck with it.

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.

In the large, sure. But "if you're going to say you can do X, you should have a good idea of what X is" is pretty baseline, I think.

@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

You can click on the post itself to reply to it.

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.)