These last few months, I have been building a capability-based language and runtime for fun based on the "port EVERYTHING" idea.

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.

▲

kragen an hour ago | parent [-]

That's exciting! I'm interested to hear about the language design. I vibecoded a unikernel web server a few weeks ago, and I've been trying to extend it into a full capability-secure microkernel called KokalOS.

	▲	sieve 26 minutes ago \| parent [-]
		The language borrows syntax from Python (and a wee bit from Haskell) and is essentially syntactic sugar over facilities provided by the runtime: - 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.