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