Live data from Hacker News

Retiring from the Rust for Linux Project – Wedson Almeida Filho

lore.kernel.org

101–107 of 107 posts

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

#101

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…

To me it seems like the goal was to be a C++ alternative, not C. I do half-agree though... I think somewhere inside Rust there is a hidden simpler language, with only a tiny subset of its features, but which still has lifetimes. I'd love to see that language.

> To me it seems like the goal was to be a C++ alternative, not C.

That's probably the reason.

> I think somewhere inside Rust there is a hidden simpler language, with only a tiny subset of its features, but which still has lifetimes

That's exactly the language I would like to upgrade to from C.

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

#102

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 bo…

> 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.

Yeah unfortunately.

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

#103
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…

I don't think this would go well for Linux. The companies actually paying for the kernel development want Rust. That's a matter of fact. Just see who's sponsoring the Linux Foundation, and check what they said elsewhere about their long term commitment to Rust. The main sponsors would likely just fork Linux should Rust be removed again. Than Linux would be left with "community contributions" and the trademarks, but a…

> The companies actually paying for the kernel development want Rust. That's a matter of fact.

Okay, I've researched this quite a bit and it is totally false. Companies paying for kernel development are on older kernel versions and want certain features/fixes backported to their kernels. As of today, those backports are only supported in one language, C.

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

#104
post #103

Earlier quoted context omitted.

I don't think this would go well for Linux. The companies actually paying for the kernel development want Rust. That's a matter of fact. Just see who's sponsoring the Linux Foundation, and check what they said elsewhere about their long term commitment to Rust. The main sponsors would likely just fork Linux should Rust be removed again. Than Linux would be left with "community contributions" and the trademarks, but a…

> The companies actually paying for the kernel development want Rust. That's a matter of fact. Okay, I've researched this quite a bit and it is totally false. Companies paying for kernel development are on older kernel versions and want certain features/fixes backported to their kernels. As of today, those backports are only supported in one language, C.

Because backporting is the same as writing drivers??

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

#105
post #71

They let you in, you take a shit on the floor and leave. Who is to blame? I don't blame this guy. It's the people who let the Barbarians in, because politics. Sometimes gates need to be kept.

This is pretty vague. Your post contains only analogies. No content.

Not at all, their username and post history says it all... They are a troll.

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

#106
post #104
post #103

Earlier quoted context omitted.

> The companies actually paying for the kernel development want Rust. That's a matter of fact. Okay, I've researched this quite a bit and it is totally false. Companies paying for kernel development are on older kernel versions and want certain features/fixes backported to their kernels. As of today, those backports are only supported in one language, C.

Because backporting is the same as writing drivers??

When the drivers are being written with compatibility in mind for the older kernels... yes? Would you prefer that the overworked maintainers write them twice in two completely different languages?

Look at RHEL 9. That shipped with kernel 5.14. For companies that are getting newer hardware or want capabilities that aren't available in 5.14, what do you think they would be paying for?

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

#107

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 bo…

Looks like we will get that borrow checker after all :) "The affine type system makes it easier to relocate objects without breaking type safety. Pattern matching, which is safe and expressive, interfaces with the extension’s new choice types. Borrow checking,[borrow-checking] the most sophisticated part of the Safe C++, provides a new reference type that flags use-after-free and iterator invalidation defects at compile time." https://safecpp.org/P3390R0.html
Post reply on HN