> reflects the software engineering philosophies of the 1980s.
It has a microkernel architecture. That's already an improvement over the "modern" monolithic kernels we are stuck with today. Given Big Tech's interest in hardening security and sandboxing you'd think this would get more attention.
True but it's not exactly new. I remember Andrew Tanenbaum and Linus Torvald's heated discussions in the early 90s :) Minix featured a microkernel before linux existed.
Yeah, but we are still far off making it mainstream beyond some key use cases, QNX, INTEGRITY, language runtimes on top of type 1 hypervisors, all kernel extension points being pushed into userspace across Apple,Google,Microsoft offerings, Nintendo Switch,....
Given the tectonic shift in priorities for Linux kernel development over the past decade, I'm willing to bet that many key developers would be open to a microkernel architecture now than ~25+ years ago. CPUs now have hardware features that reduce the overhead of MMU context changes which gets rid of a significant part of the cost of having isolated address spaces to contain code. The Meltdown and Spectre attacks really forced the security issue to the point where major performance costs to improve security became acceptable in a way that was not the case in the '90s or '00s.
I'm being pedantic, but on modern hardware, the ISA is an abstraction over microarchitecture and microcode. It's no longer a 1-to-1 representation of hardware execution. But, as programmers, it's as low as we can go, so the distinction is academic.
In a well-functioning competitive market, no company should be able to rest on its laurels. The problem is industries have consolidated and trustbusters are nowhere to be found.
Notice when tech is new (the web, smart phones, AI) there's an initial burst of competitive companies? That's because the market hasn't consolidated yet. Ask yourself how many dot-com millionaires would realistically be able to duplicate their success in 2026, given the same product but launching today.
Aside from consolidation, discoverability is a huge problem, especially in the era of AI slop. Building a superior product is easy, getting it noticed and building traction is hard.
I'm flabbergasted why anyone would voluntarily vibe code anything. For me, software engineering is a craft. You're supposed to enjoy building it. You should want to do it yourself.
I absolutely love programming. I enjoy creating software, trying out new languages and systems, creating games during my free time.
And I also might "vibe code" when I need to add another endpoint on a deadline to earn a living. To be fair - I review and test the code so not sure it's really vibe coding.
Not everything can be built by one person. This is why a lot of software requires entire teams of developers. And someone has to have vision of that completed software and wants it made even if they had to delegate to other people. I hate to think that none of these people enjoy their job.
Do you honestly get satisfaction out of writing code that you've written dozens of times in your career? Does writing yet another REST client endpoint fill you with satisfaction? Software is my passion, but I want to write code where I can add the maximum value. I add more value by using my experience solving new problems that rehashing code I've written before. Using GenAI as a helper tool allows me to quickly write the boilerplate and get to the value-add. I review every line of code written before sending it for PR review. That's not controversial, it's just good engineering.
Sounds like eventually we will end up in a situations where engineers/developers will end up on an AI spectrum:
- No ai engineers
- Minimal AI autocomplete engineers
- Simple agentic developers
- Vibe coders who review code they get
- Complete YOLO vibe coders who have no clue how their "apps" work
And that spectrum will also correlate to the skill level in engineering: from people who understand what they are doing and what their code is doing - to people who have lost (or never even had) software engineering skills and who only know how to count lines of code and write .md files.
> like nearly all other datetime APIs, has 0 support for querying leap-second information
That's probably because you only need leap second accuracy in niche use cases, like astronomy or GPS. In JavaScript specifically, that kind of accuracy isn't needed for 99% of client-side use cases. Most date-time libraries work with POSIX time which assumes 86,400 seconds each day.
If you trained on a neutral representation like an AST or IR, then the source language shouldn't matter. *
* I'm not familiar with how Anthropic builds their models, but training this way should nullify PL differences.
reply