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

Hard Rust requirements from May onward

lists.debian.org

Post reply on HN
Print view View original

761–770 of 797 posts

Re: Hard Rust requirements from May onward

#761

Post by dralley »

jurschreuder wrote: post #667
dataflow wrote: post #648

Earlier quoted context omitted.

> So say you're a C++ developer, contributed to APT over the years, see all of it linked to the C++ community which you are part of too, and someone wants to start migrating parts of it to Rust/$NewLang. I think it might sometimes affect more for these people than just the code, might even be "attacking" (strong word perhaps) their sense of identity, for better or worse. How is language relevant here? If someone just…

This is really a Rust specific thing, since so many C++ projects were 1-on-1 translated to Rust only changing the licence. Rust has been the tool of choice for stealing GPL3 open source projects where some people have spent all their free time on at some point in their life.

Rewriting software is not "stealing" it. That is an absurd framing, and one that seems akin to the arguments employed against FOSS software in the first place back in the 1980s and 1990s.

In your view, was writing a BIOS re-implementation from scratch "stealing" from IBM? Are all of the vaguely Unix-compatible operating systems "stealing" from Unix (ATT/Bell)? Why is the "free time" of the original developer more sacrosanct than the "free time" of the re-implementer?

Re: Hard Rust requirements from May onward

#762

Post by dralley »

richard_todd wrote: post #631
pornel wrote: post #604

Earlier quoted context omitted.

You seem to think of "rust enthusiasts" as some organized group with a goal of writing Rust for the sake of it. Rust is long past such extremely early adopter phase. What you're seeing now is developers who are interested in writing a better version of whatever they're already working on, and they're choosing Rust to do it. It's not a group "Rust enthusiasts" ninjas infiltrating projects. It's more and more developer…

Nah, I called out redox and another commenter pointed out ripgrep as an even better example of what I’d prefer to see, and those are also by what I would call rust enthusiasts. I don’t think of them as a monolithic group. Where we disagree is I would not call injecting rust into an established project “writing a better version”. I would love it if they did write a better version, so we could witness its advantages be…

They are referring to adopting the Sequoia PGP library, which is written in Rust. There are plenty of benefits to using Sequoia which you can investigate now, no need to theoretically wait for the integration to happen. Not coincidentally, the RPM package manager also adopted Sequoia PGP.

Re: Hard Rust requirements from May onward

#763

Post by burntsushi »

larusso wrote: post #747
burntsushi wrote: post #723

Earlier quoted context omitted.

Writing tools that are POSIX compatible doesn't mean one puts it on the pedestal of the "holy grail of OS design." I've certainly used POSIX to guide design aspects of things I build. Not because I think POSIX is the best. In fact, I think it's fucking awful and I very much dislike how some people use it as a hammer to whinge about portability. But POSIX is ubiquitous. So if you want your users to have less friction,…

Yes but GNU to put them under GPL. Or that was my understanding.

So then your original comment should be amended to say, "and this is actually all fine when the authors use a license I personally like." So it's not actually the rewriting you don't like, but the licensing choices. Which you completely left out of your commentary.

You also didn't respond to my other rebuttal, which points out a number of counter-examples to your claim.

From my view, your argument seems very weak. You're leaving out critical details and ignoring counterpoints that don't confirm your bias.

Re: Hard Rust requirements from May onward

#764

Post by dralley »

UncleEntity wrote: post #201
mirashii wrote: post #172

Earlier quoted context omitted.

> I think this is the wrong way to promote rust This is entirely the wrong lens. This is someone who wants to use Rust for a particular purpose, not some sort of publicity stunt. > I know nobody that programms or even thinks about rust. I’m from the embedded world a there c is still king. Now’s a good time to look outside of your bubble instead of pretending that your bubble is the world. > as long as the real money…

> This is entirely the wrong lens. Telling people they need to take their ball and go home if they're incapable or unable to maintain an entire compiler back-end seems like a, shall we say, 'interesting' lens for a major distro such as Debian. Just to parse some files?

These are not officially supported platforms. It doesn't seem that unreasonable for Debian to not want to be restricted to "code that can be run on CPUs from the 1990s" in 2025

It's cool that you can run modern Debian on an Amiga or whatever, but it's not particularly important that that be the case.

Re: Hard Rust requirements from May onward

#765

Post by eYrKEC2 »

qiu3344 wrote: post #720
drnick1 wrote: post #686

My main objection to Rust is how ugly it looks. Why did they have to change things such as how types and functions are defined? I really hate keywords such as def, fn, and other "explicit" function declarations. Also all the :: and from C++. Language-wise Java and C# did a much better job at introducing the features they needed without breaking the readability and familiarity of C.

The "spiral" type declaration syntax from C is hard to parse, both for humans and machines. That's probably why even C++ is moving away from it: C modern C++ "int foo[5]" -> "array foo" It's easy to criticize simple examples like the one above, since the C++ (or Rust) version is longer than the C declaration, but consider something like this: char *(*(**foo[][8])())[]; and the idiomatic Rust equivalent: let foo: Vec…

For C, once I learned that types are best read right-to-left, they became much more scrutable.

        int[] foo
        |   |  |
        |   |  foo 
        |   is an array  
        of ints
I still prefer Rust types though..

Re: Hard Rust requirements from May onward

#766

Post by richard_todd »

dralley wrote: post #762
richard_todd wrote: post #631

Earlier quoted context omitted.

Nah, I called out redox and another commenter pointed out ripgrep as an even better example of what I’d prefer to see, and those are also by what I would call rust enthusiasts. I don’t think of them as a monolithic group. Where we disagree is I would not call injecting rust into an established project “writing a better version”. I would love it if they did write a better version, so we could witness its advantages be…

They are referring to adopting the Sequoia PGP library, which is written in Rust. There are plenty of benefits to using Sequoia which you can investigate now, no need to theoretically wait for the integration to happen. Not coincidentally, the RPM package manager also adopted Sequoia PGP.

First off, the mail references far more rust adoption than just Sequoia, but since you bring it up: here is how RPM adopted Sequoia in Fedora-land. There was a proposal, a discussion with developers about the ramifications (including discussion about making sure the RPMs built on all architectures), and there were votes and approvals. Costs and benefits and alternatives were analyzed. Here's a page that has links to the various votes and discussion: https://fedoraproject.org/wiki/Changes/RpmSequoia

Can't you see how much more thought and care went into this, than is on display in this Debian email (the "if your architecture is not supported in 6 months then your port is dead" email)?

Re: Hard Rust requirements from May onward

#767

Post by dataflow »

dralley wrote: post #761
jurschreuder wrote: post #667

Earlier quoted context omitted.

This is really a Rust specific thing, since so many C++ projects were 1-on-1 translated to Rust only changing the licence. Rust has been the tool of choice for stealing GPL3 open source projects where some people have spent all their free time on at some point in their life.

Rewriting software is not "stealing" it. That is an absurd framing, and one that seems akin to the arguments employed against FOSS software in the first place back in the 1980s and 1990s. In your view, was writing a BIOS re-implementation from scratch "stealing" from IBM? Are all of the vaguely Unix-compatible operating systems "stealing" from Unix (ATT/Bell)? Why is the "free time" of the original developer more sac…

I don't think they mean stealing in a legal/ownership sense, but stealing in the "I can no longer say this is my project" (control/intellectual/credit) sense.

> Why is the "free time" of the original developer more sacrosanct than the "free time" of the re-implementer?

This has nothing to do with free time. It has to do with the fact that the former actually went through a ton of pain to get the project from its original conception and past bugs & design flaws into its current useful state, and the latter is merely translating the solution right in front of them. And not only is the latter going to deprive the former of the ability to even say "this is my project" (despite them having spent years or decades on its design etc.), but they're also probably going to be able to take the whole thing in a different direction, effectively leaving the original author behind.

Whether you feel this is a good or a bad thing for society aside, it should be obvious why this could be genuinely upsetting in some situations.

Re: Hard Rust requirements from May onward

#768

Post by dralley »

richard_todd wrote: post #766
dralley wrote: post #762

Earlier quoted context omitted.

They are referring to adopting the Sequoia PGP library, which is written in Rust. There are plenty of benefits to using Sequoia which you can investigate now, no need to theoretically wait for the integration to happen. Not coincidentally, the RPM package manager also adopted Sequoia PGP.

First off, the mail references far more rust adoption than just Sequoia, but since you bring it up: here is how RPM adopted Sequoia in Fedora-land. There was a proposal, a discussion with developers about the ramifications (including discussion about making sure the RPMs built on all architectures), and there were votes and approvals. Costs and benefits and alternatives were analyzed. Here's a page that has links to…

> (including discussion about making sure the RPMs built on all architectures)

All officially supported ones. The Debian discussion is not about officially supported Debian ports, it's about unofficial ones.

Re: Hard Rust requirements from May onward

#769

Post by dralley »

dataflow wrote: post #767
dralley wrote: post #761

Earlier quoted context omitted.

Rewriting software is not "stealing" it. That is an absurd framing, and one that seems akin to the arguments employed against FOSS software in the first place back in the 1980s and 1990s. In your view, was writing a BIOS re-implementation from scratch "stealing" from IBM? Are all of the vaguely Unix-compatible operating systems "stealing" from Unix (ATT/Bell)? Why is the "free time" of the original developer more sac…

I don't think they mean stealing in a legal/ownership sense, but stealing in the "I can no longer say this is my project" (control/intellectual/credit) sense. > Why is the "free time" of the original developer more sacrosanct than the "free time" of the re-implementer? This has nothing to do with free time. It has to do with the fact that the former actually went through a ton of pain to get the project from its orig…

Sure, it's upsetting. IBM was upset about BIOS being cloned, Bell got upset about Unix being cloned, Oracle got upset about the JDK being cloned, etc. Many of them were upset enough to engage in decade-long lawsuits. But we'd ultimately be in a much worse place if "avoiding making original creators upset" was the primary factor in development, over things like compatibility, bugs, performance, security etc.

I happen to like living in a world where Pipewire can just be a drop in replacement for PulseAudio that can implement the same APIs and do everything that PulseAudio does but better. Or where I can play my games on Linux because Valve re-implemented DirectX and all the Windows platform libraries. Or where there are half a dozen "vim" clones to pick from if I want to. If there are broad, tangible benefits to rewriting a piece of software, then it ought to be rewritten, hurt feelings nonwithstanding.

I don't really understand the argument that the original author gets deprived of anything by a piece of free software being rewritten, certainly not credit. Obviously stealing the name would be a dick move and maybe open you up to legal action but that's not really what happens 99.99% of the time.

Re: Hard Rust requirements from May onward

#770

Post by DaSHacka »

iknowstuff wrote: post #662
DaSHacka wrote: post #650

Earlier quoted context omitted.

I'm not gonna waste effort on a fool's errand. So far, neither claim has been backed up whatsoever. It's obviously more likely it's just fans of the language with a knee-jerk reaction of "ackshully you're totally definetely wrong, but uh... don't ask me how, you just are" than legitimate talking points.

stay ignant then, keep making stupid claims and asking people to correct them lol

> stay ignant then, keep making stupid claims and asking people to correct them lol

It aint stupid if its the truth lol

Feel free to stay "ignant" though, making stupid claims and refusing to back them up when asked.

Post reply on HN