Sometimes you do wonder if those 4chan memes about those who push rust rewrites are just memes or what..
A maintainer of a project making a decision about their project is not someone pushing a re-write.
APT Rust requirement raises questions
231–240 of 508 posts
Re: APT Rust requirement raises questions
#232Earlier quoted context omitted.
> I am thrown back by how... "janky" the syntax is. Well if you come from C++ it's a breath of fresh air! Rust is like a "cleaned-up" C++, that does not carry the historical baggage forced by backwards compatibility. It is well-thought out from the start. The syntax may appear a bit too synthetic; but that's just the first day of use. If you use it for a few days, you'll soon find that it's a great, beautiful languag…
> Rust is like a "cleaned-up" C++ Except they got the order of type and variable wrong. That alone is enough reason to never use Rust, Go, TypeScript or any other language that botches such a critical cornerstone of language syntax.
[flagged]
Re: APT Rust requirement raises questions
#233Earlier quoted context omitted.
I'm not sure which of the dozen Rust-syntax supporters I should reply to, but consider something like these three (probably equivalent) syntaxes: let mut a = Vec:: ::new(); let mut b = >::new(); let mut c = >::new(); let mut d: Vec = Vec::new(); Which one will your coworker choose? What will your other corworkers choose? This is day one stuff for declaring a dynamic array. What you really want is something like: let…
I mean, the fact that you mention "probably equivalent" is part of the reality here: Nobody writes the majority of these forms in real code. They are equivalent, by the way. In real code, the only form I've ever seen out of these in the wild is your d form.
This is some True Scotsman style counter argument, and it's hard for me to make a polite reply to it.
There are people who program with a "fake it till you make it" approach, cutting and pasting from Stack Overflow, and hoping the compiler errors are enough to fix their mess. Historically, these are the ones your pages/books cater to, and the ones who think the borrow checker is the hard part. It doesn't surprise me that you only see code from that kind of beginner and experts on some rust-dev forum and nothing in between.
Re: APT Rust requirement raises questions
#234""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 can pick something else if it really matters.
Re: APT Rust requirement raises questions
#235Maybe 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?
It sounds like all of the affected Debian ports are long since diverged from the official Debian releases anyway:
> The sh4 port has never been officially supported, and none of the other ports have been supported since Debian 6.0.
Wikipedia tells me Debian 6 was released on 6 February 2011
Re: APT Rust requirement raises questions
#236I have a dual pentium pro 200 that runs gentoo and openbsd, but rust doesn't ship i586 binaries, only i686+. So I would need to compile on a separate computer to use any software that is using rust. There is already an initrd package tool I can't use since it is rust based, but I don't use initrd on that machine so it is not a problem so far. The computer runs modern linux just fine, I just wish the rust team would a…
I thought the Pentium Pro _was_ a 686?
Wikipedia seems to correlate: https://en.wikipedia.org/wiki/Pentium_Pro, as do discussions on CMOV: https://stackoverflow.com/a/4429563
Re: APT Rust requirement raises questions
#237""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…
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...
Re: APT Rust requirement raises questions
#238I have a dual pentium pro 200 that runs gentoo and openbsd, but rust doesn't ship i586 binaries, only i686+. So I would need to compile on a separate computer to use any software that is using rust. There is already an initrd package tool I can't use since it is rust based, but I don't use initrd on that machine so it is not a problem so far. The computer runs modern linux just fine, I just wish the rust team would a…
Pentium Pro is the first i686 CPU, so you should be fine.
Re: APT Rust requirement raises questions
#239Earlier quoted context omitted.
As a c/c++ cmake user, cargo sounds like a utopia in comparison. It still amazes me that c/c++ package management is still spread between about 5 different solutions. IMO, the biggest improvement to C/C++ would be ISO defining a package manager a.la pip or uv or cargo. I'm so tired of writing cmake. just... tired.
cmake is a self-inflicted problem of some C++ users, and an independent issue of the language itself (just like cargo for rust). If you want, you can use a makefile and distribution-provided dependencies, or vendored dependencies, and you don't need cmake.
imo the biggest single problem with C++ that the simple act of building it is not (and it seems, cannot) be standardized.
This creates kind of geographic barriers that segregate populations of C++ users, and just like any language, that isolation begets dialects and idioms that are foreign to anyone from a different group.
But the stewards of the language seem to pretend these barriers don't exist, or at least don't understand them, and go on to make the mountain ranges separating our valleys even steeper.
So it's not that CMake is a self-inflicted wound. It's the natural evolution of a tool to fill in the gaps left under specified by the language developers.
Re: APT Rust requirement raises questions
#240I remembered reading about this news back when that first message was posted on the mailing list, and didn't think much of it then (rust has been worming its way into a lot of places over the past few years, just one more thing I tack on for some automation)... But seeing the maintainer works for Canonical, it seems like the tail (Ubuntu) keeps trying to wag the dog (Debian ecosystem) without much regard for the wide…
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…
> This is breaking support for multiple ports to rewrite some feature for a tiny security benefit. And doing so on an unacceptably short timeline. Introducing breakage like this is unacceptable.
I’m
Normally I’d agree, but the ports in question are really quite old and obscure. I don’t think anything would have changed with an even longer timeline.
I think the best move would have been to announce deprecation of those ports separately. As it was announced, people who will never be impacted by their deprecation are upset because the deprecation was tied to something else (Rust) that is a hot topic.
If the deprecation of those ports was announced separately I doubt it would have even been news. Instead we’ve got this situation where people are angry that Rust took something away from someone.