> My argument is that you'll need better developers who cost more money.
Frankly I wouldn't want a developer who's too dumb to learn OCaml anywhere near my production code. Is this thing new? Yes. Will developers take time (=your money) to get up to speed on it? Yes. But do you need "better" developers, long-term? I don't think so.
> Not only that, but you're making the project more complicated. i.e if the project is to create x, then you have to also create y first and, it's harder to debug.
Maybe a valid concern, but I remember very similar arguments from C++ programmers in the early days of the JVM. Turns out the JVM is rock-solid and nowadays has better debugging tools than those for C++. There's no reason that couldn't be true for this approach. Or if it's easy to make a multi-target project that builds both a linux binary and a unikernel image, then debugging would be no harder than it is for existing OCaml code.
> and you've also got the added overhead of running xen.
If you're already running linux-in-xen then this is reducing overhead. Even if you're not, it could still improve overall performance by reducing context switching, in the same way as user-mode networking stacks.
> it's a nice trick, but it's not very practical, because if it was practice we'd all be using dos for our vms
This sounds rather like "this can't be a good idea because if it was we'd have it already". It's only in the last few years that xen and the "cloud" approach have become so popular, so a lot of new ideas and approaches are still being found.
Frankly I wouldn't want a developer who's too dumb to learn OCaml anywhere near my production code. Is this thing new? Yes. Will developers take time (=your money) to get up to speed on it? Yes. But do you need "better" developers, long-term? I don't think so.
> Not only that, but you're making the project more complicated. i.e if the project is to create x, then you have to also create y first and, it's harder to debug.
Maybe a valid concern, but I remember very similar arguments from C++ programmers in the early days of the JVM. Turns out the JVM is rock-solid and nowadays has better debugging tools than those for C++. There's no reason that couldn't be true for this approach. Or if it's easy to make a multi-target project that builds both a linux binary and a unikernel image, then debugging would be no harder than it is for existing OCaml code.
> and you've also got the added overhead of running xen.
If you're already running linux-in-xen then this is reducing overhead. Even if you're not, it could still improve overall performance by reducing context switching, in the same way as user-mode networking stacks.
> it's a nice trick, but it's not very practical, because if it was practice we'd all be using dos for our vms
This sounds rather like "this can't be a good idea because if it was we'd have it already". It's only in the last few years that xen and the "cloud" approach have become so popular, so a lot of new ideas and approaches are still being found.