Aleph lacked GC, which Rob Pike considered the main reason for its implementation failure on Plan 9, and initially bounds checking was also missing.
Two key design difference from Go and its two predecessors.
Dis is an implementation detail, Go could offer the same dynamism with AOT toolchain, as proven by other languages with ahead of time toolchains available.
I don't know. I use a lot of Swift and C++ and while both are OK languages there is an absurd amount of complexity in these languages that doesn't seem to serve any real purpose. Just a lot of foot traps, really.
Coming back to Plan9 from that world is a breeze, the simplicity is like a therapy for me. So enjoyable.
If "modern" means complex, I don't think it fits Plan9.
AFAIK there is no Rust compiler for Plan 9 or 9front. The project is using a dialect of C and its own C compiler(s). I doubt adding Rust to the mix will help. For a research OS, C is a nice clean language and the Plan 9 dialect has a some niceties not found in standard C.
If you really want Rust, check this https://github.com/r9os/r9 it is Plan 9 reimplemented in Rust (no idea about the project quality):
R9 is a reimplementation of the plan9 kernel in Rust. It is not only inspired by but in many ways derived from the original Plan 9 source code.
ZeroFS [0] is very thankful for what it brought to Linux with the v9fs [1] subsystem which is very nice to work with (network native) compared to fuse :)
Is there Plan9 port for RISC-V (RV32I) ?
People wanting a Retina-capable drawterm to access Plan9/9front from their Macs are welcome to have a look at https://github.com/rcarmo/drawterm
Ooh la la
The transition step between UNIX and Inferno, and between C and Limbo as main userspace language, by its authors.
Which tends to be forgotten when praising Plan 9.
Is it correct to say Golang is bringing Limbo to the masses?
No, it's bringing Aleph to the masses. Limbo is a cousin, and Dis was certainly very interesting and something I wish had caught on.
Aleph lacked GC, which Rob Pike considered the main reason for its implementation failure on Plan 9, and initially bounds checking was also missing.
Two key design difference from Go and its two predecessors.
Dis is an implementation detail, Go could offer the same dynamism with AOT toolchain, as proven by other languages with ahead of time toolchains available.
Partially, Go still doesn't support a few Limbo features.
However the influence is quite clear, plus the Oberon-2 style methods and SYSTEM package.
>9front.org frequently questioned answers
Knowing that project am I going to be rickrolled?
I would love to see more Rust on Plan9 implementations, IMHO, could be a good modern combination.
I don't know. I use a lot of Swift and C++ and while both are OK languages there is an absurd amount of complexity in these languages that doesn't seem to serve any real purpose. Just a lot of foot traps, really. Coming back to Plan9 from that world is a breeze, the simplicity is like a therapy for me. So enjoyable.
If "modern" means complex, I don't think it fits Plan9.
AFAIK there is no Rust compiler for Plan 9 or 9front. The project is using a dialect of C and its own C compiler(s). I doubt adding Rust to the mix will help. For a research OS, C is a nice clean language and the Plan 9 dialect has a some niceties not found in standard C.
If you really want Rust, check this https://github.com/r9os/r9 it is Plan 9 reimplemented in Rust (no idea about the project quality):
R9 is a reimplementation of the plan9 kernel in Rust. It is not only inspired by but in many ways derived from the original Plan 9 source code.
I’m fairly sure that Rust compiler is bigger than the entire 9front (and 9front has Doom in it).
Since Rust depends on LLVM, which is massive, that is almost certainly true. It seems likely even if you don't include LLVM though.
ZeroFS [0] is very thankful for what it brought to Linux with the v9fs [1] subsystem which is very nice to work with (network native) compared to fuse :)
[0] https://github.com/Barre/ZeroFS
[1] https://docs.kernel.org/filesystems/9p.html