4 ms·

Fuchsia network stack is also being rewritten from Go to Rust [1] and it follows a functional core/imperative shell pattern, something very unusual in network s

Fuchsia network stack is also being rewritten from Go to Rust [1] and it follows a functional core/imperative shell pattern, something very unusual in network stacks [2]: [1] https://fuchsia.dev/fuchsia-src/contribute/contributing_to_netstack3 https://fuchsia.dev/fuchsia-src/contribute/contributing_to_n... [2] https://cs.opensource.google/fuchsia/fuchsia/+/master:src/connectivity/network/netstack3/docs/CORE_BINDINGS.md https://cs.opensource.google/fuchsia/fuchsia/+/master:src/co...

jillesvangurp 6y ago
Interesting; makes you wonder about the potential for code sharing between that and Android or even linux as well. The Linux kernel developers are open to allowing some Rust usage for things like drivers at this point. So the time seems right for this kind of thing. I guess there is also some decent code from e.g. redox os that might be adapted. Licensing (MIT) should not be an obstacle for this as far as I understand it. Likewise Fuchsia also uses GPL2 compatible licenses (MIT, Apache2, BSD). So, there's some potential to avoid reinventing a few wheels across these platforms. At face value, protocol stacks such as TCP/IP or bluetooth, are great use cases for a language like rust in a resource constrained environment (battery, CPU) where you are looking to get high throughput, low latency, etc combined with decent zero cost abstractions so you can make some strong guarantees about e.g. correctness. A good high level implementation, might be usable across different OS kernels. Of course these kernels have very different designs so it might make less sense at the code level than I imagine. I do wonder about where Google is headed with Fuchsia. Do they have a plan at this point for getting OEMs to want to switch to that? I imagine e.g. Samsung might have some hesitations about being even more dependent on Google as a supplier.
- yjftsjthsd-h 6y ago
  > I imagine e.g. Samsung might have some hesitations about being even more dependent on Google as a supplier. Does it make them more dependent? Google is effectively the only upstream for Android, and Fuchsia is open source, so it seems like it should be the same?
  - jillesvangurp 6y ago
    One of them is based on mobile linux; which Samsung also uses for things like Bada and which has a lot of hardware vendors supporting it with drivers; including Samsung itself of course. Bada actually originated out of Nokia's Meego and Maemo mobile OS. That predates Android and early Android versions ran pretty much the same Linux kernels. The first devices running Android were actually Nokia N800s before they did the first Nexus. Fuchsia is open source but closed source friendly (because of the license). I suspect that's actually the main non technical argument for Google to be doing this: Android is too open and they've been trying to fix that for years. Apple has a similar benefit with the BSD internals of IOS and OSX. Still OSS in part but mostly not and Apple has not bothered with supporting separate Darwin releases for a long time. So, like with Android, I'd expect a fair amount of closed source secret sauce is going to be needed to run Fuchsia. More rather than less. I doubt Google free versions of Fuchsia are going to be a thing like it is a thing with Android. Google is doing this to take more control of the end user experience. Just like Apple does with IOS. Letting Samsung (or anyone) bastardize that is not really what they want here. I'm guessing, Samsung actually wants less of that Google secret sauce at this point rather than more. They are trying to differentiate with exclusive features, their own UX, their own apps, and services, etc. I'm expecting a lot of OEMs are going to have a similar mindset. Especially the Chinese ones currently shipping flavors of Android without a Google license for the play services on the wrong side of the current trade wars (like Huawei). Google has got their work cut out there trying to get OEMs like that to swallow Fuchsia. I think, Google is going to end up supporting Android for a long time because of this even if they eventually launch Fuchsia (which in my opinion is not a certainty yet). The simple reason for this is that the alternative would be walking away from a chunk of the mobile market that they currently exploit via their play store. I don't see them surrendering that and I don't think they would want third parties to continue releasing Android without Google either. So, the only way to prevent that would be a long term Android development strategy regardless of whether they actually release Fuchsia or not. So, reusing code across Android and Fuchsia makes a lot of sense.
    - pjmlp 6y ago
      Bada doesn't have anything to do with Linux, at all. It was a OS using a stack similar to Symbian. You mean Tizen. Which, just like Android, the only thing it shares with Linux, is the Linux kernel, now having its own C++ stack, .NET Core/Xamarin and there are still some Englightment leftovers.
PragmaticPulp 6y ago
> Fuchsia network stack is also being rewritten from Go to Rust This Android Bluetooth stack is mostly in C++. Only part of it (about 4K lines) is written with Rust. The headline is misleading.

jillesvangurp 6y ago

Interesting; makes you wonder about the potential for code sharing between that and Android or even linux as well. The Linux kernel developers are open to allowing some Rust usage for things like drivers at this point. So the time seems right for this kind of thing. I guess there is also some decent code from e.g. redox os that might be adapted. Licensing (MIT) should not be an obstacle for this as far as I understand it. Likewise Fuchsia also uses GPL2 compatible licenses (MIT, Apache2, BSD). So, there's some potential to avoid reinventing a few wheels across these platforms. At face value, protocol stacks such as TCP/IP or bluetooth, are great use cases for a language like rust in a resource constrained environment (battery, CPU) where you are looking to get high throughput, low latency, etc combined with decent zero cost abstractions so you can make some strong guarantees about e.g. correctness. A good high level implementation, might be usable across different OS kernels. Of course these kernels have very different designs so it might make less sense at the code level than I imagine. I do wonder about where Google is headed with Fuchsia. Do they have a plan at this point for getting OEMs to want to switch to that? I imagine e.g. Samsung might have some hesitations about being even more dependent on Google as a supplier.

yjftsjthsd-h 6y ago
> I imagine e.g. Samsung might have some hesitations about being even more dependent on Google as a supplier. Does it make them more dependent? Google is effectively the only upstream for Android, and Fuchsia is open source, so it seems like it should be the same?
- jillesvangurp 6y ago
  One of them is based on mobile linux; which Samsung also uses for things like Bada and which has a lot of hardware vendors supporting it with drivers; including Samsung itself of course. Bada actually originated out of Nokia's Meego and Maemo mobile OS. That predates Android and early Android versions ran pretty much the same Linux kernels. The first devices running Android were actually Nokia N800s before they did the first Nexus. Fuchsia is open source but closed source friendly (because of the license). I suspect that's actually the main non technical argument for Google to be doing this: Android is too open and they've been trying to fix that for years. Apple has a similar benefit with the BSD internals of IOS and OSX. Still OSS in part but mostly not and Apple has not bothered with supporting separate Darwin releases for a long time. So, like with Android, I'd expect a fair amount of closed source secret sauce is going to be needed to run Fuchsia. More rather than less. I doubt Google free versions of Fuchsia are going to be a thing like it is a thing with Android. Google is doing this to take more control of the end user experience. Just like Apple does with IOS. Letting Samsung (or anyone) bastardize that is not really what they want here. I'm guessing, Samsung actually wants less of that Google secret sauce at this point rather than more. They are trying to differentiate with exclusive features, their own UX, their own apps, and services, etc. I'm expecting a lot of OEMs are going to have a similar mindset. Especially the Chinese ones currently shipping flavors of Android without a Google license for the play services on the wrong side of the current trade wars (like Huawei). Google has got their work cut out there trying to get OEMs like that to swallow Fuchsia. I think, Google is going to end up supporting Android for a long time because of this even if they eventually launch Fuchsia (which in my opinion is not a certainty yet). The simple reason for this is that the alternative would be walking away from a chunk of the mobile market that they currently exploit via their play store. I don't see them surrendering that and I don't think they would want third parties to continue releasing Android without Google either. So, the only way to prevent that would be a long term Android development strategy regardless of whether they actually release Fuchsia or not. So, reusing code across Android and Fuchsia makes a lot of sense.
  - pjmlp 6y ago
    Bada doesn't have anything to do with Linux, at all. It was a OS using a stack similar to Symbian. You mean Tizen. Which, just like Android, the only thing it shares with Linux, is the Linux kernel, now having its own C++ stack, .NET Core/Xamarin and there are still some Englightment leftovers.

PragmaticPulp 6y ago

> Fuchsia network stack is also being rewritten from Go to Rust This Android Bluetooth stack is mostly in C++. Only part of it (about 4K lines) is written with Rust. The headline is misleading.