Comment Re:Unfortunate realities (Score 1) 309
There is no reason that a single
Sure there is. For one thing, a sandbox by its very nature must always impose some overhead, which is anathema to systems programmers. Another paradox is that when you're building the layers in your system, something has to be at the bottom, and that can't be sandboxed.
To take on your more general point, even if you could write a kitchen sink language in which it would be possible to do just about anything, that doesn't mean it would actually be a good language to do any of those things in. Trying to be the Jack of all trades makes you something like C++ or Scala, very flexible, but also so complicated that bugs lurk in every corner case and almost no-one truly understands the entire language and all its subtleties because there are so many interacting and sometimes ill-fitting programming models at work.
A good tool should serve its purpose well, but a good craftsman probably has a very large tool box and picks the right tool for each job. If you have a screwdriver as well as a hammer, you don't have to insert screws like a nail. A programmer who is working on embedded firmware and concerned with things like memory mapped I/O and meeting hard real time constraints is going to have very different priorities to a programmer who writes a lot of CRUD applications to automate business processes and is concerned with implementing things like event-driven user interfaces and DB queries as quickly as possible and in an easily maintainable form. You could write a language with enough features to serve both, but it would be horrendously complicated and feature a diverse range of traps so all types of programmer could get caught in something. Why would you do that? What possible advantage could it offer?