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

291–300 of 508 posts

Re: APT Rust requirement raises questions

#291

Post by mikepurvis »

surajrmal wrote: post #209
inetknght wrote: post #104

Earlier quoted context omitted.

> the "new solver" currently lacks a testsuite To borrow a phrase I recently coined: If it's not tested then it's not Engineered. You'd think that core tools would have proper Software Engineering behind them. Alas, it's surprising how many do not.

Integration tests are still tests. There are definitely cases for tools where you can largely get by without unit tests in favor of integration tests. I've written a lot of code generation tools this way for instance.

Unit tests are for testing branchiness— what happens in condition X, what about condition Y? Does the internal state remain sane?

Integration tests are for overall sanity— do a few happy paths basically work? what about when we make changes to the packaging metadata or roll dependencies forward?

Going unit-test free makes total sense in the case of code that doesn't have much in the way of branching, or where the exceptional cases can just be an uncontrolled exit. Or if you feel confident that your type system's unions are forcing you to cover your bases. Either way, you don't need to test individual functions or modules if running the whole thing end to end gives you reasonable confidence in those.

Re: APT Rust requirement raises questions

#292

Post by Daishiman »

DeathArrow wrote: post #81
debo_ wrote: post #58

Earlier quoted context omitted.

The family of languages that started with ML[0] mostly look like this. Studying that language family will probably help you feel much more at home in Rust. Many features and stylistic choices from ML derivatives have made their way into Swift, Typescript, and other non-ML languages. I often say that if you want to be a career programmer, it is a good idea to deeply learn one Lisp-type language (which will help with s…

F# looks nothing like Rust. Is much more readable for me.

F#'s semantics don't describe memory management and lifetimes to the degree that Rust does.

Re: APT Rust requirement raises questions

#294

Post by kasabali »

yoyohello13 wrote: post #144
thousand_nights wrote: post #86

Earlier quoted context omitted.

nta you're replying to, but as someone who doesn't know rust, on first glance it seems like it's littered with too many special symbols and very verbose. as i understand it this is required because of the very granular low level control rust offers maybe unreadable is too strong of a word, but there is a valid point of it looking unapproachable to someone new

People often misuse unreadable when they mean unfamiliar. Rust really isn't that difficult to read when you get used to it.

Chinese isn't that difficult to read when you get used to it, too.

Re: APT Rust requirement raises questions

#295

Post by mikepurvis »

stonemetal12 wrote: post #42
fn-mote wrote: post #20

The most interesting criticism / idea in the article was that the parts that are intended for Rust-ification should actually be removed from core apt. > it would be better to remove the code that is used to parse the .deb, .ar, and .tar formats [...] from APT entirely. It is only needed for two tools, apt-ftparchive and apt-extracttemplates [...] Another interesting, although perhaps tangential, criticism was that th…

Given that Cargo is written in Rust, you would think there would be at least one battle tested solver that could be used. Perhaps it was harder to extract and make generic than write a new one?

Historically apt hasn't had much of a "solver". It's basically take the user's upgrade/install action, if there's some conflict or versioned requirement, go to the candidate (≈newest barring pinfile shenanigans) of the involved packages, and if there's still a conflict, bail.

It was always second-tier utilities like Aptitude that tried to search for a "solution" to conflicting packaging constraints, but this has always been outside of the core functionality, and if you accepted one of Aptitude's proposed paths, you would do so knowing that the next apt dist-upgrade was almost certainly going to hose everything again.

I think the idea in Apt-world is that it's the responsibility of the archive maintainer to at all times present a consistent index for which the newest versions of everything can coexist happily together. But this obviously breaks down when multiple archives are active on the same apt conf.

Re: APT Rust requirement raises questions

#296

Post by cogman10 »

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…

Your post is offensive to me.

I have plenty of relatives without money or resources and $150 is something they can all afford.

It's not even the floor of the amount of money needed (Here's a used NUC for $30 [1]), but rather just showing that a new system can be had for a lot less than many people expect.

You are the one divorced from reality if you think there's an army of poor orphans running modern linux on pentium pros.

Affording rent and health insurance is a FAR bigger issue than being able to throw a little money towards a new computer once every 10 years.

[1] https://www.ebay.com/itm/366000004972?_skw=NUC&itmmeta=01KAY...

Re: APT Rust requirement raises questions

#297

Post by gpm »

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…

> 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?!?" I didn't learn about "turbo fish" until some time later.

Tbh d strikes me as the most normal - right hand sides inferring the type from the left exists in basically every typed language. Consider for instance the C code

    some_struct a = { .flag = true, .value = 123, .stuff = 0.456 };
Doing this inference at a distance is more of a feature of the sml languages (though I think it now exists even in C with `auto`) - but just going from left to right is... normal.

Re: APT Rust requirement raises questions

#298

Post by dathinab »

razighter777 wrote: post #172
geerlingguy wrote: post #5

I 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…

> and the author didn't provide them the opportunity to provide feedback on the change.

this is wrong, the author wrote a mail about _intended_ changes _1/2 year_ before shipping them on the right Debian mailing list. That is _exactly_ how giving people an opportunity to give feedback before doing a change works...

Sure, they made it clear they don't want any discussions to be side tracked about a topics about thing Debian doesn't official support. That is not nice, but understandable, I have seen way too much time wasted on discussions being derailed.

The only problem here is people overthinking things and/or having issues with very direct language IMHO.

> This is breaking support for multiple ports to rewrite some feature for a tiny security benefit

It's not braking anything supported.

The only thing breaking are unsupported. And are only niche used too.

Nearly all projects have very limited capacities and have to draw boundaries, and the most basic boundary is unsupported means unsupported. This doesn't mean you don't keep unsupported use cases in mind/avoid accidentally breaking them, but it means they don't majorly influence your decision.

> And doing so on an unacceptably short timeline

1/2 a year for a change which only breaks unsupported things isn't "unacceptably short", it's actually pretty long. If this weren't OSS you could be happy about one month and most likely less. People complain about how little resources OSS projects have, but the scary truth is most commercial projects have even less resource and must ship at a dead line. Hence why it's very common for them to be far worse when it comes to code quality, technical dept, not correctly handled niche error cases etc.

> to every architecture they release for

Rust toolchain has support for every architecture _they_ release for, it breaks architectures niche unofficial 3rd party projects support. Which is sad, sure, but unsupported is in the end unsupported.

> cost-benefit analysis done for this change.

Who says it wasn't done at all. People have done so over and over on the internet for all kind of Linux distributions. But either way, you wouldn't include that in a mail announcing an intend for change (as you don't want discussions to be side tracked). Also benefits are pretty clear:

- using Sequoia for PGP seems to be the main driving force behind this decision, this projects exists because of repeating running into issues (including security issues) with the existing PGP tooling. It happens to use rust, but if there where no rust it still would exist. Just using a different language.

- some file format parsing is in a pretty bad state to a point you most likely will rewrite it to fix it/make it robust. When anyway doing so it using rust if preferable.

- and long term: Due to the clear, proven(1), benefits of using rust for _new_ project/code increasingly more use it, by not "allowing" rust to be required Debian bars itself form using any such project (like e.g. Sequoia which seems to be the main driver behind this change)

> this "rewrite it in rust" evangilism

which isn't part of this discussion at all,

the main driving part seems to be to use Sequoia, not because Sequoia is in rust but because Sequoia is very well made and well tested.

Similar Sequoia isn't a "lets re-write everything in rust project" but a "state of PGP tooling" is so painful for certain use cases (not all) in ways you can't fix by trying to contribute upstream that some people needed a new tooling, and rust happened to be the choice for implementing that.

Re: APT Rust requirement raises questions

#299

Post by mixmastamyk »

Aurornis wrote: post #56
dv35z wrote: post #31

Every time I consider learning Rust, I am thrown back by how... "janky" the syntax is. It seems to me that we ought to have a system-level language which builds upon the learnings of the past 20+ years. Can someone help me understand this? Why are we pushing forward with a language that has a Perl-esque unreadability...? Comparison: I often program in Python (and teach it) - and while it has its own syntax warts & fr…

> Comparison: I often program in Python (and teach it) - and while it has its own syntax warts & frustrations - overall the language has a "pseudocode which compiles" approach, which I appreciate. I think this is why you don’t like Rust: In Rust you have to be explicit by design. Being explicit adds syntax. If you appreciate languages where you can write pseudocode and have the details handled automatically for you,…

> Being explicit adds syntax.

Not what they are talking about. Rather better to use words instead of symbols, like python over perl.

Instead of “turbofish” and , there could be more key words like mut or dyn. Semicolons and ‘c’har are straight out of the seventies as well. :: not useful and ugly, etc.

Dunders avoid namespace collisions and are not a big problem in practice, all one char, and easy to read. I might remove the trailing part if I had the power.

Re: APT Rust requirement raises questions

#300

Post by adastra22 »

jandrese wrote: post #183
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.

While it kinda flies under the radar, most modern C projects do have a kind of package management solution in the form of pkg-config. Instead of the wild west of downloading and installing every dependency and figuring out how to integrate it properly with the OS and your project you can add a bit of syntactic sugar to your Makefile and have that mostly handled for you, save for the part where you will need to use yo…

Unless you are using nix or something, pkg-config is comparing apples to oranges.
Post reply on HN