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

391–400 of 508 posts

Re: APT Rust requirement raises questions

#391

Post by xscott »

echelon wrote: post #285
SoftTalker wrote: post #169

Earlier quoted context omitted.

This honestly reads like the cliche "you just don't get it yet" dismissals of many rust criticisms.

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.

Re: APT Rust requirement raises questions

#392

Post by crote »

kevin_thibedeau wrote: post #279
razighter777 wrote: post #172

Earlier quoted context omitted.

Agreed. I think that announcement was unprofessional. This was a unilateral decision affecting other's hard work, and the author didn't provide them the opportunity to provide feedback on the change. It disregards the importance of ports. Even if an architecture isn't widely used, supporting multiple architectures can help reveal bugs in the original implementation that wouldn't otherwise be obvious. This is breaking…

> Canonical or debian should work on porting the rust toolchain (ideally with tier 1 support) to every architecture they release for This will be an impediment for new architectures in the future. Instead of just "builds with gcc" we would need to wait for Rust support.

> Instead of just "builds with gcc" we would need to wait for Rust support.

There's always rustc_codegen_gcc (gcc backend for rustc) and gccrs (Rust frontend for gcc). They are't quite production-ready yet, but there's a decent chance it's good enough for the handful of hobbyists wanting to run the latest applications on historical hardware.

As to adding new architectures: it just shifts the task from "write gcc backend" to "write llvm backend". I doubt it'll make much of a difference in practice.

Re: APT Rust requirement raises questions

#393

Post by cogman10 »

MisterTea wrote: post #349
tucnak wrote: post #237

Earlier quoted context omitted.

You seem to be involved with 9front. Are you trying to suggest there is a nontrivial community of people who cannot afford modern 64-bit Linux platforms, and opt for 9front on some ancient 32-bit hardware instead? Where are they coming from? Don't get me wrong, I love the 9 as much as the next guy, but you seem to paint it as some kind of affordability frontier...

> Where are they coming from? One is in lives in Brazil and I think the other lives in the Middle East. They both have old second hand 32 bit laptops from the 00's. > but you seem to paint it as some kind of affordability frontier... Yes because there are people still using old hardware because they have no choice. Also, whats the problem with supporting old architectures? Plan 9 solved the portability problem and a…

> whats the problem with supporting old architectures?

It's not free, it's not easy, and it introduces hard to test and rarely run code paths that may or may not have problems on the target architecture.

I think there's a pretty strong argument for running hardware produced in the last 10 years for the next 10 or 20 years. However, I think it should be recognized that there was massive advances in compute power from 2000 to 2010 that didn't happen from 2010 to 2025.

A Core 2 Quad (produced in 2010) has ~ 1/2 the performance of the N150 (1/4 the single core performance of the latest AMD 9950).

Meanwhile a Pentium 3 from 2000 has roughly 1/10th the performance of the same Core 2 Quad.

There are simply far fewer differences between CPUs made in 2010 and today vs CPUs made in 2000 to 2010. Even the instruction set has basically become static at this point. AVX isn't that different from SSE and there's really not a whole bunch of new instructions since the x64 update.

Re: APT Rust requirement raises questions

#394

Post by OptionX »

yoyohello13 wrote: post #152
OptionX wrote: post #60

Earlier quoted context omitted.

Untrue.

As evidenced by this very comment chain. I've seen, by far, way more comment from people annoyed by vegans. I can't even remember the last time I've heard a vegan discuss it outside of just stating the food preference when we got out to eat.

If I don't see it it doesn't happen is the definition of anedoctal.

Re: APT Rust requirement raises questions

#395

Post by krior »

kataklasm wrote: post #127
tcfhgj wrote: post #113

Earlier quoted context omitted.

I am coming from C++ and think Cargo is a blessing. I like that I can just add a dependency and be done instead of having to deal with dependencies which require downloading stuff from the internet and making them discoverable for the project specific tool chain - which works differently on every operating system. Same goes for compiling other projects.

But that is the kind of convenience and ease of use that brings us another npm malware incident every other month at this point.

On the other hand you don't have developers handrolling their own shitty versions of common things like hashmaps or json-serializers, just because the dependencies are to hard to integrate.

Re: APT Rust requirement raises questions

#396

Post by raxxorraxor »

antonvs wrote: post #309
travisgriggs wrote: post #243

Earlier quoted context omitted.

> I love and use rust, it is my favorite language and I use it in several of my OSS projects but I'm tired of this "rewrite it in rust" evangilism and the reputational damage they do to the rust community. Thanks for this. I know intellectually, that there are sane/pragmatic people who appreciate Rust. But often the vibe I’ve gotten is the evangelism, the clear “I’ve found a tribe to be part of and it makes me feel s…

Much of the drive to rewrite software in Rust is a reaction to the decades-long dependence on C and C++. Many people out there sit in the burning room like the dog in that meme, saying "this is fine". Most of them don't have to deal at all directly with the consequences involved. Rust is the first language for a long time with a chance at improving this situation. A lot of the pushback against evangelism is from peop…

Sometimes good things are ruined by people around. I think Rust is fine, although I doubt its constraints are universally true and sensible in all scenarios.

This is also not an endorsement of C/C++.

Re: APT Rust requirement raises questions

#397

Post by crote »

pjmlp wrote: post #389
crote wrote: post #373

Earlier quoted context omitted.

Command line utilities often handle not-fully-trusted data, and are often called from something besides an interactive terminal. Take for example git: do you fully trust the content of every repository you clone? Sure, you'll of course compile and run it in a container, but how prepared are you for the possibility of the clone process itself resulting in arbitrary code execution? The same applies to the other side of…

None of that requires a borrow checker. Any memory safe compiled managed language will do.

That's definitely true!

Some people might complain about the startup cost of a language like Java, though: there are plenty of scripts around which are calling command-line utilities in a very tight loop. Not every memory-safe language is suitable for every command-line utility.

Re: APT Rust requirement raises questions

#398

Post by WD-42 »

ActorNightly wrote: post #380
WD-42 wrote: post #116

Earlier quoted context omitted.

I’ve been writing python professionally for over 10 years. In the last year I’ve been writing more and most Rust. At first I thought the same as you. It’s a fugly language, there’s no denying it. But once I started to learn what all the weird syntax was for, it began to ruin Python for me. Now I begrudge any time I have to go back to python. It feels like its beauty is only skin deep, but the ugly details are right t…

>Now I begrudge any time I have to go back to python. It feels like its beauty is only skin deep, but the ugly details are right there beneath the surface: prolific duck typing, exceptions as control flow, dynamic attributes. All these now make me uneasy, like I can’t be sure what my code will really do at runtime. I feel like this sentiment is from people who haven't really took the time to fully see what the Python…

Oh I’m familiar with the ecosystem. Yes the dynamic nature does make it easy to prototype things flexibly. The problem is when your coworker, or you, decide to flexibly and dynamically get the job on a Friday before a long weekend and then 3 months later you need to figure out how a variable is being set, or where a method is being called.

Re: APT Rust requirement raises questions

#399

Post by yjftsjthsd-h »

cogman10 wrote: post #234
MisterTea wrote: post #212

""and not be held back by trying to shoehorn modern software on retro computing devices"" Nice. So discrimination of poor users who are running "retro" machines because that is the best they can afford or acquire. I knew of at least two devs who are stuck with older 32 bit machines as that is what they can afford/obtain. I even offered to ship them a spare laptop with a newer CPU and they said thanks but import dutie…

The last 32bit laptop CPU was produced nearly 20 years ago. Further, there are still several LTS linux distros (including the likes of Ubuntu and Debian) which don't have the rust requirement and won't until the next LTS. 24.04 is supported until 2029. Meaning you are talking about a 25 year old CPU at that point. And even if you continue to need support. Debian based distros aren't the only ones on the plant. You ca…

> The last 32bit laptop CPU was produced nearly 20 years ago.

15 years max; I can easily find documentation of Intel shipping Atom chips without 64-bit support in 2010, though I haven't found a good citation for when exactly that ended.

Re: APT Rust requirement raises questions

#400

Post by yjftsjthsd-h »

powerclue wrote: post #107
scotty79 wrote: post #53

Maybe there's a place for Future Debian distro that could be a place for phasing out old tech and introducing new features?

Or maybe old devices and tech should expect a limited support window, or be expected to fork after some time?

Some of us abandoned commercial OSs for Debian precisely to escape that mentality.
Post reply on HN