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

81–90 of 508 posts

Re: APT Rust requirement raises questions

#81

Post by DeathArrow »

debo_ wrote: post #58
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…

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.

Re: APT Rust requirement raises questions

#82

Post by simonask »

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

> > really extreme use cases with lots of lifetime annotations and generic bounds

You choose as your example a pretty advanced use case.

Re: APT Rust requirement raises questions

#83

Post by brettermeier »

shmolyneaux wrote: post #46
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 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.

Re: APT Rust requirement raises questions

#84

Post by movpasd »

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…

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 "Perl-esque" is an overstatement.

It has some upsides over Python as well, notably that the lack of significant whitespace means inserting a small change and letting the autoformatter deal with syntax changes is quite easy, whereas in Python I occasionally have to faff with indentation before Black/Ruff will let me autoformat.

I appreciate that for teaching, the trade-offs go in the other direction.

Re: APT Rust requirement raises questions

#85

Post by jvanderbot »

bakugo wrote: post #9
jvanderbot wrote: post #6

Earlier quoted context omitted.

I think you'll experience some pushback on the assertion that that particular quote has a lot of arrogance or disdain in it. Building large legacy projects can be difficult and tapping into a thriving ecosystem of packages might be a good thing. But it's also possible to have "shiny object" or "grass is greener" syndrome.

> I think you'll experience some pushback on the assertion that that particular quote has a lot of arrogance or disdain in it. It's just a roundabout way of saying "anything that isn't running Rust isn't a REAL computer". Which is pretty clearly an arrogant statement, I don't see any other way of interpreting it.

I read it as a straightforward way of saying "support for a few mostly unused architectures is all that is holding us back from adopting rust, and adopting rust is viewed as a good thing"

Re: APT Rust requirement raises questions

#86

Post by thousand_nights »

tcfhgj wrote: post #39
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…

what makes it unreadable for you?

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

Re: APT Rust requirement raises questions

#87

Post by leoh »

I hate learning new things. It sucks. Also, I hate things that make my knowledge of C++ obsolete. I hate all the people that are getting good at rust and are threatening to take away my job. I hate that rust is a great leveler, making all my esoteric knowledge of C++ that I have been able to lord over others irrelevant. I hate that other people are allowed to do this to me and to do whatever they want, like making the decision to use rust in apt. It’s just sad and crazy to me. I can’t believe it. There are lots of people like me who are scared and angry and we should be able to control anyone else who makes us feel this way. Wow, I’m upset. I hope there is another negative post about rust I can upvote soon.

Re: APT Rust requirement raises questions

#88

Post by Muromec »

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…

It is possible the deb package is parsed to extract some metadata before being installed and before verifying signature.

Also there is aspect of defence in depth. Maybe you can compromise one package that itself can't do much, but installer runs with higher priviledges and has network access.

Another angle -- installed package may compromise one container, while a bug in apt can compromise the environment which provisions containers.

And then at some point there is "oh..." moment when the holes in different layers align nicely to make four "bad but not exploitable" bugs into a zero day shitshow

Re: APT Rust requirement raises questions

#89

Post by marcosdumay »

epolanski wrote: post #11
petcat wrote: 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.

Cue for all those battle tested programs that people keep finding vulnerabilities several decades after they got considered "done". You should try looking at the test results once in a while.

And by the way, we had to replace almost all of the basic Unix tools at the turn of the century because they were completely unfit for purpose. There aren't many left.

Re: APT Rust requirement raises questions

#90

Post by tcfhgj »

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

now show me an alternative syntax encoding the same information
Post reply on HN