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

APT Rust requirement raises questions

lwn.net

Post reply on HN
Print view View original

461–470 of 508 posts

Re: APT Rust requirement raises questions

#461

Post by pornel »

grayhatter wrote: post #276
cogman10 wrote: post #252

Earlier quoted context omitted.

This sounds like it's fun. However, I have to ask, why should the linux world cater to supporting 30 year old systems? Just because it scratches an itch? You can grab a $150 NUC which will run circles around this dual pentium pro system while also using a faction of the power. You obviously have to do a lot of extra work, including having a second system, just to keep this old system running. More work than it'd take…

> You can grab a $150 NUC I grew up without money, it makes me laugh when I read comments like this. You can just, yeah when you're fortunate enough to have a strong support system; you can. My understanding is that the systems are not meaningfully common, and are hobbyist archs. But the idea that dropping support is fine because you can just throw money at it is so incredibly divorced from reality that I actually fe…

The situation today is very different than what it used to be when people actually used 386 or Amigas because they had no other options (BTW, Rust supports m68k, just not AmigaOS specifically).

Today even crappiest old PCs that you can fish out of a dumpster are already new enough to have Rust/LLVM support. We have mountains of Rust-compatible e-waste that you can save from landfill. Take whatever is cheapest on eBay, or given away on your local FB marketplace, and it will run Rust, and almost certainly be orders of magnitude faster and more practical than the unsupported retro hardware.

Using actual too-niche-for-Rust hardware today is more expensive. Such machines are often collectors' items, and need components and accessories that are hard to obtain, or need replacements/adapters that can be custom low-volume products.

Even if you can put together something from old-but-not-museum-yet parts, it's not going to make more sense economically than getting an older-gen Raspberry PI kit or its Ali Express knock-offs (there are VGA dongles more expensive than some of these boards).

It's fine to appreciate SGI and DEC Alpha, have fun using BE OS, or prove that AmigaOS is still a perfectly fine daily driver, but let's not pretend it's a situation that people are in due to economic hardship.

Re: APT Rust requirement raises questions

#462

Post by kstrauser »

steveklabnik wrote: post #455
chillingeffect wrote: post #451

Earlier quoted context omitted.

True, but you might want to look into the licenses people are actually choosing for Rust versions of coreutils/uutils and who's promoting them.

Sure, those authors chose that license because they did not really particularly care for the politics of licenses and chose the most common one in the Rust ecosystem, which is MIT/Apache 2. If folks want more Rust projects under licenses they prefer, they should start those projects.

I released my most recent Rust project under the GPLv3. The first issue was someone asking me to relicense it under MIT. I politely declined.

I bring this up because no matter what you choose, someone will wish it was otherwise.

Re: APT Rust requirement raises questions

#463

Post by grayhatter »

pornel wrote: post #461
grayhatter wrote: post #276

Earlier quoted context omitted.

> You can grab a $150 NUC I grew up without money, it makes me laugh when I read comments like this. You can just, yeah when you're fortunate enough to have a strong support system; you can. My understanding is that the systems are not meaningfully common, and are hobbyist archs. But the idea that dropping support is fine because you can just throw money at it is so incredibly divorced from reality that I actually fe…

The situation today is very different than what it used to be when people actually used 386 or Amigas because they had no other options (BTW, Rust supports m68k, just not AmigaOS specifically). Today even crappiest old PCs that you can fish out of a dumpster are already new enough to have Rust/LLVM support. We have mountains of Rust-compatible e-waste that you can save from landfill. Take whatever is cheapest on eBay…

> but let's not pretend it's a situation that people are in due to economic hardship.

I'd encourage you to not strawman my response. Because I already said myself that it appears to me it's only hobbyists who are losing support.

My objection isn't to the argument that it's dropping support, my objection is that it's dropping support without cause. Other than, the assumed this would be more comfortable for me.

Maintainers are absolutely not required to support everything for ever, but I recall a story where someone from Linux paid for a user to upgrade, not because that was required, because more because that would make dropping support for that floppy driver feel ethical.

This is the level of compassion everyone should expect from software engineers in critical positions of power.

I have no sympathy for people who lack the compassion to expend the effort to help others. I do have sympathy for people who have to watch the world that they, even if it's them alone. Have to watch their world get worse, so that others can avoid a trivial amount of perceived discomfort.

Should this solo maintainer (who understands C) be required do things exactly the way that I want? Of course not, but I'll be damned if everyone expects me to remain silent while I watch them disrespect other people who were previously depending on their support.

Re: APT Rust requirement raises questions

#464

Post by echelon »

xscott wrote: post #391
echelon wrote: post #285

Earlier quoted context omitted.

Not at all! I'm trying to sell Rust to someone who is worried about it. I'm not trying to sound elitist. I want people to try it and like it. It's a useful tool. I want more people to have it. And that's not scaring people away. Rust isn't as hard or as bad as you think. It just takes time to let it sink in. It's got a little bit of a learning curve, but that pain goes away pretty quick. Once you've paid that down, R…

> Rust isn't as hard or as bad as you think. I think this depends a LOT on what you're trying to do and what you need to learn to do it. If you can get by with the std/core types and are happy with various third party crates, then you don't really need to learn the language very deeply. However, if you want to implement new data structures or generic algorithms, it gets very deep very quickly.

Why would you say that? I feel this pushes people away.

"Hey, you might be able to use Rust trivially if you stick to XYZ, but if you dare touch systems programming you're in for some real hurt. Dragons everywhere."

Why say that? It's not even remotely true - it's a gradient of learning. You can use Rust for simple problems as a gateway into systems programming.

Rust is honestly a great alternative to Python or Golang for writing servers. Especially given that you can deploy static binaries or WASM.

We need more people learning the language, not to scare them away.

Rust is getting easier year over year, too! People can choose Rust for their problems today and not struggle.

Give them a cookie and let them see for themselves.

Re: APT Rust requirement raises questions

#465

Post by pabs3 »

forgotpwd16 wrote: post #38
petcat wrote: post #3

Interesting how instead of embracing Rust as a required toolchain for APT, the conversation quickly devolved into "why don't we just build a tool that can translate memory-safe Rust code into memory-unsafe C code? Then we don't have to do anything." This feels like swimming upstream just for spite.

>tool that can translate memory-safe Rust code into memory-unsafe C code Fwiw, there're two such ongoing efforts. One[1] being an, written in C++, alternative Rust compiler that emits C (aka, in project's words, high-level assembly ), the other[2] being a Rust compiler backend/plugin (as an extra goal to its initial being to compile Rust to CLR asm). Last one apparently is[3] quite modular and could be adapted for ot…

Also there is a rustc codegen backend that uses GCC, so you can just skip the C part:

https://github.com/rust-lang/rustc_codegen_gcc

Re: APT Rust requirement raises questions

#466

Post by yjftsjthsd-h »

ForHackernews wrote: post #440
yjftsjthsd-h wrote: post #432

Earlier quoted context omitted.

NetBSD isn't a retro OS, nor is it particularly obscure. (For that matter, VAX isn't obscure, though it's very retro.)

Maybe not for hacker news. In the real world, it's plenty obscure. Poll your family at Thanksgiving. https://w3techs.com/technologies/details/os-netbsd > NetBSD is used by less than 0.1% of all the websites whose operating system we know.

I would expect the same number of laypeople to know about NetBSD and Debian (zero). Which gets neatly to an argument that I like for this kind of thing: Don't be so quick to throw out the long tail, because you're on it.

Re: APT Rust requirement raises questions

#467

Post by bobbylarrybobby »

xscott wrote: post #271
bobbylarrybobby wrote: post #202

Earlier quoted context omitted.

I've only ever seen `a` and `d`. Personally I prefer `a`. The only time I've seen `c` is for trait methods like ` >::func`. Noisy? I guess. Not sure how else this could really be written.

Fwiw, I didn't go looking for obscure examples to make HN posts. I've had three rounds of sincerely trying to really learn and understand Rust. The first was back when pointer types had sigils, but this exact declaration was my first stumbling block on my second time around. The first version I got working was `d`, and my first thought was, "you're kidding me - the right hand side is inferring it's type from the left…

Rust’s inference is generally a strength. If there's a type-shaped hole to fill, and only one way to fill it, Rust will just do it. So for instance `takes_a_vec(some_iter.collect())` works even though `collect` has a generic return type — being passed to `takes_a_vec` implies it must be a Vec, and so that's what Rust infers.

Re: APT Rust requirement raises questions

#468

Post by vablings »

influx wrote: post #282
vablings wrote: post #274

Earlier quoted context omitted.

>I know intellectually, that there are sane/pragmatic people who appreciate Rust. For the most part that is almost everyone who works on rust and writes rust. The whole coreutils saga was pretty much entirely caused by Canonical, The coreutils rewrite project was originally a hobby project iirc and NOT ready for prod. for the most part the coreutils rewrite is going well all things considered, bugs are fixed quickly…

It really makes me upset that we are throwing away decades of battle tested code just because some people are excited about the language du jour. Between the systemd folks and the rust folks, it may be time for me to move to *BSD instead of Linux. Unfortunately, I'm very tied to Docker.

I agree that throwing away battle tested code is wasteful and often not required. Most people are not of the mindset of just throwing things away but there is a drive to make things better. There are some absolute monoliths such as the Linux kernel that will likely never break free of its C shackles and thats completely okay and acceptable to me

Re: APT Rust requirement raises questions

#469

Post by leoh »

leoh wrote: post #87

I hate learning new things. It sucks. Also, I hate things that make my knowledge of C++ obsolete. I hate all the people that are getting good at rust and are threatening to take away my job. I hate that rust is a great leveler, making all my esoteric knowledge of C++ that I have been able to lord over others irrelevant. I hate that other people are allowed to do this to me and to do whatever they want, like making th…

https://en.wikipedia.org/wiki/Poe%27s_law

Re: APT Rust requirement raises questions

#470

Post by [deleted] »

xscott wrote: post #318
gpm wrote: post #250

Earlier quoted context omitted.

This is like complaining that in C you can write a->b (a->b) (*a).b ((*a).b) Being able to use disambiguated syntaxes, and being able to add extra brackets, isn't an issue. PS. The formatting tooling normalizes your second and third example to the same syntax. Personally I think it ought to normalize both of them to the first syntax as well, but it's not particularly surprising that it doesn't because they aren't thi…

> This is like complaining that in C [...] It's really not. Only one of my examples has the equivalent of superfluous parens, and none are dereferencing anything. And I'm not defending C or C++ anyways. When I was trying to learn Rust (the second time), I wanted to know how to make my own types. As such, the macro `vec!` mentioned elsewhere isn't really relevant. I was using `Vec` to figure things out so I could make…

[deleted]
Post reply on HN