Given development speed is way up, I'd be interested to see what a from-basic-principles simple and efficient OS and programming system might look like. Or people trying radically different versions of efficiency and simplicity, like an OS that uses an existing battle-tested sandboxed execution environment like v8 for userspace safety/isolation.
Fundamentally, many inefficiencies were justified for developer productivity, and I'm not sure that makes sense anymore, and the cost of larger projects with clear abstraction boundaries has plummetted.
This is the thing - when the cost of iterating and grinding compiler warnings drops to virtually 0, what new paradigms might we invent to exploit that? Rust gives us an inkling of an idea of what might be possible, but that still predates LLMs and thus still makes concession for human ergonomics. What are structures, guardrails, and patterns, that our OSs, frameworks, and toolchains can put in place, which would result in whole classes of problems going away completely, at the expense of massively increased (but mechanical, and easily automatable with a prompt) developer effort?
>Fundamentally, many inefficiencies were justified for developer productivity, and I'm not sure that makes sense anymore
Having lived through this period, I would disagree, quite the opposite we tended to develop in C and assembly specifically for runtime efficiency because we had to.
For developer productivity you could opt for Lisp or SmallTalk or some such, which ran much slower until high quality compilers for these became available, and even then your target machine might only have a C compiler.
I read GP's comment differently, that we ended up where we are today (bloated languages, IDEs and runtimes) due to chasing developer productivity at all costs.
Now, developer productivity is becoming less important as developers are factored out entirely.
This was my intended meaning -- the clearest advocacy of this was from DHH about Ruby on Rails, although he's changed his mind about big questions lately and suspect he no longer endorses that set of trade-offs (I don't either, _sort of_ -- I think developer productivity means having simple ways to enable large-scale testing and oversight while minimizing context switching costs, although I think we are all figuring out what that means in practice).
v8 is pretty complicated, and anything that depends on LLVM is going to be huge, so I think I would start smaller. You could try building around something like NuttX or an L4 + tcc or cproc and see what it takes to get to self-hosting as well as ability to do some job you care about. To me the bigger question is that last bit, you can shrink the platform code quite a lot relative to a typical Linux but what's the situation where that's a good trade vs say cross-compiling from a full C++ or Rust toolchain?
Fundamentally, many inefficiencies were justified for developer productivity, and I'm not sure that makes sense anymore, and the cost of larger projects with clear abstraction boundaries has plummetted.
The next few years are going to be fun.
Having lived through this period, I would disagree, quite the opposite we tended to develop in C and assembly specifically for runtime efficiency because we had to.
For developer productivity you could opt for Lisp or SmallTalk or some such, which ran much slower until high quality compilers for these became available, and even then your target machine might only have a C compiler.
Now, developer productivity is becoming less important as developers are factored out entirely.
It's the lack of clear abstraction boundaries that causes decreased developer productivity.
A code generator will not save you from Conway's law.