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

91–100 of 508 posts

Re: APT Rust requirement raises questions

#91

Post by piva00 »

simonw wrote: post #71
simonask wrote: post #50

Earlier quoted context omitted.

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) }

Could have thrown a few uses of macros with the # and ! which threw me off completely while trying to read a Rust codebase as a non-Rust programmer.

Re: APT Rust requirement raises questions

#92

Post by gorgoiler »

”[One] major contributor to APT suggested it would be better to remove the Rust code entirely as it is only needed by Canonical for its Launchpad platform. If it 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 regular installations].”

Given the abundance of the hundreds of deb-* and dh-* tools across different packages, it is surprising that apt isn’t more actively split into separate, independent tools. Or maybe it is, but they are all in a monorepo, and the debate is about how if one niche part of the monorepo uses Rust then the whole suite can only be built on platforms that support Rust?

  #!/bin/sh
  build_core
  if has_rust
  then
    build_launchpad_utils
  fi
It’s like arguing about the bike shed when everyone takes the bus except for one guy who cycles in every four weeks to clean the windows.

Re: APT Rust requirement raises questions

#93

Post by pohl »

brettermeier wrote: post #83
shmolyneaux wrote: post #46

Earlier quoted context omitted.

I would encourage you to give it a try anyways. Unfamiliar syntax is off-putting for sure, but you can get comfortable with any syntax. Coming from Python, I needed to work on some legacy Perl code. Perl code looks quite rough to a new user. After time, I got used to it. The syntax becomes a lot less relevant as you spend more time with the language.

Sure... but you don't want to spend time if it's such a mess to read it.

Once one does spend some time to become comfortable with the language, that feeling of messiness with unfamiliar syntax fades away. That's the case with any unfamiliar language, not just Rust.

Re: APT Rust requirement raises questions

#94

Post by simonask »

handwarmers wrote: post #79
steveklabnik wrote: post #41

Earlier quoted context omitted.

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

This is such a weird take. What do you suggest? Should Rust’s syntax have been democratically decided?

Re: APT Rust requirement raises questions

#95

Post by tayo42 »

handwarmers wrote: post #79
steveklabnik wrote: post #41

Earlier quoted context omitted.

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

> the sense that the group is immune to feedback

Is complaining about syntax really productive though? What is really going to be done about it?

Re: APT Rust requirement raises questions

#96

Post by enriquto »

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…

> 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 language!

The main problem with rust is that the community around it has embraced all the toxic traditions of the js/node ecosystem, and then some. Cargo is a terrifying nightmare. 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.

Concerning TFA, adding rust to apt might be a step in the right direction. But it should be symmetric: apt depends on rust, that's great! But all the rust that it depends on needs to be installed by apt, and by apt alone!

Re: APT Rust requirement raises questions

#97

Post by marcosdumay »

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…

.deb is a packaging format like any other. There are plenty of reasons for parsing without running the code inside them.

Re: APT Rust requirement raises questions

#98

Post by dboon »

dralley wrote: post #17
epolanski wrote: post #11

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.

Converting parsers to Rust is not "pointless". Doing string manipulation in C is both an awful experience and also extremely fertile ground for serious issues.

It’s very easy to write a string library in C which makes string operations high level (both in API and memory management). Sure, you shouldn’t HAVE to do this. I get it. But anyone writing a parser is definitely skilled enough to maintain a couple hundred lines of code for a linear allocator and a pointer plus length string. And to be frank, doing things like “string operations but cheaply allocated” is something you have to do ANYWAY if you’re writing e.g. a parser.

This holds for many things in C

Re: APT Rust requirement raises questions

#99

Post by gorgoiler »

ndiddy wrote: post #73
gorgoiler wrote: post #54

Earlier quoted context omitted.

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

I understand, but the comment to which I was replying implied that this keeps happening, and in general. That’s not fair to the N-1 other DDs who aren’t the subject of this LWN article (which I read!)

Re: APT Rust requirement raises questions

#100

Post by tsimionescu »

fainpul wrote: post #66
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…

> Is there a "Kotlin for Rust"? While it's not a systems language, have you tried Swift?

Swift is as relevant to this discussion as Common Lisp.
Post reply on HN