4 ms·

My argument is that you'll need better developers who cost more money. Not only that, but you're making the project more complicated. i.e if the project is to c

by n0body 12y ago

My argument is that you'll need better developers who cost more money. 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. and you've also got the added overhead of running xen. all in all 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, since you get the bare metal, and a little bit of a environment to bootstrap from.

lmm 12y ago
> 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.

by n0body 12y ago

lmm 12y ago

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