Reflect on Rust for Android and Linux kernel support

[winn]

Hi, I may not well thought about this, hope someone else here can take this seriously and have some change( say invest more on some area: kernel, android, the area that Rust can do, etc ) or something else change maybe.

You can take this as a feedback.

I've see Rust in the Android platform  and Rust in the Linux kernel, and Rust even got Rust foundation that Google, Amazon, Microsoft joined, with recently Facebook Joins the Rust Foundation joined.

Here I've got some question, forgive me if I'm just stupid to understand the situation

1. What things that Rust can do, and Go can't ( even do better ), to get them select Go as better choice.

2. Should we have a foundation rather than  pure opensource. so to get better support from all big company( officially ). I see CNCF foundation is a good example( can we learn something from it).  So to have better ecosystem, that the language choice decision is not based about ecosystem but pure language choice( Say if Linux Kernel or Android doesn't support Go, people intuitively choose supported Rust), ecosystem is a big factor I think.

I love Go's simplicity and I'm surprised that they choose Rust first for that much of hard to learning language, at least not as Go's elegance and simplicity I think.

They often cite that Go is a GC language, I've known that it can turn off. and even no GC at all. in my thinking they both can solve the same kind of problem( using CGO etc) and so I don't understand their decision.

And the purpose of this post is to have someone thought about how can we do better? 

I'm sorry to raise this comparing, my point is more about how to make Go better(I'd expect someone to really thinking about it).

I'd want to see Go thrive as everyone here does.

Best regards.

[Uli Kunitz]

There are multiple differences that make Rust a better replacement for C/C++ code than Go:

* Go requires a garbage collector and its own scheduler (A Go without GC and goroutines is not Go.)

* Go has its own ABI and CGO calls are slow

* Rust makes guarantees about memory safety that Go doesn't do. 

While there are already experimental Linux kernel modules in Rust, I have only read about researchers who wrote a whole kernel in Go. But a new kernel requires an ecosystem and it is hard to see, how the industry as a whole will support this. So you would need to write Linux kernel modules in Go and it would need to have advantages over kernel modules in Rust. It is hard to see how this will come about.

There is now a group of developers working to integrate Rust with the kernel. But they also have challenges like panics in the Rust core libraries and the plan to interact with the Linux kernel through a safe API. I guess it will take still a year or two before Rust code has been merged into the Linux mainline kernel. At this point, it is not obvious whether the majority of new code will be written in Rust or C for the Linux kernel 10 years from now. 

I don't know anything about the reasons and drivers for the Rust Foundation, but having observed the open-source landscape for the last 30 years I can say the following. Foundations usually address two main issues: funding of the core development team and addressing intellectual property rights issues.  Go is very well funded by Google, so this is not a driver. Google has pooled patents with IBM and others for open source in the Open Invention Network and is able to fund litigation up to the Supreme Court of the United States. So legal issues are also no reason for a foundation. There could be a third objective for a foundation, which would be community governance of the Go development, but the proposal process works well and I cannot see, how a foundation would improve it.  This doesn't say a foundation may be required in the future, but right now the usual drivers don't apply.

Greetings,

UIi

[Amnon]

I would agree with all Uli's points. 
I would add that not that many kernel developers - around 15,000
and most of these just write device drivers.
So kernel development is very much a niche occupation.
C as a very low level language - basically a pretty assembler, with no runtime, is ideally suited to Kernel development.
Adapting the Kernel to allow development in a higher level language with GC is not trivial. For one thing, 
Kernel code needs to deal with different kinds of memory allocations, different kinds of memory and different address spaces.

I have not been following the discussions on the Kernel mailing lists for many years, so I am not sure what problem enabling Rust 
to be used inside the Kernel will solve. But if Kernel developers want to do the work to enable
Rust to be used for Kernel development, then all power to them.

Go was never meant to be all things to all people, and in an ideal world people will use the tool most suited to the job.
Go benefits from having a very clear vision, and being designed to solve a specific problem (server/cloud programming).
And Go's growth over the years suggests that it does this well.
Diluting this vision in order to cover more niche areas might not improve the language.

- amnon

[winn]

Thanks Uli and Amnon.

I'm now better understand the reason behinds, and you've list some solid point. and it's reasonable for it to work that way.

I'm here just list some possibilities:

> 1. * Go requires a garbage collector and its own scheduler (A Go without GC and goroutines is not Go.)

> 2. * Go has its own ABI and CGO calls are slow

> 3. * Rust makes guarantees about memory safety that Go doesn't do.

for 1: Is it possible that some flag or switch to enable different GC, which behavior similar to Rust.

for 2: Is it possible to make it faster.

for 3: Is it possible that Go can provide memory safety.

> Go was never meant to be all things to all people, and in an ideal world people will use the tool most suited to the job.

I guess someone may want it work more area(similar to rust to system programming?)

> Go benefits from having a very clear vision, and being designed to solve a specific problem (server/cloud programming).

Is it possible to have wider vision( that cover system programming? if I understand correctly, above issue is relate to that area), since Go is a system programming language from beginning, later changed to general programming language.

> Diluting this vision in order to cover more niche areas might not improve the language.

Is it possible for a way to not diluting this vision, and have it cover more niche(out of tree developing, etc) ?.

I realized that I want Go to cover more niche, I don't know if there's lack of resource so that Go can only pick certain area(server/cloud programming), would foundation help about this?

I would love to see Go have a nice way( genius way) to keep current elegance and simplicity and have more niche covered.

- winn

[peterGo]

On Sunday, May 9, 2021 at 3:40:52 AM UTC-4 Uli Kunitz wrote:

I have only read about researchers who wrote a whole kernel in Go.

UIi

The benefits and costs of writing a POSIX kernel in a high-level language
Cody Cutler, M. Frans Kaashoek, and Robert T. Morris, MIT CSAIL
https://www.usenix.org/conference/osdi18/presentation/cutler
https://pdos.csail.mit.edu/papers/biscuit.pdf

Biscuit research OS
Biscuit is a monolithic, POSIX-subset operating system kernel in Go for x86-64 CPUs. It was written to study the performance trade-offs of using a high-level language with garbage collection to implement a kernel with a common style of architecture.
https://github.com/mit-pdos/biscuit

Peter