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 On Sunday, 9 May 2021 at 08:40:52 UTC+1 Uli Kunitz wrote: > 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 > > On Saturday, May 8, 2021 at 11:28:54 PM UTC+2 xiao...@gmail.com wrote: > >> 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 >> <https://security.googleblog.com/2021/04/rust-in-android-platform.html> >> and Rust in the Linux kernel >> <https://security.googleblog.com/2021/04/rust-in-linux-kernel.html>, and >> Rust even got Rust foundation that Google, Amazon, Microsoft joined, with >> recently Facebook Joins the Rust Foundation >> <https://developers.facebook.com/blog/post/2021/04/29/facebook-joins-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 >> <http://cncf.io/> 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. >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/31f41eac-35ac-4898-924a-35a750ff5031n%40googlegroups.com.
