Live data from Hacker News

APT Rust requirement raises questions

lwn.net

71–80 of 508 posts

Re: APT Rust requirement raises questions

#71
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…

What are you talking about? Rust’s function signature and type declaration syntaxes are extremely vanilla, unless you venture into some really extreme use cases with lots of lifetime annotations and generic bounds. I seriously don’t get it. fn add(a: i32, b: i32) -> i32 { … } Where’s the “Perl-esqueness”?

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

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

Re: APT Rust requirement raises questions

#72
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…

What are you talking about? Rust’s function signature and type declaration syntaxes are extremely vanilla, unless you venture into some really extreme use cases with lots of lifetime annotations and generic bounds. I seriously don’t get it. fn add(a: i32, b: i32) -> i32 { … } Where’s the “Perl-esqueness”?

That's simple even in Perl. The problem is when you start adding the expected idioms for real world problems.

Re: APT Rust requirement raises questions

#73

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…

There are many high profile DDs who work or have worked for Canonical who are emphatically not the inverse — Canonical employees who are part of the Debian org. The conclusion you drew is perfectly reasonable but I’m not sure it is correct, especially when in comparison Canonical is the newcomer. It could even be seen to impugn their integrity.

If you look at the article, it seems like the hard dependency on Rust is being added for parsing functionality that only Canonical uses:

> David Kalnischkies, who is also a major contributor to APT, suggested that if the goal is to reduce bugs, it would be better to remove the code that is used to parse the .deb, .ar, and .tar formats that Klode mentioned from APT entirely. It is only needed for two tools, apt-ftparchive and apt-extracttemplates, he said, and the only ""serious usage"" of apt-ftparchive was by Klode's employer, Canonical, for its Launchpad software-collaboration platform. If those were taken out of the main APT code base, then it would not matter whether they were written in Rust, Python, or another language, since the tools are not directly necessary for any given port.

Re: APT Rust requirement raises questions

#74

Earlier quoted context omitted.

That’s also not something anybody has actually said.

While no one has explicitly said that, it is the implied justification of rewriting so much stuff in rust

I disagree very strongly that a suggestion to change something is also a personal attack on the author of the original code. That’s not a professional or constructive attitude.

Re: APT Rust requirement raises questions

#75

Earlier quoted context omitted.

The problem is that rust is being shoved in pointless places with a rewrite-everything-in-rust mentality. There's lunatics that want to replace basic Unix tools like sudo, etc, that are battle tested since ages which has been a mess of bugs till now. Instead Rust should find it's niches beyond rewriting what works, but tackling what doesn't.

Is the apt package manager a pointless place? It seems like a pretty foundational piece of supply chain software with a large surface area.

The author of the rust software did not solve the platform problem, as a result it is not a solution. Since it is not a solution, it should be reverted. It's really that simple.

Re: APT Rust requirement raises questions

#76
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…

Maybe I've Stockholm'd myself, but I think Rust's syntax is very pleasant. I also think a lot of C code looks very good (although there is some _ugly_ C code out there).

Sometimes the different sets of angle and curly brackets adding up can look ugly at first, and maybe the anonymous function syntax of || {}, but it grows on you if you spend some time with the language (as do all syntaxes, in my experience).

Re: APT Rust requirement raises questions

#77
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…

I'm writing this as a heavy python user in my day job. Python is terrible for writing complex systems in. Both the language and the libraries are full of footguns for the novice and expert alike. It has 20 years of baggage, the packaging and environment handling is nothing short of an unmitigated disaster, although uv seems to be a minor light at the end of the tunnel. It is not a simple language at this point. It ha…

Python had already become vastly popular before ML/AI. Scripting/tools/apps/web/... Only space that hasn't entered is mobile.

Re: APT Rust requirement raises questions

#78
post #43

Earlier quoted context omitted.

That’s also not something anybody has actually said.

Are you serious? It's basically impossible to discuss C/C++ anymore without someone bringing up Rust. If you search for HN posts with C++ in the title from the last year, the top post is about how C++ sucks and Rust is better. The fourth result is a post titled "C++ is an absolute blast" and the comments contain 128 (one hundred and twenty eight) mentions of the word "Rust". It's ridiculous.

Lots of current and former C++ developers are excited about Rust, so it’s natural that it comes up in similar conversations. But bringing up Rust in any conversation still does not amount to a personal attack, and I would encourage some reflection here if that is your first reaction.

Re: APT Rust requirement raises questions

#79
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…

Syntax tends to be deeply personal. I would say the most straightforward answer to your question is "many people disagree that it is unreadable." Rust did build on the learnings of the past 20 years. Essentially all of its syntax was taken from other languages, even lifetimes.

Are the many who disagree that it is unreadable more than the people who agree? I have been involved with the language for a while now, and while I appreciate what you and many others have done for it, the sense that the group is immune to feedback just becomes too palpable too often. That, and the really aggressive PR.

Rust is trying to solve a really important problem, and so far it might well be one of the best solutions we have for it in a general sense. I 100% support its use in as many places as possible, so that it can evolve. However, its evolution seems to be thwarted by a very vocal subset of its leadership and community who have made it a part of their identity and whatever socio-political leverage toolset they use.

Re: APT Rust requirement raises questions

#80
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.

The problem is that rust is being shoved in pointless places with a rewrite-everything-in-rust mentality. There's lunatics that want to replace basic Unix tools like sudo, etc, that are battle tested since ages which has been a mess of bugs till now. Instead Rust should find it's niches beyond rewriting what works, but tackling what doesn't.

Calling it pointless comes across as jaded. It's not pointless.

Supporting Rust attracts contributors, and those contributors are much less likely to introduce vulnerabilities in Rust when contributing vs alternatives.

Post reply on HN