Oh good. Though it's a shame that the test suite is a `test.py` file instead of `cargo test`; it would have been extremely satisfying to know that the Rust project would run the test suite for an INTERCAL compiler on a regular basis as part of Crater.
Yes, I find that The Dragon Book to be a fundamental reference in my university days of studying compilers. Even so, many sections of it are still relevant to this day.
Also, I think I might have seen your name before whilst looking at the Solaris port of Go years back. Mind you, I'm looking at bringing Golang to Haiku (0) with similar changes like Solaris and Windows.
This is very interesting as this is almost identical to how the Haiku Operating System does package management using their own packaging format (hpkg) which uses packagefs. [0] [1]
This format is used more than just to package applications, but to update the whole OS in a consistent manner [2] as it is also versioned in with shared-libraries and this was implemented in 2013.
I haven't implemented PASETO but I was thinking about adding support for another language. If I were to implement it, I would just use libsodium for most of the cryptographic primitives whenever possible since the reference PASETO implementation uses it as well as most of the other language implementations too (Except for the Go version).
PASETO does seem like a cryptographic secure alternative that addresses the pitfalls of the JOSE standard and has most of the mitigations mentioned in this blog-post (No cryptographic-algorithm agility) and it supports the same functionalities of JWT/JWE and JWS. So I am convinced on getting that standardized, but it also needs XChaCha20-Poly1305 AEAD to be standardized too [0].
Fernet was also around as being a secure alternative, but it has been mostly replaced by Branca [1] and PASETO.v2.
As for virtualization, Fuchsia already has its own KVM equivalent called Machina which so far can run Debian on top of Zircon and with several compatibility changes for supporting the ART runtime in Zircon already merged in, it should be also possible to run Android apps with this.
But perhaps the reason Fuchsia won't struggle unlike the other OSes you mention, is that it is possible that it will be compatible to run all the Android apps in the play store from day one, thanks to Machina; allowing a smoother transition, a process similar to what Apple did with the PowerPC to X86 switch but in Google's case, its for a completely different OS.
Well XNU has always been 'open-source' [1] for some time on Intel machines but its just that ARM support remained closed (until 2017) which is why the darwin-on-arm [2] project existed. But I'm assuming that the OP means that the ARM64 code was recently open-sourced in the XNU sources[3] making a possible open-source ARM port much simpler. I still find it quite interesting to see some regained attempts in emulating iOS; with Corellium being the furthest at doing this.
Well Zircon (Fuchsia's kernel) doesn't have any Rust code inside of it; it's C++. Parts of rust code used in Fuchsia can be found in the Garnet layer and it is just one of the languages that can interface with the OS via the FIDL (Fuchsia Interface Definition Language) [0][1]. An example of this is a tool written in Rust that communicates with parts of the bluetooth stack[2]. The network stack is also using it and is written in Go. [3]
