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

191–200 of 508 posts

Re: APT Rust requirement raises questions

#191

Post by raincole »

freedomben wrote: post #163
raincole wrote: post #136

Earlier quoted context omitted.

> Cargo is a terrifying nightmare Really? Why? I'm not a Rust guru, but Cargo is the only part of Rust that gave me a great first impression.

GP mostly answered that in the comment already: > If you could install regular rust dependencies with "apt install" in debian stable, that would be a different story! But no. They want the version churn: continuously adding and removing bugs, like particle/anti-particle pairs at the boundary of a black hole.

I don't know, it doesn't explain how and why Cargo causes "continuously adding and removing bugs, like particle/anti-particle pairs at the boundary of a black hole."

Re: APT Rust requirement raises questions

#192

Post by creata »

nullpoint420 wrote: post #157
simonask wrote: post #82

Earlier quoted context omitted.

> > really extreme use cases with lots of lifetime annotations and generic bounds You choose as your example a pretty advanced use case.

Which is the exact use case someone would choose rust for over other languages

No, the use cases of Rust are pretty much the same as the use cases of C++. Most Rust code shouldn't have objects with complicated lifetimes, just like most code in any language should avoid objects with complicated lifetimes.

Re: APT Rust requirement raises questions

#193

Post by morshu9001 »

jamespo wrote: post #156
morshu9001 wrote: post #109

Earlier quoted context omitted.

Both Python and JS evolved by building on top of older versions, but somehow JS did a way better job than Python, even though Py forced a major breaking change. Agree about Rust, all the syntax is necessary for what it's trying to do.

You mean typescript?

Before that. The classes and stuff added in ES6 and earlier

Re: APT Rust requirement raises questions

#194

Post by Kwpolska »

mrob wrote: post #33

The announcement says: >In particular, our code to parse .deb, .ar, .tar, and the HTTP signature verification code would strongly benefit from memory safe languages and a stronger approach to unit testing. I can understand the importance of safe signature verification, but how is .deb parsing a problem? If you're installing a malicious package you've already lost. There's no need to exploit the parser when the user h…

The parser can run before the user is asked for permission to make changes. The parsed metadata can then discourage the user from installing the package (e.g. because of extremely questionable dependencies).

Dependencies are probably in the apt database and do not need parsing, but not everything is, or perhaps apt can install arbitrary .deb files now?

Re: APT Rust requirement raises questions

#195

Post by nerdponx »

nofunsir wrote: post #176
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.

Unit tests does not make Software Engineering. That's simply part of the development phase, which should be the smallest phase out of all the phases involved in REAL Software Engineering, which is rarely even done these days, outside of DO-178 (et al) monotony. The entire private-to-public industry has even polluted upper management in defense software engineering into accepting SCRUM as somehow more desirable than t…

As far as I understand the idea behind scrum it's not that you don't plan, it's that you significantly shorten the planning-implementation-review cycle.

Re: APT Rust requirement raises questions

#196

Post by steveklabnik »

creata wrote: post #175
simonw wrote: post #71

Earlier quoted context omitted.

trait Handler { fn handle (&self, input: &'a str) -> Result ; } fn process_handler ( handler: Box , input: &'a str, ) -> Result { handler.handle(input) }

That's just a weird and unrealistic example, though. Like, why is process_handler taking an owned, boxed reference to something it only needs shared access to? Why is there an unnecessary 'a bound on handler? In the places where you need to add lifetime annotations, it's certainly useful to be able to see them in the types, rather than relegate them to the documentation like in C++; cf. all the places where C++'s STL…

I agree that the signature for process_handler is weird, but you could steelman it to take a borrowed trait object instead, which would have an extra sigil.

The handler function isn't actually unnecessary, or at least, it isn't superfluous: by default, the signature would include 'a on self as well, and that's probably not what you actually want.

I do think that the example basically boils down to the lifetime syntax though, and yes, while it's a bit odd at first, every other thing that was tried was worse.

Re: APT Rust requirement raises questions

#197

Post by WD-42 »

creata wrote: post #175
simonw wrote: post #71

Earlier quoted context omitted.

trait Handler { fn handle (&self, input: &'a str) -> Result ; } fn process_handler ( handler: Box , input: &'a str, ) -> Result { handler.handle(input) }

That's just a weird and unrealistic example, though. Like, why is process_handler taking an owned, boxed reference to something it only needs shared access to? Why is there an unnecessary 'a bound on handler? In the places where you need to add lifetime annotations, it's certainly useful to be able to see them in the types, rather than relegate them to the documentation like in C++; cf. all the places where C++'s STL…

LLMs LOVE to write Rust like this. They add smart pointers, options and lifetimes everywhere when none of those things are necessary. I don’t know what it is, but they love over-engineering it.

Re: APT Rust requirement raises questions

#198

Post by Onavo »

reidrac wrote: post #12
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…

> As an end user, it doesn't concern me too much ... It doesn't concern me neither, but there's some attitude here that makes me uneasy. This could have been managed better. I see a similar change in the future that could affect me, and there will be precedent. Canonical paying Devs and all, it isn't a great way of influencing a community.

> Canonical paying Devs and all, it isn't a great way of influencing a community.

That's kind of the point of modern open source organizations. Let corporations fund the projects, and in exchange they get a say in terms of direction, and hopefully everything works out. The bigger issue with Ubuntu is that they lack vision, and when they ram things through, they give up at the slightest hint of opposition (and waste a tremendous amount of resources and time along the way). For example Mir and Unity were perfectly fine technologies but they retired it because they didn't want to see things through. For such a successful company, it's surprising that there technical direction setting is so unserious.

https://www.reddit.com/r/linux/comments/15brwi0/why_canonica...

Re: APT Rust requirement raises questions

#199

Post by creata »

steveklabnik wrote: post #196
creata wrote: post #175

Earlier quoted context omitted.

That's just a weird and unrealistic example, though. Like, why is process_handler taking an owned, boxed reference to something it only needs shared access to? Why is there an unnecessary 'a bound on handler? In the places where you need to add lifetime annotations, it's certainly useful to be able to see them in the types, rather than relegate them to the documentation like in C++; cf. all the places where C++'s STL…

I agree that the signature for process_handler is weird, but you could steelman it to take a borrowed trait object instead, which would have an extra sigil. The handler function isn't actually unnecessary, or at least, it isn't superfluous: by default, the signature would include 'a on self as well, and that's probably not what you actually want. I do think that the example basically boils down to the lifetime syntax…

> The handler function isn't actually unnecessary, or at least, it isn't superfluous: by default, the signature would include 'a on self as well, and that's probably not what you actually want.

To clarify, I meant the 'a in `Box` in the definition of `process_handler` is unnecessary. I'm not saying that the parameter in the definition of Handler::handle is unnecessary, which seems to be what you think I said, unless I misunderstood.

Re: APT Rust requirement raises questions

#200

Post by [deleted] »

xscott wrote: post #165
movpasd wrote: post #84

Earlier quoted context omitted.

You might this blog post interesting, which argues that it's Rust semantics and not syntax that results in the noisiness, i.e.: it's intrinsic complexity: https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html I found it reasonably convincing. For what it's worth, I found Rust's syntax quite daunting at first (coming from Python as well), but it only took a few months of continuous use to get used to it. I think…

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…

[deleted]
Post reply on HN