Hacker News new | ask | show | jobs
by olliej 1243 days ago
Fuchsia is (was?) a long term investment, so would be expected to not be directly profitable for a long time.

The core problem I guess is that it suffers from an inability to partially migrate to it. This is a common problem that many people fail to understand actually matters. For example, we know rust is a safer language than C and C++, and so people say "all should be rewritten in rust", but rust is designed with no intent or plan to support partial migration. What that means is that even Mozilla - who created rust specifically for gecko - has been unable to replace the bulk of their code with rust: they can only replace entire large subsections at a time, which is harder, riskier, and as a result slower. Fuchsia's (I guess Zircon's) adoption is hindered because the objectively superior security model also meant that none of the infrastructure around the linux kernel say could work with it, so feature parity required at best significant porting, but frequently complete rewrites of large swathes of the surround infra. e.g. porting android to zircon (the fuchsia kernel) would require significant rewriting of the existing code bases, and the time spent doing that is not time spent adding shiny new features and animations (or chat programs?). Apple is generally much more pragmatic which is why Swift had such good objc and C interop from day 1, and why real C++ interop is something it's working on: if fixing C++ projects can only be done by all-at-once complete rewrites you basically ensure the C++ will live forever - rewriting a file at a time however is much more achievable, which is personally what I want (as for Swift vs rust I'm on the fence I like different parts of both, and also c++ :D).

1 comments

This is very false. Fuchsia is built around the idea of making it easy to port software. It just doesn't attempt to achieve it by providing a POSIX interface. POSIX doesn't specify the vast majority of interfaces a modern OS needs to define anyways. For instance you won't see POSIX interfaces that tell you that provide you a signal for when memory on the system is low and you should free up memory.

Instead Fuchsia tries to target porting runtimes which applications are built against. For instance, porting chrome as a runtime unlocks web applications. Porting flutter unlocks flutter applications. Porting Android as a runtime is challenging but still achievable. It is not necessary to rewrite all of Android to accomplish this either.

At the extreme, it's possible to simply implement runtime support by implementing various virtio interfaces and running a full OS in a VM, similar to how other OS like ChromeOS and Windows achieve Android app support today. Fuchsia is written in a way that you don't need to do that, but it's always an option as well.