gauntletstricky
gauntletstricky on Hacker News
But the bindings still require expertise in both languages to write, don't they? And knowledge of both codebases?
And I haven't followed the specifics of the mailing list debate closely, but couldn't the nice bindings be copied or vendored into each Rust driver or something? I could be wrong, and it wouldn't be neat at all, and be a lot of bloat, but would enable having bindings. Some people argued the Rust code could be maintained out-of-tree, like some other projects were, even though it would take extra effort and also probably require tooling and processes.
>In other words, it doesn't matter unless you're trying to make Rust code link with, say, stuff compiled by ancient C compilers like Metrowerks CodeWarrior[1] or something; and that stuff makes use of varargs.
I did mention that it might not be an issue in practice, given some assumptions. However, if LLVM changes, or if for instance the Rust standard library is reused or copied over to GCC Rust, then the code would need to be changed. For GCC Rust, I wonder if part or all of the standard library could be forked, to have a GCC specific Rust standard library implementation, similar to what happens with C++'s standard library.
>As for Zig, I haven't used it. I trust that it also has good interop facilities. But that doesn't matter since we're talking about Rust for Linux, not Zig for Linux.
Sorry, but it does matter, since claiming that a language like Rust has good C interop of course leads to relative comparisons with other languages in similar spaces and how well they do relative to Rust. And if the promises by Zig holds, and the experience people talk about with Zig holds, then Zig appears to have a substantially better track record in regards to C interop than Rust. Which isn't surprising, since Zig is a less advanced and more primitive language than Rust, and while that has drawbacks, it can also have benefits, possibly like in this case with having much better C interop than Rust. In the same vein that the interop between Rust and C is likely way better than (unless confined to the C subset) the interop between Rust and C++.
>My sibling is also correct, language decisions were made in order to keep FFI zero overhead.
Yet overhead is only one piece of the puzzle for FFI and interop with C, or for that matter, C++.
How does Rust compare with a language with less advanced and more simple semantics and requirements of invariants, like Zig?
>Incrementally improve your C/C++/Zig codebase. > >Use Zig as a zero-dependency, drop-in C/C++ compiler that supports cross-compilation out-of-the-box.
I don't really know Zig, so I can't vouch for it, though.
BTW: You, Steve Klabnik, had this employer in the past:
https://fable.co/author/steve-klabnik
>Steve Klabnik is the Community Team Leader for the Rust team at Mozilla, in charge of official Rust community documentation as well as the key Rust community advocate. Klabnik is a frequent speaker at conferences and one of the world's most prolific contributors to Rails projects.
Were or are you a paid advocate for Rust?
Do the semantics of the borrow checker play nicely with C projects, depending on architectures? And the other semantics of Rust?
https://www.reddit.com/r/rust/comments/90s2no/rust_c_interop...
>When we started this, even rust itself was not ready and over this time rust has improved and it is today a better language and it is better prepared to offer something like this. For us or for other projects.
>It takes someone who is interested and good at both languages to dig in, understand the architectures, the challenges and the protocols to drive this all the way through.
>I am not against revisiting the topic and the idea of providing alternative backends for HTTP/1 in the future, but I think we should proceed a little different next time. We also have a better internal architecture now to build on than what we had in 2020 when this attempt started.
If the above quotes are accurate, how would it be consistent with what you wrote?
>In that sense, Rust is indeed specifically designed to play well in C codebases as the rest of the C code can basically pretend it's only working with C code.
This quote especially:
>It takes someone who is interested and good at both languages to dig in, (...)
As for being designed for interop with C, I found this blog:
https://ludwigabap.bearblog.dev/zig-vs-rust-at-work-the-choi...
Where they chose Zig instead of Rust, and mentioned the importance of interop, and that Zig also is a C compiler. Something that is claimed on Zig's website as well:
>Incrementally improve your C/C++/Zig codebase. > >Use Zig as a zero-dependency, drop-in C/C++ compiler that supports cross-compilation out-of-the-box.
I know barely anything about Zig, so I don't know the veracity of this, however.
Rust's FFI also relies on undefined behavior if this comment isn't outdated https://github.com/rust-lang/rust/pull/59625#issuecomment-48... https://github.com/rust-lang/rust/blob/master/library/core/s... . Might not be an issue as long as the implementation is only used with LLVM and LLVM doesn't change.
Apologies, you are "Top 1% Commenter" on r/rust, not a moderator, I remember going to r/rust to check, but I was not logged in, so couldn't check the list of moderators. I must have mixed you up with matthieum.
>I haven’t been involved with the Rust Project for years, I speak only for myself.
I did write "former".
Overall, my characterization of you as a major Rust community figure is correct, as you also do not deny, even though you do not acknowledge it here. You did run @rustlang, you are a primary author of the Rust Programming Language Book, you are a former Rust Core member, you are "Top 1% Commenter" on r/rust.
This is how you are described elsewhere https://books.google.com/books/about/The_Rust_Programming_La...
>Steve Klabnik is the Community Team Leader for the Rust team at Mozilla, in charge of official Rust community documentation, as well as a trusted Rust community advocate. Klabnik is a frequent speaker at conferences and one of the world's most prolific contributors to Rails projects
You wrote:
https://news.ycombinator.com/item?id=42981228
>It was sufficient, but that doesn’t prevent people from acting in bad faith. Which is what is happening here.
https://news.ycombinator.com/item?id=42973432
>Against the decision that the project made, that is very straightforwardly sabotage.
https://news.ycombinator.com/item?id=42968940
>That question is also not what is at the heart of this conflict. It’s someone that categorically rejects the experiment, even though the project has decided to give it a try. It’s entirely social and not technical.
https://news.ycombinator.com/item?id=42974898
>I agree that Linus's response wasn't over the top, but Hector didn't quit because of that one email. Heck, as far as I know he wasn't even involved in writing the patch in question. The Asahi folks have had a number of issues dealing with other maintainers for at least the past couple of years. This is a "the straw that broke the camel's back" situation.
https://news.ycombinator.com/item?id=42976319
>Hector wasn't the developer of this patch. However, he is a user of it. He has had some rough interactions over the last few years. And so seeing this happen (even though it's happening to someone else) is a "the straw that breaks the camel's back" kind of deal.
You have clearly made excuses for Hector. And how can you not deem it wrong of him to begin social media brigading? How can you not deem it wrong of him to begin making a "hall of shame" list?
If it is true that you, Steve Klabnik, were "Community Team Leader for the Rust team at Mozilla, in charge of official Rust community documentation as well as the key Rust community advocate.", can you confirm that you were in the past paid to be an advocate for Rust? And if yes, are you still paid to be an advocate for Rust?
And it is clear that the Rust Project has admitted to having an interest in Rust for 4 Linux https://blog.rust-lang.org/2024/08/12/Project-goals.html :
>The experimental support for Rust development in the Linux kernel is a watershed moment for Rust, demonstrating to the world that Rust is indeed capable of targeting all manner of low-level systems applications. And yet today that support rests on a number of unstable features, blocking the effort from ever going beyond experimental status. For 2024H2 we will work to close the largest gaps that block support.
https://rust-lang.github.io/rust-project-goals/2024h2/rfl_st...
>The experimental support for Rust development in the Linux kernel is a watershed moment for Rust, demonstrating to the world that Rust is indeed capable of targeting all manner of low-level systems applications. And yet today that support rests on a number of unstable features, blocking the effort from ever going beyond experimental status. For 2024H2 we will work to close the largest gaps that block support.
Sources requested. I don't even know why you'd claim this. Are you a Rust evangelist?
Another C project has not had good experiences with all interop attempts, pulling the plug on interop with one Rust library, while keeping support for two other Rust libraries.
https://daniel.haxx.se/blog/2024/12/21/dropping-hyper/
>Before this step, we supported three different backends backed up by libraries written in rust. Now we are down to two: rustls (for TLS) and quiche (for QUIC and HTTP/3). Both of them are still marked experimental. >These two backends use better internal APIs in curl and are hooked into libcurl in a cleaner way that makes them easier to support and less of burden to maintain over time.
Where was this done? In the recent mailing list, the maintainer never called people cancer, he said
https://lore.kernel.org/lkml/[email protected]/
>And I also do not want another maintainer. If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade).
Not referring to people. And many developers would agree that a multilanguage codebase can easily end up becoming a nightmare and pure cancer to maintain, whether or not Rust is one of those languages.
Another C project has not had good experiences with all interop attempts, pulling the plug on interop with one Rust library, while keeping support for two other Rust libraries.
https://daniel.haxx.se/blog/2024/12/21/dropping-hyper/
>Before this step, we supported three different backends backed up by libraries written in rust. Now we are down to two: rustls (for TLS) and quiche (for QUIC and HTTP/3). Both of them are still marked experimental. >These two backends use better internal APIs in curl and are hooked into libcurl in a cleaner way that makes them easier to support and less of burden to maintain over time.
>Thinking of literally starting a Linux maintainer hall of shame. Not for public consumption, but to help new kernel contributors know what to expect. >Every experienced kernel submitter has this in their head, maybe it should be finally written down.
https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU...
>If shaming on social media does not work, then tell me what does, because I'm out of ideas.
Hector Martin went way beyond being a "prick". And Linus Torvalds told him to stop it.
Have you considered that the problem may be the people that are making "hall of shame" lists of people and doing social media brigading?
Worsening matters, Steve Klabnik (major Rust community figure, has run @rustlang, primary author of the Rust Programming Language Book, former Rust Core member, and moderator of r/rust), have been busy here and on reddit making excuses for Hector Martin. What kind of community is the Rust community?