7 ms·
Per a talk from Joshua Liebow-Feeser at the Rust Belt Rust 2018 conference, Google is heavily using Rust for networking in their new Fuchsia operating system.
by dswalter 8y ago
Per a talk from Joshua Liebow-Feeser at the Rust Belt Rust 2018 conference, Google is heavily using Rust for networking in their new Fuchsia operating system.
This is a rough approximation of a quote he gave during the talk:
"What makes Rust different is not that you can write high-performance, bare-metal code. People use C and C++ to do that all the time. What makes Rust different is that when you write that code, it is safe, clean, and easy to use, and you are confident in its correctness."
If even Google is using Rust for performance-critical development, that seems pretty promising to me.
- daveoflynn 8y agoHere are Joshua’s slides from the talk mentioned above: https://joshlf.com/files/talks/Move%20Fast%20and%20Don't%20Break%20Things.pdf https://joshlf.com/files/talks/Move%20Fast%20and%20Don't%20B...
- Numberwang 8y agoIs this on YouTube? I can't find the talk.
- shepmaster 8y agoNot yet. I'm slowly putting them together and really hope to have them uploaded by the end of the year. You can follow our channel[1], which should (?) notify you when this year's videos are published. [1]: https://www.youtube.com/channel/UCptxtVyJkQAJZcFwBbIDZcg https://www.youtube.com/channel/UCptxtVyJkQAJZcFwBbIDZcg
- mav3rick 8y agoThe Chrome OS team is writing Rust for it's Crostini project as well.
- erwan 8y agoFuschia seem more like an experiment in object-capabilities design rather than "performance-critical development" to me.
- Cmerlyn 8y agoWouldn't an operating system be a performance-critical piece of software despite being an experiment in object-capabilities design?
- derefr 8y agoObject-capabilities design might be a net performance win, despite its overhead, if it can obviate some/all layers of “workload-oblivious” sandboxing (e.g. VM hypercalls, container network sandboxing, ring0–3 context switching, separate process memory maps with associated TLB cache flushes, etc.) Capability checks can be optimized away when you (the program loader, e.g. the kernel) know they’re not necessary; while you can never transparently optimize a syscall or hypercall into a regular function call. Ideally, under a capability-based OS, you can just have a unikernel that directly loads user-supplied(!) modules in a bytecode format where instructions have capability-checking as an intrinsic; and then, after performing static analysis on those modules to guarantee that they don’t do anything crazy, the kernel module loader can JIT them into native code that doesn’t need to do the capability checks. Basically like if the entire userland consisted of ePBF programs—but with higher-level exposed semantics that allow for rich access to kernel structures, rather than just their handles. Plus, you also get the benefit of safe sharing of higher-level data abstractions. A “native” userland process has to make syscalls using, at most, registers containing pointers to strings or fixed-size non-polymorphic structs. A capability-based userland module, meanwhile, could interact with the kernel even through reads and writes to a shared-memory tree or hashmap. Essentially, with capabilities, you get all the benefits of every program having the same low-overhead access to the kernel that a kernel driver does, with none of the drawbacks of having to guard against corrupting the kernel’s state.
- monocasa 8y agoThose aren't mutually exclusive. Object capabilities are a core part of what makes the L4s faster than Mach. Mach had to do a permissions check on every IPC message since the port table is global. And since it was global, practically that was an expensive ACL check. You don't even have to do a full permissions check on capability endpoints since the mere fact that you have a handle to it is proof of that you have the appropriate permissions.
- Thaxll 8y agoIsn't the networking stack of Fuchsia written in Go? https://fuchsia.googlesource.com/garnet/+/master/go/src/netstack/ https://fuchsia.googlesource.com/garnet/+/master/go/src/nets... https://github.com/fuchsia-mirror?language=go https://github.com/fuchsia-mirror?language=go I'm pretty sure Go is the dominant language for networking in Fuchsia and not Rust.
- DougBTX 8y agoLinks in the presentation point here: https://fuchsia.googlesource.com/garnet/+/master/bin/recovery_netstack/core/src/ https://fuchsia.googlesource.com/garnet/+/master/bin/recover...
- deleted 8y ago[deleted]
- derefr 8y agoDifferent layers, perhaps? The DMAing around of physical packets, and the parsing of ARP/IP/TCP headers, require different safety guarantees.
- squeed 8y agoThey're phasing much of the go and replacing it with rust.
- nine_k 8y agoHey, Google is becoming an interesting place to work again! :) (Only partly a joke.)
- kenhwang 8y agoI'd work for Google if they'd offered me a Rust job :) Too bad the odds are 10000:1 that I get stuck doing Java/Go instead.
- steveklabnik 8y agoYou can apply directly to the fuschia team, in my understanding. They put an email at the end of talks usually with where to apply.
- monocasa 8y agoCan you give an example? My Google Fu is failing me at the moment. Fuschia/Rust is about the only thing I'd do at Google.
- steveklabnik 8y agoThe one I’ve seen is fuchsiajobs@google.com
- r00fus 8y agoI know people who have gone through the their hiring process, and they were sufficiently unsure if they would ever get on the team they applied for. There's also the story of the Google+ UI lead who though he'd be working on another Google product, then got reassigned before he was even hired into G+ and hated his entire 9mo having never even met with Vic the VP driving G+. Does that still happen?
- steveklabnik 8y agoI have no idea, I’ve never worked for or even applied at google.