cyclone VS gvisor

One of the inspirations for Rust, as I recall, was Cyclone: https://cyclone.thelanguage.org/

Which was/is a "safe" dialect of C; basically C extended with a bunch of the stuff that made it into Rust (algebraic datatypes, pattern matching, etc.) Though its model of safety is not the borrow checker model that Rust has.

Always felt to me like something like Cyclone would be the natural direction for OS development to head in, as it fits better with existing codebases and skillsets.

In any case, I'm happy to see this stuff happening in Rust.

It sounds like they re-invented Cyclone.

https://cyclone.thelanguage.org

Looks like it was a research project and is now abandoned: http://cyclone.thelanguage.org

The borrow checker is Rust's secret sauce. It's the one thing no other language has. (Except Cyclone I think, which is an unmaintained research language.)

Also, lifetimes are not the mechanism by which Rust ensures safety - it's a necessary side-effect of the approach that Rust has taken, and this has nothing to do with the issues that "plague" other languages. Region-based memory management techniques are neither new nor really innovative. https://cyclone.thelanguage.org/, which directly inspired Rust, had them, and the authors gave up working on it because the ergonomics were terrible, as is the case with Rust. Lifetimes are needed for the Rust compiler to reason about what it can reasonably allow at compile time, but it, along with the Borrow Checker (which provides the actual safety net) ensures that whole swathes of valid programs are disallowed because the Rust compiler is not smart enough (and probably never will be) to check that these programs are valid.

Isn't gVisor kind of this as well?

"gVisor is an application kernel for containers. It limits the host kernel surface accessible to the application while still giving the application access to all the features it expects. Unlike most kernels, gVisor does not assume or require a fixed set of physical resources; instead, it leverages existing host kernel functionality and runs as a normal process. In other words, gVisor implements Linux by way of Linux."

https://github.com/google/gvisor

This sort of feels like seeing someone riding a bike and saying: why don’t they just get a car? The simple fact is that containers and VMs are quite different. Whether something uses VMX and friends or not is also a red herring, as gVisor also “rolls it own VMM” [1].

[1] https://github.com/google/gvisor/tree/master/pkg/sentry/plat...

There's two major production-ready Go-based operating system(-ish) projects:

- Google's gVisor[1] (a re-implementation of a significant subset of the Linux syscall ABI for isolation, also mentioned in the article)

- USBArmory's Tamago[2] (a single-threaded bare-metal Go runtime for SOCs)

Both of these are security-focused with a clear trade off: sacrifice some performance for memory safe and excellent readability (and auditability). I feel like that's the sweet spot for low-level Go - projects that need memory safety but would rather trade some performance for simplicity.

[1]: https://github.com/google/gvisor

[2]: https://github.com/usbarmory/tamago

It uses gVisor to create a TCP/IP stack in userspace, and starts a wireguard interface on it, which the HTTP server from http.Serve listens on. The library will print a URL after startup, where you can access your server. You can create multiple listeners in one binary.

The playground compiles the program with GOOS=linux, GOARCH=amd64 and runs the program with gVisor. Detailed documentation is available at the gVisor site.

You could use a container sandbox like gVisor, light virtual machines as containers (Kata containers, firecracker + containerd) or full virtual machines (virtlet as a CRI).