I don't get it, in this scenario, would people also vibe code (the equivalent of) the PHP interpreter?
The one situation where they really can't get anywhere profitable is a unikernel webapp. With no source and no shell they find the vuln but the worst they can do with it is possibly poison or exfiltrate data as a one off, or crash the server. Often they can't even figure that out. Can't even leave themselves a reliable way back in.
Of course the traditional problem with unikernels is that you have to port EVERYTHING you need yourself. But the cheapness of this is exactly what we're talking about so.
Looks like security through obscurity's back on the menu.
But putting ssh for those bounce boxes on a nonstandard port that doesn't even show up to a remote system within the network until they've port-knocked on another two or four ports in the proper order on top of all that does not hurt security. Using a separate internal DNS zone that nobody outside your network has access to resolve doesn't hurt. Having your firewall drop packets from invalid sources instead of rejecting them doesn't hurt.
The language is restricted to permissions granted on startup and can only access the system via the runtime, which only supports a particular subset of linux syscalls. So, outside of the stdlib, whichever feature you need, you simply use an LLM to port an existing python/rust/JS/TS/Java library to the language and use it.
As the runtime has its own scheduler and GC, I have actually been wondering about the feasibility of skipping the linux kernel and making the runtime itself the "os." Given that so much modern hosting is actually done on virtual hardware, the drivers could be hosted within the runtime as well.
- statically typed from end to end
- closed and open/extensible types
- closed types are immutable, open ones have two variants: immutable and mutable
- arrays have two variants: immutable and mutable
- no OOP/classes. inheritance is nominal and mainly exists to provide access to class membership (is X a Y?)
- functions operating on data
- UFCS exists to provide nice features like "apple".substr(...)
- first class functions and closures
- monomorphized generics
- tailcalls
- operator overloading
- modules and namespaces to control access
- erlang/beam style first class processes. So you `spawn` a function and communicate between processes using send/recv instead of async/await
Processes are completely isolated at the runtime level. Each has its own stack, heap, mailbox and GC.
The bytecode carries all type information. The VM will compile using AOT-on-load.
My own runtime-becomes-a-os idea is still just an idea. I haven't really pursued it with seriousness. Will probably do that once the language and runtime stabilize.
I started in March and have gone through nearly 300 spec revisions for the runtime and language. Thanks to LLMs, I think I will have something useful to share in 2027.
My problem is that I have ten things in the pipeline at any given moment and I switch between them as time permits. So things get delayed a bit.
A bare bones microkernel?
The advantage there shouldn't be obscurity, so much as very limited attack surface in the whole exposed stack.
Big picture, I think we should explore what's possible when software is disposable.
Which, probably, you will also have to do.
I suspect that a more effective mitigation to having exploitable bugs would be to have an LLM read all your HTTP requests and the actions the web server proposes to take in response and give a Jev-like approve/disapprove decision.
My point is that everyone doing their own thing their own way means an attacker doesn't get the next thousand sites for free after finding a vulnerability in one site.
Having an LLM as sentry is a fun idea too.
Genetic monocultures like bananas are at risk from a single species of fungus.