Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Retiring from the Rust for Linux Project – Wedson Almeida Filho

lore.kernel.org

Post reply on HN
Print view View original

91–100 of 107 posts

Re: Retiring from the Rust for Linux Project – Wedson Almeida Filho

#91

Post by MiguelX413 »

rc00 wrote: post #54

I'm at the point of wishing for the Rust experiment in the Linux kernel to be over. It's become an over-dramatic culture clash of a distraction, taking away from the valuable time that the already over-burdened kernel developers have available. Combine that with the veiled threats and passive aggressive tone of the email and it is all a turn-off. Let the Rust folks go off and do their own kernel project(s). If they c…

If Linux is to remain exclusively in the terrible memory unsafe language known as C, then I'm afraid I'll have to switch from Linux, which I've been daily driving for a decade now.

Re: Retiring from the Rust for Linux Project – Wedson Almeida Filho

#92

Post by cholantesh »

masfoobar wrote: post #38
simjnd wrote: post #33

Earlier quoted context omitted.

> I understand the backlash especially veterans who have put in their efforts on the kernel and have no wish to learn Rust. I am sure there are plenty of Rust people throwing their world views opinions yet barely wrote anything decent in C, if at all. If you watch the video Wedson linked to in his email, you will see a fragment of the typical experience of a Linux Rust kernel maintainer. Rust in the kernel does not a…

I have watched the video. I am not ignoring or denying there isn't individuals throwing their toys out of the pram when follow-up discussions should remain respectful and mature. On one end, I get it. Linux kernel is a BIG project. I assume it is still the biggest Free/Open Source project today. Many developers involved in this project genuinely care about it. These big projects will NOT go down well if a release con…

>Now, these guys need to learn Rust

I think the key point of contention here is that the Rust maintainers are insisting this isn't the case. For them, they retain oversight on the Rust bindings, not the C components they reference. What they expect is that when a breaking change happens, they are able to reach out to maintainers of the C component and get documentation, issue threads, etc that might help them resolve those issues.

For Ts'o, maybe the concern is that producing the docs would be onerous, or that in reality they may have to provide more than the minimum expected level of support. I don't personally think the former is a reasonable complaint. I think the latter has grounds for discussion and compromise. And if he is passionate about the kernel as a project, he should introspect about how likely it is that the community will retain or expand its strength as he throws loud public tantrums voluntary contributions to it.

Re: Retiring from the Rust for Linux Project – Wedson Almeida Filho

#93

Post by masfoobar »

mustache_kimono wrote: post #86
masfoobar wrote: post #84

Earlier quoted context omitted.

> Should there be some duty to approach reality in these comments? What is wrong comparing Odin to Rust... or Zig to Rust.. or Zig to Odin? These languages exists and should not be ignored simply for being labeled as `niche` The previous commenter referred Rust as being stable because it was version 1.0 nearly 10 years ago.. and I responded why this does not mean as much as people think. From 1.0 to (now) 1.80.1 -- h…

> Comparing that with C, [the kernel] is now going through the process of moving from C89 to C11. Once moved to C11 is unlikely to move for quite some time. Such conservatism is fine(?), but I think it really should serve some purpose. You think Rust code will change, such that... it will not be understandable? You don't actually say. Why should we be concerned? > I am just stating that it is hard to know REALLY what…

> You think Rust code will change, such that... it will not be understandable?

Its not about whether it is understandable or not -- it is NEW FEATURES!

Re: Retiring from the Rust for Linux Project – Wedson Almeida Filho

#94

Post by mustache_kimono »

masfoobar wrote: post #93
mustache_kimono wrote: post #86

Earlier quoted context omitted.

> Comparing that with C, [the kernel] is now going through the process of moving from C89 to C11. Once moved to C11 is unlikely to move for quite some time. Such conservatism is fine(?), but I think it really should serve some purpose. You think Rust code will change, such that... it will not be understandable? You don't actually say. Why should we be concerned? > I am just stating that it is hard to know REALLY what…

> You think Rust code will change, such that... it will not be understandable? Its not about whether it is understandable or not -- it is NEW FEATURES!

> Its not about whether it is understandable or not -- it is NEW FEATURES!

I guess I still don't understand. Your concern is new features will do what exactly to old Rust code?

Re: Retiring from the Rust for Linux Project – Wedson Almeida Filho

#95

Post by steveklabnik »

mustache_kimono wrote: post #94
masfoobar wrote: post #93

Earlier quoted context omitted.

> You think Rust code will change, such that... it will not be understandable? Its not about whether it is understandable or not -- it is NEW FEATURES!

> Its not about whether it is understandable or not -- it is NEW FEATURES! I guess I still don't understand. Your concern is new features will do what exactly to old Rust code?

I have found that there are two different ways people think about the word stability:

1. A toolchain is stable if new toolchains can still work with older code written for a previous version of the toolchain.

2. A toolchain is stable if there is a slow rate of change in the toolchain.

It would seem your parent is either in camp #2 or closer to #2 than #1.

Re: Retiring from the Rust for Linux Project – Wedson Almeida Filho

#96

Post by whytevuhuni »

steveklabnik wrote: post #95
mustache_kimono wrote: post #94

Earlier quoted context omitted.

> Its not about whether it is understandable or not -- it is NEW FEATURES! I guess I still don't understand. Your concern is new features will do what exactly to old Rust code?

I have found that there are two different ways people think about the word stability: 1. A toolchain is stable if new toolchains can still work with older code written for a previous version of the toolchain. 2. A toolchain is stable if there is a slow rate of change in the toolchain. It would seem your parent is either in camp #2 or closer to #2 than #1.

There is also:

3. A toolchain is stable if it has LTS releases and bugfixes are backported to them, regardless of how many changes each non-LTS release brings.

But I'm not sure if people think about stability like that often. I wish they did.

Re: Retiring from the Rust for Linux Project – Wedson Almeida Filho

#97

Post by mustache_kimono »

steveklabnik wrote: post #95
mustache_kimono wrote: post #94

Earlier quoted context omitted.

> Its not about whether it is understandable or not -- it is NEW FEATURES! I guess I still don't understand. Your concern is new features will do what exactly to old Rust code?

I have found that there are two different ways people think about the word stability: 1. A toolchain is stable if new toolchains can still work with older code written for a previous version of the toolchain. 2. A toolchain is stable if there is a slow rate of change in the toolchain. It would seem your parent is either in camp #2 or closer to #2 than #1.

Steve, as always, very wise.

Of course, it wasn't sensible, but it felt like my burden to say something when the reasoning was "But MORE features! Can't you see MORE is MORE?!" Perhaps because it reminded me of Drew Devault's mind-numbing "Rust is not a good C replacement". My more detailed thoughts on which are here: https://news.ycombinator.com/item?id=41409049

Re: Retiring from the Rust for Linux Project – Wedson Almeida Filho

#98

Post by Pet_Ant »

pseudony wrote: post #8
laerus wrote: post #7

Earlier quoted context omitted.

Why the answers to these questions are not the same as if C code was calling other C code?

That should be obvious ? The concern from those contributors (and we might soon see the same in QEMU) is that these bindings are essentially a weaponization which forces the great majority of contributors to learn Rust or drop out. Essentially a hostile takeover. If I am contributing to the Linux kernel already, I presumably have a decent grasp of C, the central abstractions in the code I am changing, the email-based…

> The concern from those contributors (and we might soon see the same in QEMU) is that these bindings are essentially a weaponization which forces the great majority of contributors to learn Rust or drop out. Essentially a hostile takeover.

No, it just means that when their changes are ready, if they break the Rust bindings then then just need to fire off an email to the Rust people to update the binding. This is no different than having to get an approval before merging a branch. They don't have to code differently at all. It just slows down the merge. That's it.

Re: Retiring from the Rust for Linux Project – Wedson Almeida Filho

#99

Post by steveklabnik »

Pet_Ant wrote: post #98
pseudony wrote: post #8

Earlier quoted context omitted.

That should be obvious ? The concern from those contributors (and we might soon see the same in QEMU) is that these bindings are essentially a weaponization which forces the great majority of contributors to learn Rust or drop out. Essentially a hostile takeover. If I am contributing to the Linux kernel already, I presumably have a decent grasp of C, the central abstractions in the code I am changing, the email-based…

> The concern from those contributors (and we might soon see the same in QEMU) is that these bindings are essentially a weaponization which forces the great majority of contributors to learn Rust or drop out. Essentially a hostile takeover. No, it just means that when their changes are ready, if they break the Rust bindings then then just need to fire off an email to the Rust people to update the binding. This is no…

At present it doesn’t even slow down the merge! The whole point of the experiment is to get experience without interfering with the regular development of the kernel. It’s allowed to be broken by non-Rust work, and as you mentioned the Rust folks are wiling to do the work on that side.

Re: Retiring from the Rust for Linux Project – Wedson Almeida Filho

#100

Post by aw1621107 »

cantrelate wrote: post #80

Forget all this drama, I wonder if we can have a Borrow Checker, like the one Rust has, implemented on top of C as an optional feature? And since it's just a compile-time thing, it won't cause any incompatibility or breakage at runtime. I love the idea of having the memory safety features that the Rust compiler offers, but I find Rust unreadable, it hurts my eyes, why do we have to write "let" to define a variable? w…

> I wonder if we can have a Borrow Checker, like the one Rust has, implemented on top of C as an optional feature?

In theory, possibly. In practice, there are a number of technical and social obstacles standing in the way of such a feature.

The first big technical problem is that standard C is currently not very well-suited for borrow checker-style automated lifetime/ownership analysis. Much of the information the borrow checker needs just not present in the C type system, and while some information may be inferable from function bodies separate compilation and the dynamic nature of ownership make things really hard, if not impossible in the general case.

Of course, one could require the addition of lifetime/ownership annotations, but that is a pretty substantial backwards compatibility break - there's a lot of existing C code out there, and they'd need to be annotated to be usable in a Rust-style borrow checker. That's an automatic deal-breaker for a lot of people.

So what happens if you just try to work with what you have? Then you basically end up where existing static analysis tools are - they can catch some lifetime/ownership errors, but that's on a best-effort basis an can potentially be very resource-intensive.

> why do we have to write "let" to define a variable?

The most common explanation I've seen is that it makes parsing and/or type inference easier. In addition, let is also more than just a variable declaration - it can be used more generally for binding/destructuring/pattern matching (e.g., if let Some(Point(x, y)) = p { do_something(x, y) }.

> why did they completely change the syntax if the goal is to be a C alternative!?

Because those changes are (arguably) improvements?

Post reply on HN