3 ms·
> I think the industry can support multiple competing unikernels in different languages. That way we can reimplement existing, common facilities not once, but
by dap 11y ago
> I think the industry can support multiple competing unikernels in different languages.
That way we can reimplement existing, common facilities not once, but N times -- and still not support what I was alluding to (namely, allowing specific subcomponents written in a language appropriate for that component).
> Rigorously define ones interfaces while hiding implementation details
Fine, but then there's little advantage to mandating a single address space and language.
- Ericson2314 11y ago> That way we can reimplement existing, common facilities not once, but N times -- and still not support what I was alluding to (namely, allowing specific subcomponents written in a language appropriate for that component). Ah sorry did not realize you meant that. Well the other answer is that more powerful languages can support more expressive and diverse embedded languages. > Fine, but then there's little advantage to mandating a single address space and language. Rigorous interfaces != primitive interfaces, but Unix forces both those on us. For example, how feasible is it to share a tree between to processes? Powerful languages allow us to specify the end-goals of per-process address spaces etc, while leaving the means much more open ended.