APT Rust requirement raises questions

https://lwn.net/SubscriberLink/1046841/5bbf1fc049a18947/

by todsacerdoti • 8 months ago

266 445 8 months ago

petcat• 8 months ago

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.

sidewndr462• 8 months ago

All compilers do anyways is translate from one language specification to another. There's nothing magical about Rust or any specific architecture target. The compiler of a "memory safe" language like Rust could easily output assembly with severe issues in the presence of a compiler bug. There's no difference between compiling to assembly vs. C in that regard.

simonask5• 8 months ago

The assumption here is that there exists an unambiguous C representation for all LLVM IR bitcode emitted by the Rust compiler.

To my knowledge, this isn’t the case.

tsimionescu3• 8 months ago

The gigantic difference is that assembly language has extremely simple semantics, while C has very complex semantics. Similarly, assembler output is quite predictable, while C compilers are anything but. So the level of match between the Rust code and the machine code you'll get from a Rust-to-assembly compiler will be much, much easier to understand than the match you'll get between the Rust code and the machine code produced by a C compiler compiling C code output by a Rust-to-C transpiler.

epolanski3• 8 months ago

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.

genewitch• 8 months ago

We need lisp, cobol, and java in apt, too. and firefox.

VWWHFSfQ• 8 months ago

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

sidewndr462• 8 months ago

I seem to remember going through this with systemD in Ubuntu. Lots of lessons learned seemed to come back as "didn't we fix this bug 3 years ago?"

dralley• 8 months ago

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.

mmastrac• 8 months ago

sudo is not fully battle tested, even today. You just don't really see the CVEs getting press.

https://www.oligo.security/blog/new-sudo-vulnerabilities-cve...

saghm2• 8 months ago

FWIW sudo has been maintained by an OpenBSD developer for a while now but got replaced in the base system by doas. Independent of any concerns about Rust versus C, I don't think it's quite as unreasonable as you're claiming to consider alternatives to sudo given that the OS that maintains it felt that it was flawed enough to be worth writing a replacement for from scratch.

honeycrispy• 8 months ago

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.

marcosdumay2• 8 months ago

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.

anarki82• 8 months ago

The problem is that rust is being shoved in pointless places with a rewrite-everything-in-rust mentality.
There's lunatics ...

I think the problem is people calling developers "lunatics" and telling them which languages they must use and which software they must not rewrite.

Battle tested is not bulletproof: https://cybersecuritynews.com/sudo-linux-vulnerability/

Applying strict compile time rules makes software better. And with time it will also become battle tested.

forgotpwd163• 8 months ago

tool that can translate memory-safe Rust code into memory-unsafe C code

Fwiw, there're two such ongoing efforts. One[1] being an, written in C++, alternative Rust compiler that emits C (aka, in project's words, high-level assembly), the other[2] being a Rust compiler backend/plugin (as an extra goal to its initial being to compile Rust to CLR asm). Last one apparently is[3] quite modular and could be adapted for other targets too. Other options are continuing/improve GCC front-end for Rust and a recent attempt to make a Rust compiler in C[4] that compiles to QBE IR which can then be compiled with QBE/cc.

[1] https://github.com/thepowersgang/mrustc [2]: https://github.com/FractalFir/rustc_codegen_clr [3]: https://old.reddit.com/r/rust/comments/1bhajzp/ [4]: https://codeberg.org/notgull/dozer

pabs3• 8 months ago

Also there is a rustc codegen backend that uses GCC, so you can just skip the C part:

https://github.com/rust-lang/rustc_codegen_gcc

pbohun• 8 months ago

That's not what the comment said. It said, "How about a Rust to C converter?..." The idea was that using a converter could eliminate the problem of not having a rust compiler for certain platforms.

geerlingguy• 8 months ago

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 wider non-Ubuntu community.

I think the whole message would be more palatable if it weren't written as a decree including the dig on "retro computers", but instead positioned only on the merits of the change.

As an end user, it doesn't concern me too much, but someone choosing to add a new dependency chain to critical software plumbing does, at least slightly, if not done for very good reason.

reidrac• 8 months ago

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.

Onavo• 8 months ago

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

tremon• 8 months ago

I agree. It's sad to see maintainers take a "my way or the highway" approach to package maintenance, but this attitude has gradually become more accepted in Debian over the years. I've seen this play before, with different actors: gcc maintainers (regarding cross-bootstrapping ports), udev (regarding device naming, I think?), systemd (regarding systemd), and now with apt. Not all of them involved Canonical employees, and sometimes the Canonical employees were the voice of reason (e.g. that's how I remember Steve Langasek).

I'm sure some will point out that each example above was just an isolated incident, but I perceive a growing pattern of incidents. There was a time when Debian proudly called itself "The Universal Operating System", but I think that hasn't been true for a while now.

gorgoiler3• 8 months ago

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.

ndiddy• 8 months ago

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.

Aurornis8• 8 months ago

I think the whole message would be more palatable if it weren't written as a decree including the dig on "retro computers", but instead positioned only on the merits of the change.

The wording could have been better, but I don’t see it as a dig. When you look at the platforms that would be left behind they’re really, really old.

It’s unfortunate that it would be the end of the road for them, but holding up progress for everyone to retain support for some very old platforms would be the definition of the tail wagging the dog. Any project that starts holding up progress to retain support for some very old platforms would be making a mistake.

It might have been better to leave out any mention of the old platforms in the Rust announcement and wait for someone to mention it in another post. As it was written, it became an unfortunate focal point of the announcement despite having such a small impact that it shouldn’t be a factor holding up progress.

miladyincontrol2• 8 months ago

Not just really, really old, but they in fact have long since been depreciated in any semblance of official support.

I get the friction especially for younger contributors, not that this is the case here. However there are architectures that havent even received a revision in their lifetime which old heads will take as personal slights for which heads must roll when presented with even the slightest of inconvenience for their hobbyist port.

jancsika• 8 months ago

The wording could have been better, but I don’t see it as a dig.

He created (or at least re-activated) a dichotomy for zero gain, and he vastly increased the expectations for what a Rust rewrite can achieve. That is very, very bad in a software project.

The evidence for both is in your next paragraph. You immediately riff on his dichotomy:

It’s unfortunate that it would be the end of the road for them, but holding up progress for everyone to retain support for some very old platforms would be the definition of the tail wagging the dog.

(My emphasis.)

He wants to do a rewrite in Rust to replace old, craggy C++ that is so difficult to reason about that there's no chance of attracting new developers to the maintenance team with it. Porting to Rust therefore a) addresses memory safety, b) gives a chance to attract new developers to a core part of Debian, and c) gives the current maintainer a way to eventually leave gracefully in the future. I think he even made some these points here on HN. Anyone who isn't a sociopath sympathizes with these points. More importantly, accidentally introducing some big, ugly bug in Rust apt isn't at odds with these goals. It's almost an expected part of the growing pains of a rewrite plus onboarding new devs.

Compare that to "holding up progress for everyone." Just reading that phrase makes me force sensitive like a Jedi: I can feel the spite of dozens HN'ers tingling at that and other phrases in these HN comments as they sharpen their hatred, ready to pounce at the Rust Evangelists the moment this project hits a snag. (And, like any project, it will hit snags.)

1. "I'm holding on for dear life here, I need help from others and this is the way I plan to get that help"

2. "Don't hold back everyone else's progress, please"

The kind of people who hear "key party" and imagine clothed adults reciting GPG fingerprints need to comprehend that #1 and #2 are a) completely different strings and b) have very different-- let's just say magical-- effects on the behavior of even small groups of humans.

razighter7773• 8 months ago

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 support for multiple ports to rewrite some feature for a tiny security benefit. And doing so on an unacceptably short timeline. Introducing breakage like this is unacceptable.

There's no clear cost-benefit analysis done for this change. Canonical or debian should work on porting the rust toolchain (ideally with tier 1 support) to every architecture they release for, and actually put the cart before the horse.

I love and use rust, it is my favorite language and I use it in several of my OSS projects but I'm tired of this "rewrite it in rust" evangilism and the reputational damage they do to the rust community.

foota• 8 months ago

*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."

Imo this is true for going from one to a handful, but less true when going from a handful to more. Afaict there are 6 official ports and 12 unofficial ports (from https://www.debian.org/ports/).

Aurornis8• 8 months ago

This is breaking support for multiple ports to rewrite some feature for a tiny security benefit. And doing so on an unacceptably short timeline. Introducing breakage like this is unacceptable. I’m Normally I’d agree, but the ports in question are really quite old and obscure. I don’t think anything would have changed with an even longer timeline.

I think the best move would have been to announce deprecation of those ports separately. As it was announced, people who will never be impacted by their deprecation are upset because the deprecation was tied to something else (Rust) that is a hot topic.

If the deprecation of those ports was announced separately I doubt it would have even been news. Instead we’ve got this situation where people are angry that Rust took something away from someone.

locknitpicker• 8 months ago

I love and use rust, it is my favorite language and I use it in several of my OSS projects but I'm tired of this "rewrite it in rust" evangilism and the reputational damage they do to the rust community.

This right here.

As a side-note, I was reading one of Cloudflare's docs on how it implemented its firewall rules, and it's so utterly disappointing how the document stops being informative suddenly start to reads like a parody of the whole cargo cult around Rust. Rust this, Rust that, and I was there trying to read up on how Cloudflare actually supports firewall rules. The way they focus on a specific and frankly irrelevant implementation detail conveys the idea things are ran by amateurs that are charmed by a shiny toy.

travisgriggs• 8 months ago

I love and use rust, it is my favorite language and I use it in several of my OSS projects but I'm tired of this "rewrite it in rust" evangilism and the reputational damage they do to the rust community.

Thanks for this.

I know intellectually, that there are sane/pragmatic people who appreciate Rust.

But often the vibe I’ve gotten is the evangelism, the clear “I’ve found a tribe to be part of and it makes me feel special”.

So it helps when the reasonable signal breaks through the noisy minority.

kevin_thibedeau• 8 months ago

Canonical or debian should work on porting the rust toolchain (ideally with tier 1 support) to every architecture they release for

This will be an impediment for new architectures in the future. Instead of just "builds with gcc" we would need to wait for Rust support.

dathinab2• 8 months ago

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.

crote9• 8 months ago

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.

The problem is that those ports aren't supported and see basically zero use. Without continuous maintainer effort to keep software running on those platforms, subtle platform-specific bugs will creep in. Sometimes it's the application's fault, but just as often the blame will lie with the port itself.

The side-effect of ports being unsupported is that build failures or test failures - if they are even run at all - aren't considered blockers. Eventually their failure becomes normal, so their status will just be disregarded as noise: you can't rely on them to pass when your PR is bug-free, so you can't rely on their failure to indicate a genuine issue.

pjmlp4• 8 months ago

I fully agree, and in what concerns command line utility applications I see no benefit of using Rust's borrow checker.

At most if a rewrite would happen, it makes much more sense in a compiled language with automatic resource management.

eggy3• 8 months ago

I totally agree. In reality, today, if you want to produce auditable high-integrity, high-assurance, mission-critical software, you should be looking at SPARK/Ada and even F* (fstar). SPARK has legacy real world apps and a great eco system for this type of sofware. F* is being used on embedded and in other realworld apps where formal verification is necessary or highly advantageous. Whether I like Rust or not, should not be the defining factor. AdaCore has a verifed Rust compiler, but the tooling around it does not compare to that around SPARK/Ada. I've heard younger people complain about PLs being verbose, boring, or not their thing, and unless you're a diehard SPARK/Ada person, you probably feel that way about it too. But sometimes the tool doesn't have to be sexy or the latest thing to be the right thing to use. Name one Rust realworld app older than 5 years that is in this category.

ForHackernews5• 8 months ago

Canonical or debian should work on porting the rust toolchain (ideally with tier 1 support) to every architecture they release for, and actually put the cart before the horse.

They already have a Rust toolchain for every system Debian releases for.

The only architectures they're arguing about are non-official Debian ports for "Alpha (alpha), Motorola 680x0 (m68k), PA-RISC (hppa), and SuperH (sh4)", two of which are so obscure I've never even heard of them and one of the others most famous for powering retro video game systems like Sega Genesis.

oconnor663• 8 months ago

to rewrite some feature for a tiny security benefit

For what it's worth, the zero->one introduction of a new language into a big codebase always comes with a lot of build changes, downstream impact, debate, etc. It's good for that first feature to be some relatively trivial thing, so that it doesn't make the changes any bigger than they have to be, and so that it can be delayed or reverted as needed without causing extra trouble. Once everything lands, then you can add whatever bigger features you like without disrupting things.

No comment on the rest of the thread...

astrobe_• 8 months ago

I think the whole message would be more palatable if it weren't written as a decree including the dig on "retro computers"

Yes, and more generally, as far as I am concerned, the antagonizing tone of the message, which is probably partly responsible for this micro-drama, is typical of some Rust zealots who never miss an occasion to remind C/C++ that they are dinosaurs (in their eyes). When you promote your thing by belittling others, you are doing it wrong.

maeln• 8 months ago

You know, it is easy to find this kind of nitpicking and seemingly eternal discussion over details exhausting and meaningless, but I do think it is actually a good sign and a consequence of "openness". In politics, authoritarianism tend to show a pretty façade where everyone mostly agrees (the reality be damned), and discussion and dissenting voice are only allowed to a certain extent as a communication tool. This is usually what we see in corporate development.

Free software are much more like democracy, everyone can voice their opinion freely, and it tends to be messy, confrontational, nitpicky. It does often lead to slowing down changes, but it also avoids the common pitfall of authoritarian regime of going head first into a wall at the speed of light.

cogman107• 8 months ago

What?

Opensource software doesn't have 1 governance model and most of it starts out as basically a pure authoritarian run.

It's only as the software ages, grows, and becomes more integral that it switches to more democratic forms of maintenance.

Even then, the most important OS code on the planet, the kernel, is basically a monarchy with King Linus holding absolute authority to veto the decision of any of the Lords. Most stuff is maintained by the Lords but if Linus says "no" or "yes" then there's no parliament which can override his decision (beyond forking the kernel).

fn-mote• 8 months ago

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 the "new solver" currently lacks a testsuite (unit tests; it has integration tests). I'm actually kind of surprised that writing a dependency solver is a greenfield project instead of using an existing one. Or is this just a dig at something that pulls in a well-tested external module for solving?

Posted in curiosity, not knowing much about apt.

stonemetal12• 8 months ago

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?

steveklabnik25• 8 months ago

Cargo's solver incorporates concepts that .debs don't have, like Cargo features, and I'm sure that .debs have features that Cargo packages don't have either.

mikepurvis3• 8 months ago

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.

pornel4• 8 months ago

Cargo isn't satisfied with its own solver either. Solvers are a hard and messy problem.

The problem is theoretically NP complete (a SAT solver), but even harder than that: users also care about picking solutions that optimize for multiple criteria like minimal changes, more recent versions, minimal duplication (if multiple versions can coexist), all while having easy-to-understand errors when dependencies can't be satisfied, and with better-than-NP performance. It ends up being complex and full of compromises.

kzrdude• 8 months ago

Uv uses pugrub and maybe APT could too.

catlifeonmars2• 8 months ago

Dependency solvers are actually an area that can benefit from updating IMO.

inetknght2• 8 months ago

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.

nofunsir4• 8 months ago

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 the ability to effectively plan your requirements and execute without deviation. Yes it's possible, and yes it's even plausible. SWE laziness turns Engineers into developers. Running some auto-documentation script or a generic non-official block diagram is not the same as a Civil PE creating blueprints for a house, let alone a mile long bridge or skyscraper.

surajrmal• 8 months ago

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.

cactusfrog2• 8 months ago

Could the rust code be transpired to readable C?

estebank2• 8 months ago

readable

No, because some things that are UB in C are not in Rust, and vice versa, so any codegen has to account for that and will result in additional verbosity that you wouldn't see in "native" code.

dontlaugh5• 8 months ago

It seems silly to say that it has no tests. If I had to pick between unit and integration tests, I'd pick integration tests every time.

sedatk• 8 months ago

It has integration tests.

dv35z• 8 months ago

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 & frustrations - overall the language has a "pseudocode which compiles" approach, which I appreciate. Similarly, I appreciate what Kotlin has done with Java. Is there a "Kotlin for Rust"? or another high quality system language we ought to be investing in? I genuinely believe that languages ought to start with "newbie friendliness", and would love to hear challenges to that idea.

tcfhgj3• 8 months ago

what makes it unreadable for you?

forgotpwd163• 8 months ago

Legit question really. A comparative study on language readability using codes doing the same thing written idiomatically in different languages will be interesting. Beyond syntax, idioms/paradigm/familiarity should also play role.

thousand_nights• 8 months ago

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

steveklabnik25• 8 months ago

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.

handwarmers• 8 months ago

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.

aallaall• 8 months ago

There’s syntax that is objectively easier to both read and write, and there’s syntax that is both harder to read and write. For a majority.

In general, using english words consisting of a-z is easier to read. Using regex-like mojibake is harder.

For an concrete example in rust, using pipes in lambdas, instead of an arrow, is aweful.

JuniperMesos5• 8 months ago

The lifetime syntax was taken from OCaml but it has somewhat different semarics than OCaml. I honestly get a bit tripped up when I look at OCaml code (a language I'm a beginner at), and see ordinary parameterized types using syntax that suggests to me, from a Rust background, "woah, complex lifetime situation ahead!"

I know that Graydon Hoare is a fan of OCaml and that it was a core inspiration for Rust, and I sometimes wonder if he gets tripped up too by having to switch between Rust-inspired and OCaml-inspired interpretations of the same characters.

shmolyneaux• 8 months ago

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.

brettermeier• 8 months ago

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

simonask5• 8 months ago

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”?

simonw2• 8 months ago

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

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

haolez• 8 months ago

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

stingraycharles3• 8 months ago

Seems like a fairly decent syntax. It’s less simple than many systems languages because it has a very strong type system. That’s a choice of preference in how you want to solve a problem.

I don’t think the memory safety guarantees of Rust could be expressed in the syntax of a language like C or Go.

mbel• 8 months ago

It’s less simple than many systems languages because it has a very strong type system.

I don’t think that’s the case, somehow most ML derived languages ended up with stronger type system and cleaner syntax.

everybodyknows• 8 months ago

I code mostly in Go and the typing sloppiness is a major pain point.

Example: You read the expression "x.f", say, in the output of git-diff. Is x a struct object, or a pointer to a struct? Only by referring to enclosing context can you know for sure.

Aurornis8• 8 months ago

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, then you’re probably not going to enjoy any language that expects you to be explicit about details.

As far as “janky syntax”, that’s a matter of perspective. Every time I deal with Python and do things like “__slots__” it feels like janky layer upon layer of ideas added on top of a language that has evolved to support things it wasn’t originally planned to do, which feels janky to me. All of the things I have to do in order to get a performant Python program feel incredibly janky relative to using a language with first class support for the things I need to do.

morshu90015• 8 months ago

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.

mixmastamyk6• 8 months ago

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 <‘a>, 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.

short_sells_poo• 8 months ago

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 has had so many features tacked on, that it needs years of use to have a solid understanding of all the interactions.

Python is a language that became successful not because it was the best in it's class, but because it was the least bad. It became the lingua franca of quantitative analysis, because R was even worse and matlab was a closed ecosystem with strong whiffs of the 80s. It became successful because it was the least bad glue language for getting up and running with ML and later on LLMs.

In comparison, Rust is a very predictable and robust language. The tradeoff it makes is that it buys safety for the price of higher upfront complexity. I'd never use Rust to do research in. It'd be an exercise in frustration. However, for writing reliable and robust systems, it's the least bad currently.

forgotpwd163• 8 months ago

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

pxc2• 8 months ago

What's wrong with R? I used it and liked it in undergrad. I certainly didn't use it as seriously as the users who made Python popular, but to this day I remember R fondly and would never choose Python for a personal project.

My R use was self-taught, as well. I refused to use proprietary software for school all through high school and university, so I used R where we were expected to use Excel or MatLab (though I usually used GNU Octave for the latter), including for at least one or two math classes. I don't remember anything being tricky or difficult to work with.

debo_• 8 months ago

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 stuff like Python), one ML-type language (which will help with stuff like Rust) and one C-type language (for obvious reasons.)

[0] https://en.wikipedia.org/wiki/ML_(programming_language)

DeathArrow• 8 months ago

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

fainpul3• 8 months ago

Is there a "Kotlin for Rust"?

While it's not a systems language, have you tried Swift?

tsimionescu3• 8 months ago

Swift is as relevant to this discussion as Common Lisp.

raincole3• 8 months ago

Why are we pushing forward with a language that has a Perl-esque unreadability...?

The reason is the same for any (including Perl, except those meme languages where obfuscation is a feature) language: the early adopters don't think it's unreadable.

jjice• 8 months ago

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

movpasd• 8 months ago

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.

echelon3• 8 months ago

That's it exactly.

Once you're writing Rust at full speed, you'll find you won't be putting lifetimes and trait bounds on everything. Some of this becomes implicit, some of it you can just avoid with simpler patterns.

When you write Rust code without lifetimes and trait bounds and nested types, the language looks like Ruby lite.

When you write Rust code with traits or nested types, it looks like Java + Ruby.

When you sprinkle in the lifetimes, it takes on a bit of character of its own.

It honestly isn't hard to read once you use the language a lot. Imagine what Python looks like to a day zero newbie vs. a seasoned python developer.

You can constrain complexity (if you even need it) to certain modules, leaving other code relatively clean. Imagine the Python modules that use all the language features - you've seen them!

One of the best hacks of all: if you're writing HTTP services, you might be able to write nearly 100% of your code without lifetimes at all. Because almost everything happening in request flow is linear and not shared.

mrweasel• 8 months ago

That article is really good, because it highlight that Rust doesn't have to look messy. Part of the problem, I think, is that there's a few to many people who think that messy version is better, because it "uses more of the language" and it makes them look smarter. Or maybe Rust just makes it to hard to see through the semantics and realize that just because feature is there doesn't mean that you need it.

There's also a massive difference between the type of C or Perl someone like me would write, versus someone trying to cope with a more hostile environment or who requires higher levels of performance. My code might be easier to read, but it technically has issue, they are mostly not relevant, while the reverse is true for a more skilled developer, in a different environment. Rust seems to attract really skilled people, who have really defensive code styles or who use more of the provided language features, and that makes to code harder to read, but that would also be the case in e.g. C++.

jandrese3• 8 months ago

I think Perl-esque is apt, but that's because I've done quite a bit of Perl and think the syntax concerns are overblown. Once you get past the sigils on the variables Perl's syntax is generally pretty straightforward, albeit with a few warts in places like almost every language. The other area where people complained about Perl's opaqueness was the regular expressions, which most languages picked up anyway because people realized just how useful they are.

xscott13• 8 months ago

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::<u32>::new();
    let mut b = <Vec::<u32>>::new();
    let mut c = <Vec<u32>>::new();
    let mut d: Vec<u32> = 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 mut z = Vec<u32>::new();

However, the grammar is problematic here because of using less-than and greater-than as brackets in a type "context". You can explain that as either not learning from C++'s mistakes or trying to appeal to a C++ audience I guess.

Yes, I know there is a `vec!` macro. Will you require your coworkers to declare a similar macro when they start to implement their own generic types?

There are lots of other examples when you get to what traits are required to satisfy generics ("where clauses" vs "bounds"), or the lifetime signature stuff and so on...

You can argue that strong typing has some intrinsic complexity, but it's tougher to defend the multiple ways to do things, and that WAS one of Perl's mantras.

enriquto2• 8 months ago

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!

tcfhgj3• 8 months ago

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.

steveklabnik25• 8 months ago

Debian already builds Rust packages from apt, so it will satisfy that critera.

superxpro12• 8 months ago

As a c/c++ cmake user, cargo sounds like a utopia in comparison. It still amazes me that c/c++ package management is still spread between about 5 different solutions.

IMO, the biggest improvement to C/C++ would be ISO defining a package manager a.la pip or uv or cargo. I'm so tired of writing cmake. just... tired.

raincole3• 8 months ago

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.

newsoftheday• 8 months ago

Rust is like a "cleaned-up" C++

Except they got the order of type and variable wrong. That alone is enough reason to never use Rust, Go, TypeScript or any other language that botches such a critical cornerstone of language syntax.

JuniperMesos5• 8 months ago

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.

Something I didn't appreciate for a long time is that, the C/C++ ecosystem does have an npm-like package management ecosystem - it is just implemented at the level of Linux distro maintainers DDD deciding what to package and how. Which worked ok because C was the lingua franca of Unix systems.

But actually it's valuable for programmers to be able to specify their dependencies for their own projects and update them on a schedule unconnected and uncoordinated with the OS's releases. The cargo/npm model is closer to ideal.

Of course what is even better is NixOS-like declarative specification and hashing of all dependencies

ModernMech2• 8 months ago

upon the learnings of the past 20+ years.

That's the thing though... Rust does build on many of those learnings. For starters, managing a big type system is better when some types are implicit, so Rust features type inference to ease the burden in that area. They've also learned from C++'s mistake of having a context sensitive grammar. They learned from C++'s template nightmare error messages so generics are easier to work with. They also applied learnings about immutability being a better default that mutability. The reason Rust is statically linked and packages are managed by a central repository is based on decades of seeing how difficult it is to build and deploy projects in C++, and how easy it is to build and deploy projects in the Node / NPM ecosystem. Pattern matching and tagged unions were added because of how well they worked in functional languages.

As for "Perl-esque unreadability" I submit that it's not unreadable, you are just unfamiliar. I myself find Chinese unreadable, but that doesn't mean Chinese is unreadable.

Is there a "Kotlin for Rust"?

Kotlin came out 16 years after Java. Rust is relatively new, and it has built on other languages, but it's not the end point. Languages will be written that build on Rust, but that will take some time. Already many nascent projects are out there, but it is yet to be seen which will rise to the top.

maximilianburke3• 8 months ago

In your opinion how does Rust compare to C++ for readability?

adastra226• 8 months ago

C++ is vastly more readable. I will never go back to writing or maintaining C++ projects, but drop me into a C++ file to review something and it is usually very easy to grok.

Part of this is style and conventions though. I have implemented an STL container before, and that templating hell is far worse than anything I’ve ever seen in the Rust ecosystem. But someone following modern C++ conventions (e.g. a Google library) produces very clean and readable code.

teunispeters• 8 months ago

Honestly, rust is slightly more readable than obfuscated perl. I think I prefer K&R C, and I don't like K&R C. In terms of readability, maybe equivalent to early Win32 API? [3000 lines to set up API, then call to activate].

With C++ you have a range of readable from - easy and very approachable - to 2000s era Microsoft STL. (where not only is it close to unreadable, many many hidden bugs are ... somewhere. And behaviour is not consistent).

I will admit I don't find Rust quite as unreadable as the 2000s era Microsoft STL, but the latter's one of the things that pushed me far more into Linux dev.

Rust is the kind of language that would push me to write a new language that isn't rust. And maybe work on supporting all the zillion platforms rust doesn't support. Or maybe just stick to C. I'm not a fan, but there are worse, and yeah - there are some C++ libraries out there that are worse. Lots that are better, too, eg llvm source.

EugeneOZ• 8 months ago

Does it really add any value to the conversation?

whimsicalism• 8 months ago

I don’t program much in Rust, but I find it a beautiful syntax… they took C++ and made it pretty much strictly better along with taking some inspiration from ML (which is beautiful imo)

WD-425• 8 months ago

I’ve been writing python professionally for over 10 years. In the last year I’ve been writing more and most Rust. At first I thought the same as you. It’s a fugly language, there’s no denying it. But once I started to learn what all the weird syntax was for, it began to ruin Python for me.

Now I begrudge any time I have to go back to python. It feels like its beauty is only skin deep, but the ugly details are right there beneath the surface: prolific duck typing, exceptions as control flow, dynamic attributes. All these now make me uneasy, like I can’t be sure what my code will really do at runtime.

Rust is ugly but it’s telling you exactly what it will do.

mixmastamyk6• 8 months ago

Those complaints have very little to do with the syntax.

ActorNightly3• 8 months ago

Now I begrudge any time I have to go back to python. It feels like its beauty is only skin deep, but the ugly details are right there beneath the surface: prolific duck typing, exceptions as control flow, dynamic attributes. All these now make me uneasy, like I can’t be sure what my code will really do at runtime.

I feel like this sentiment is from people who haven't really took the time to fully see what the Python ecosystem is.

Any language can have shittly written code. However languages that by default disallow it means that you have to spend extra time prototyping things, whereas in Python, you can often make things work without much issue. Dynamic typing and attributes make the language very flexible and easily adaptable.

morshu90015• 8 months ago

JS ruined Python for me, cause it serves similar purposes but handles them better. Rust is a different thing, it ruined C and C++ for me.

nawgz• 8 months ago

Python users don’t even believe in enabling cursory type checking, their language design is surpassed even by JavaScript, should it really even be mentioned in a language comparison? It is a tool for ML, nothing else in that language is good or worthwhile

sorcercode• 8 months ago

Kotlin programmer here who is picking up Rust recently. you're right, it's no Kotlin when it comes to the elegance of APIs but it's also not too bad at all.

In fact there are some things about the syntax that are actually nice like range syntax, Unit type being (), match expressions, super explicit types, how mutability is represented etc.

I'd argue it's the most similar system level language to Kotlin I've encountered. I encourage you to power through that initial discomfort because in the process it does unlock a level of performance other languages dream of.

torben-friis• 8 months ago

Have you considered that part of it is not the language but the users?

I'm learning rust and the sample code I frequently find is... cryptically terse. But the (unidiomatic, amateurish) code I write ironically reads a lot better.

I think rust attracts a former c/c++ audience, which then bring the customs of that language here. Something as simple as your variable naming (character vs c, index vs i) can reduce issues already.

dimgl• 8 months ago

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.

I said this years ago and I was basically told "skill issue". It's unreadable. I shudder to think what it's like to maintain a Rust system at scale.

yoyohello135• 8 months ago

You get used to it. Like any language.

JuniperMesos5• 8 months ago

The syntax has relatively little to do with how easy or hard it is to maintain a rust system at scale. If you get something wrong the compiler will alert you, and most of the syntax is there for good reasons that anyone maintaining any kind of software system at scale needs to understand (and indeed the syntax helps you be clear about what you mean to the compiler, which facilitates helpful compiler error messages if you screw something up when modifying code).

dev_l1x_be• 8 months ago

I would argue that anything that is not Lisp has a complicated syntax.

The question is: is it worth it?

With Rust for the answer is yes. The reliability, speed, data-race free nature of the code I get from Rust absolutely justifies the syntax quirks (for me!).

bicarbonato• 8 months ago

What do people actually mean when they say "the syntax is janky"?

I often see comparisons to languages like Python and Kotlin, but both encode far less information on their syntax because they don't have the same features as Rust, so there's no way for them to express the same semantics as rust.

Sure, you can make Rust look simpler by removing information, but at that point you're not just changing syntax, you're changing the language's semantics.

Is there any language that preserves the same level of type information while using a less "janky" syntax?

NoGravitas2• 8 months ago

I don't know if there is, but there certainly needs to be. All of Rust's syntax seems to be needed to support its semantics, but it also undeniably crosses a threshold of "too much syntax". Though I do agree with the person above who said that every language that's not Lisp has too much syntax.

SquibblesRedux• 8 months ago

As an official greybeard who has written much in C, C++, Perl, Python, and now Rust, I can say Rust is a wonderful systems programming language. Nothing at all like Perl, and as others have mentioned, a great relief from C++ while providing all the power and low-level bits and bobs important for systems programming.

hedora2• 8 months ago

The sigils in Rust (and perl) are there to aid readability. After you use it a bit, you get used to ignoring them unless they look weird.

All the python programs I've had to maintain (I never choose python) have had major maintainability problems due to python's clean looking syntax. I can still look at crazy object oriented perl meta-programming stuff I wrote 20 years ago, and figure out what it's doing.

Golang takes another approach: They impoverished the language until it didn't need fancy syntax to be unambiguously readable. As a workaround, they heavily rely on codegen, so (for instance) Kubernetes is around 2 million lines of code. The lines are mostly readable (even the machine generated ones), but no human is going to be able to read them at the rate they churn.

Anyway, pick your poison, I guess, but there's a reason Rust attracts experienced systems programmers.

yoyohello135• 8 months ago

It seems to me that we ought to have a system-level language which builds upon the learnings of the past 20+ years

I mean, Rust does. I builds on 20+ years of compiler and type system advancements. Then Syntax is verbose if you include all then things you can possibly do. If you stick to the basics it's pretty similar to most other languages. Hell, I'd say a lot of syntax Rust is similar to type-hinted Python.

Having said that, comparing a GC'd dynamic language to a systems programming language just isn't a fair comparison. When you need to be concerned about memory allocation you just need more syntax.

creata4• 8 months ago

I think this is subjective, because I think Rust's syntax is (mostly) beautiful.

Given the constraint that they had to keep it familiar to C++ people, I'd say they did a wonderful job. It's like C++ meets OCaml.

Do you have any particular complaints about the syntax?

nixpulvis• 8 months ago

Aside from async/await which I agree is somewhat janky syntaxtically, I'm curious what you consider to be janky. I think Rust is overall pretty nice to read and write. Patterns show up where you want them, type inference is somewhat limited but still useful. Literals are readily available. UFCS is really elegant. I could go on.

Ironically, I find Python syntax frustrating. Imports and list comprehensions read half backwards, variable bindings escape scope, dunder functions, doc comments inside the function, etc.

e12e• 8 months ago

It seems to me that we ought to have a system-level language which builds upon the learnings of the past 20+ years.

Maybe Ada, D or Nim might qualify?

paulddraper• 8 months ago

Perl’s most notable syntax feature is sigils on all variables.

So it’s strange to hear a comparison. Maybe there’s something I’m missing.

It seems closer to C++ syntax than Perl.

JuniperMesos5• 8 months ago

I prefer Rust syntax to Python's purely on the grounds that Rust is a curly-brace language and Python is an indentation-sensitive language. I like it when the start and end of scopes in code are overtly marked with a non-whitespace character, it reduces the chances of bugs caused by getting confused about what lines of code are in what scope and makes it easier to use text editor tools to move around between scopes.

Beyond that issue, yeah most of Rust's syntactic noise comes from the fact that it is trying to represent genuinely complicated abstractions to support statically-checked memory safety. Any language with a garbage collector doesn't need a big chunk of Rust's syntax.

mixmastamyk6• 8 months ago

The rust syntax problem is not the braces but about all the #[()] || ::<<>> ‘stuff.

pessimizer• 8 months ago

I think the problem for people is the traditional problem that a lot of people have had with a lot of languages since C took off: it doesn't look like ALGOL, and doesn't have the semantics of ALGOL.

The reason python looks like procedural pseudocode is because it was designed to look like procedural pseudocode. Rust is not just a new skin over ALGOL with a few opinionated idioms, it's actually different - mostly to give hints of intention to the compiler, but I don't even think it started from the same place. It's more functional than anything imo, but without caring about purity or appearance, and that resulted in something that superficially looks sufficiently ALGOL-like to confuse people who are used to python or Kotlin.

I genuinely believe that languages ought to start with "newbie friendliness", and would love to hear challenges to that idea.

In conclusion, I think this is a red herring. Computer languages are hard. What you're actually looking for is something that is ALGOL-like for people who have already done the hard work of learning an ALGOL-like. That's not a newbie, though. Somebody who learned Rust first would make the same complaint about python.

cb321• 8 months ago

You might enjoy https://nim-lang.org/ which has a Python-like syntax with even more flexibility really (UFCS, command-like calls, `fooTemplate: stuff` like user-defined "statements", user-defined operators, term-rewriting macros and more. With ARC it's really just about as safe as Rust and most of the stdlib is fast by default. "High quality" is kind of subjective, but they are often very welcoming of PRs.

Anyway, to your point, I think a newbie could pick up the basics quickly and later learn more advanced things. In terms of speed, like 3 different times I've compared some Nim impl to a Rust impl and the Nim was faster (though "at the extreme" speed is always more a measure of how much optimization effort has been applied, esp. if the language supports inline assembly).

https://cython.org/ , which is a gradually typed variant of Python that compiles to C, is another decent possibility.

gaanbal2• 8 months ago

sounds like something that could be solved with more learning

I wrote python for 15 years

I don't want to write python anymore. mainly rust if I can

mrob• 8 months ago

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 has already given you permission to modify arbitrary files.

Muromec2• 8 months ago

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

SAI_Peregrinus3• 8 months ago

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

Yes, .deb violates the cryptographic doom principle[1] (if you have to perform any cryptographic operation before verifying the message authentication code (or signature) on a message you’ve received, it will somehow inevitably lead to doom).

Their signed package formats (there are two) add extra sections to the `ar` archive for the signature, so they have to parse the archive metadata & extract the contents before validating the signature. This gives attackers a window to try to exploit this parsing & extraction code. Moving this to Rust will make attacks harder, but the root cause is a file format violating the cryptographic doom principle.

[1] https://moxie.org/2011/12/13/the-cryptographic-doom-principl...

marcosdumay2• 8 months ago

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

Kwpolska• 8 months ago

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?

jwilk2• 8 months ago

Yes, you can do "apt-get install --dry-run ./nyancat_1.5.2-0.2_i386.deb" these days.

renewiltord3• 8 months ago

Preferably one is not able to pwn a package repository by uploading single malicious .deb file to it. e.g. people on Ubuntu frequently use PPAs (private package archives). You can run your own on Launchpad. If you upload malicious package, it should not destroy Launchpad.

ChrisArchitect• 8 months ago

Hard Rust requirements from May onward

https://news.ycombinator.com/item?id=45779860

scotty79• 8 months ago

Maybe there's a place for Future Debian distro that could be a place for phasing out old tech and introducing new features?

powerclue2• 8 months ago

Or maybe old devices and tech should expect a limited support window, or be expected to fork after some time?

ForHackernews5• 8 months ago

It sounds like all of the affected Debian ports are long since diverged from the official Debian releases anyway:

The sh4 port has never been officially supported, and none of the other ports have been supported since Debian 6.0.

Wikipedia tells me Debian 6 was released on 6 February 2011

yjftsjthsd-h6• 8 months ago

Some of us abandoned commercial OSs for Debian precisely to escape that mentality.

gpm6• 8 months ago

Isn't that literally what debian unstable is for?

leoh2• 8 months ago

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.

Havoc• 8 months ago

Think tech space isn’t for you if you hate learning new things.

stodor89• 8 months ago

It's sarcasm.

tucnak3• 8 months ago

Can you confirm these C++ fascists you speak of are in the room with you right now?

malcolmgreaves• 8 months ago

Nice /s

leoh2• 8 months ago

https://en.wikipedia.org/wiki/Poe%27s_law

gorgoiler3• 8 months ago

”[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.

rrmm3• 8 months ago

If this could be done it seems like the ideal compromise. Everyone gets what they want.

That said eventually more modern languages will be dependencies of the tools one way or another (and they should). So probably Debian as a whole should come to a consensus on how that should happen, so it can happen in some sort of standard and fair fashion.

GuB-42• 8 months ago

Shouldn't we wait until Rust gets full support in GCC? This should resolve the issue with ports without a working Rust compiler.

I don't have a problem with Rust, it is just a language, but it doesn't seem to play along well with the mostly C/C++ based UNIX ecosystem, particularly when it comes to dependencies and package management. C and C++ don't have one, and often rely on system-wide dynamic libraries, while Rust has cargo, which promotes large dependency graphs of small libraries, and static linking.

dathinab2• 8 months ago

Why is this still a discussion?

was no room for a change in plan

yes, pretty much

at least the questions about it breaking unofficial distros, mostly related to some long term discontinued architectures, should never affect how a Distro focused on current desktop and server usage develops.

if you have worries/problems outside of unsupported things breaking then it should be obvious that you can discuss them, that is what the mailing list is for, that is why you announce intend beforehand instead of putting things in the change log

complained that Klode's wording was unpleasant and that the approach was confrontational

its mostly just very direct communication, in a professional setting that is preferable IMHO, I have seen too much time wasted due to misunderstandings due to people not saying things directly out of fear to offend someone

through he still could have done better

also questioned the claim that Rust was necessary to achieve the stronger approach to unit testing that Klode mentioned:

given the focus on Sequoia in the mail, my interpretation was that this is less about writing unit tests, and more about using some AFIK very well tested dependencies, but even when it comes to writing code out of experience the ease with which you can write tests hugely affects how much it's done, rust makes it very easy and convenient to unit test everything all the time. That is if we speak about unit tests, other tests are still nice but not quite at the same level of convenience.

"currently has problems with rebuilding packages of types that systematically use static linking"

that seems like a _huge_ issue even outside of rust, no reliable Linux distros should have problems with reliable rebuilding things after security fixes, no matter how it's linked

if I where to guess there this might be related to how the lower levels of dependency management on Linux is quite a mess due to requirements from 90 no longer relevant today, but which some people still obsess over.

To elaborate (sorry for the wall of text) you can _roughly_ fit all dependencies of a application (app) into 3 categories:

1. programs the system provides (opt.) called by the app (e.g. over ipc, or spawning a sub process), communicating over well defined non language specific protocols. E.g. most cmd-line tools, or you systems file picker/explorer should be invoked like that (that it often isn't is a huge annoyance).

2. programs the system needs to provide, called using a programming language ABI (Application Binary Interface, i.e. mostly C ABI, can have platform dependent layout/encoding)

3. code reused to not rewrite everything all the time, e.g. hash maps, algorithms etc.

The messy part in Linux is that for historic reasons the later two parts where not treated differently even through they have _very_ different properties wrt. the software live cycle. For the last category they are for your code and specific use case only! The supported versions usable with your program are often far more limited: Breaking changes far more normal; LTO is often desirable or even needed; Other programs needing different incompatible versions is the norm; Even versions with security vulnerabilities can be fine _iff_ the vulnerabilities are on code paths not used by your application; etc. The fact that Linux has a long history of treating them the same is IMHO a huge fuck up.

It made sense in the 90th. It doesn't anymore since ~20 years.

It's just completely in conflict with how software development works in practice and this has put a huge amount of strain on OSS maintainers, due to stuff like distros shipping incompatible versions potentially by (even incorrectly) patching your code.... and end users blaming you for it.

IMHO Linux should have a way to handle such application specific dependencies in a all cases from scripting dependencies (e.g. python), over shared object to static linking (which doesn't need any special handling outside of the build tooling).

People have estimated the storage size difference of linking everything statically, and AFIK it's irrelevant in relation to availability and pricing on modern systems.

And the argument that you might want to use a patched version of a dependency "for security" reasons fails if we consider that this has lead to security incidents more then one time. Most software isn't developed to support this at all and bugs can be subtle and bad to a point of a RCE.

And yes there are special cases, and gray areas in between this categories.

E.g. dependencies in the 3rd category you want to be able to update independently, or dependencies from the 2nd which are often handled like the 3rd for various piratical reasons etc.

Anyway coming back the the article Rust can handle dynamic linking just fine, but only for C ABI as of now. And while rust might get some form of RustABI to make dynamic linking better it will _never_ handle it for arbitrary libraries, as that is neither desirable nor technical possible.

---

EDIT: Just for context, in case of C you also have to rebuild all header only libraries using pre-processor macros, not doing so is risky as you now mix different versions of the same software in one build. Same (somewhat) for C++ with anything using template libraries. The way you can speed it up is by caching intermediate build artifacts, that works for rust, too.

theoldgreybeard• 8 months ago

Rust developers are so dogmatic about their way being the best and only way that I just avoid it altogether. I've had people ask about Rust in issues/discussions in small hobby projects I released as open source - I just ban them immediately because there is no reasoning with them and they never give up. Open source terrorists.

tucnak3• 8 months ago

"Open source terrorism" is a hilarious designation for Rust-like traditions and customs. I wonder what other programming language/software communities may fall under this definition?

aeve890• 8 months ago

Username checks out.

Open source terrorists

Rust users and evangelism rubs me the wrong way. Yes it's safe, yes it's ergonomic but why the weird aura around the people that insist in "Rewrite it in Rust, Deus Vult"? It eludes me.

monegator• 8 months ago

Sometimes you do wonder if those 4chan memes about those who push rust rewrites are just memes or what..

steveklabnik25• 8 months ago

A maintainer of a project making a decision about their project is not someone pushing a re-write.

tyfon4• 8 months ago

I have a dual pentium pro 200 that runs gentoo and openbsd, but rust doesn't ship i586 binaries, only i686+. So I would need to compile on a separate computer to use any software that is using rust.

There is already an initrd package tool I can't use since it is rust based, but I don't use initrd on that machine so it is not a problem so far.

The computer runs modern linux just fine, I just wish the rust team would at least release an "i386" boostrap binary that actually works on all i386 like all of the other compilers.

"We don't care about retro computers" is not a good argument imho, especially when there is an easy fix. It was the same when the Xorg project patched out support for RAMDAC and obsoleted a bunch of drivers instead of fixing it easily. I had to fix the S3 driver myself to be able to use my S3 trio 64v+ with a new Xorg server.

/rant off

ForHackernews5• 8 months ago

I mean... Pentium Pro is 30 years old at this point. I don't think it's unreasonable that modern software isn't targeting those machines.

yjftsjthsd-h6• 8 months ago

So anyways, here's the netbsd docs for running the latest release on VAX: https://wiki.netbsd.org/ports/vax/

ShroudedNight3• 8 months ago

I thought the Pentium Pro _was_ a 686?

Wikipedia seems to correlate: https://en.wikipedia.org/wiki/Pentium_Pro, as do discussions on CMOV: https://stackoverflow.com/a/4429563

tyfon4• 8 months ago

Yes, sorry I remembered incorrectly. The rust compiler claims to be i686 and the CPU is i686 too, but the rust compiler is using Pentium 4 only instructions so it doesn't actually work for i686.

ondra• 8 months ago

Pentium Pro is the first i686 CPU, so you should be fine.

cogman107• 8 months ago

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 to migrate to a new CPU.

[1] https://www.amazon.com/KAMRUI-AK1PLUS-Processor-Computer-Eth...

tyfon4• 8 months ago

The system is actually running fine standalone since I have been able to avoid rust software.

As to why it should cater to it, it's more that there is no need to remove something that already works just to remove it.

It is possible to compile rustc on another system so it supports i586 and below. Just a small change in the command line options. And it doesn't degrade the newer systems.

I have plenty of faster machines, I just enjoy not throwing things away or making odd systems work. It's called having fun :)

grayhatter2• 8 months ago

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 feel bad for anyone that believes this.

I deeply believe that if you don't like what a maintainer of FOSS code has done, you should fork the project. Admittedly that's a very onerous suggestion. But more important than that, you should help people when you can. If you're deciding to drop support for a bunch of people because it makes your job easier or simpler, when you don't need to. You're the bad guy in the story. That's the way this announcement has been written, and most reasonable people object to that kind of behavior. Selfishness should feel a bit offensive to everyone.

dontlaugh5• 8 months ago

Surely retro hardware is fine with retro software.

gpm6• 8 months ago

"We don't care about retro computers" is not a good argument imho,

It absolutely is. If you want to do the work to support <open source software> for <purpose> you're welcome to do so, but you aren't entitled to have other people do so. There's some narrow exceptions like accessibility support, but retro computing ain't that.

MisterTea3• 8 months ago

""and not be held back by trying to shoehorn modern software on retro computing devices""

Nice. So discrimination of poor users who are running "retro" machines because that is the best they can afford or acquire.

I knew of at least two devs who are stuck with older 32 bit machines as that is what they can afford/obtain. I even offered to ship them a spare laptop with a newer CPU and they said thanks but import duties in their country would be unaffordable. Thankfully they are also tinkering with 9front which has little to no issues with portability and still supports 32 bit.

aaronblohowiak• 8 months ago

Rust works fine on 32 bit, (and 16 bit) that’s not what they mean…

quux2• 8 months ago

Rust even works on 8-bit via the LLVM-MOS backend for MOS 6502 :)

chc4• 8 months ago

No one is using an Alpha, Motorola 680x0, PA-RISC, or SuperH computer because that's the only thing they can afford. Rust supports 32bit x86.

quux2• 8 months ago

Looking at the list of affected architectures: Alpha (alpha), Motorola 680x0 (m68k), PA-RISC (hppa), and SuperH (sh4) I think these are much much more likely to be run by enthusiasts than someone needing an affordable computer.

cogman107• 8 months ago

The last 32bit laptop CPU was produced nearly 20 years ago.

Further, there are still several LTS linux distros (including the likes of Ubuntu and Debian) which don't have the rust requirement and won't until the next LTS. 24.04 is supported until 2029. Meaning you are talking about a 25 year old CPU at that point.

And even if you continue to need support. Debian based distros aren't the only ones on the plant. You can pick something else if it really matters.

yjftsjthsd-h6• 8 months ago

The last 32bit laptop CPU was produced nearly 20 years ago.

15 years max; I can easily find documentation of Intel shipping Atom chips without 64-bit support in 2010, though I haven't found a good citation for when exactly that ended.

tucnak3• 8 months ago

You seem to be involved with 9front.

Are you trying to suggest there is a nontrivial community of people who cannot afford modern 64-bit Linux platforms, and opt for 9front on some ancient 32-bit hardware instead? Where are they coming from? Don't get me wrong, I love the 9 as much as the next guy, but you seem to paint it as some kind of affordability frontier...

MisterTea3• 8 months ago

Where are they coming from?

One is in lives in Brazil and I think the other lives in the Middle East. They both have old second hand 32 bit laptops from the 00's.

but you seem to paint it as some kind of affordability frontier...

Yes because there are people still using old hardware because they have no choice. Also, whats the problem with supporting old architectures? Plan 9 solved the portability problem and a prominent user recently ported it to cheap MIPS routers so we can run Plan 9 on cheap second hand network hardware. We have the tool chain support so we use it.

And believe me, I understand a raspberry pi or whatever is much faster and uses less power but I would rather we reduce e-waste where possible. I still run old 32 bit systems because they work and I have them.

stingraycharles3• 8 months ago

Poor people aren’t running exotic hardware.

miladyincontrol2• 8 months ago

Agree, using these architectures isnt related to one's finances and unaffordability of hardware. Using obscure hardware like this for hobbyist reasons is a privilege, and one that rarely demands the latest upstream for everything at that.

crote9• 8 months ago

We're basically at a point where running those older machines is more expensive, once you factor in power use.

Even then, people using ancient fifth-hand machines are almost certainly still going to run x86 - which means they'll have no trouble running Rust as 32-bit x86 is a supported target. Their bigger issue is going to be plain old C apps dropping 32-bit support!

"Retro" in this case genuinely means "horribly outdated". We're talking about systems with CPUs in the hundreds of MHz with probably fewer than a gigabyte in memory. You might do some basic word processing using Windows 95, but running anything even remotely resembling a modern OS is completely impossible. And considering their age and rarity, I'd be very impressed if anyone in a poor country managed to get their hands on it.

ethin• 8 months ago

This is just one reason I'm not the biggest fan of Rust. The language is good (as well as what it solves), but this tendency to force it into everything (even where it would provide no benefit whatsoever) is just mind-boggling to me. And the Rust evangelists then wonder why there are so many anti-rust folk.

creatonez• 8 months ago

I have never seen a program segfault and crash more than apt. The status quo is extremely bad, and it desperately needs to be revamped in some way. Targeted rewrites in a memory safe & less mistake-prone language sounds like a great way to do that.

If you think this is a random decision caused by hype, cargo culting, or a maintainer's/canonical's mindless whims... please, have a tour through the apt codebase some day. It is a ticking time bomb, way more than you ever imagined such an important project would be.

sherr• 8 months ago

I've been using apt regularly on Debian for a long time and never seen it crash or segfault. Very strange that you do. All software has bugs of course, but apt is so heavily used that I expect it gets attention. It just works for me.

dontlaugh5• 8 months ago

I’ve seen in segfault once. I don’t know how common that is, but it would be nice to make that less likely.

pmarin• 8 months ago

20 years on Debian. Not a single crash with apt

roryirvine• 8 months ago

Almost 30 years for me, both on my personal machines and at work.

I went through a period about 25 years ago where apt crashed on my (rather janky) desktop almost every other run, and sometimes left my system in a state so inconsistent that I had to fall back on 'dpkg-reconfigure --force' and the like to fix it.

Turns out that it was due to a bad interaction between a failing stick of RAM and reiserfs' tail-packing feature, which was causing frequent silent corruption in /var/lib/dpkg/status and friends.

I don't think I've seen any similar issues since, across what must be many millions of apt runs I've been responsible for.

Perhaps gp is suffering from some similar underlying problem?

jzb• 8 months ago

I’m very very curious to know what it is you’re doing to experience this: I’ve used Debian and its derivatives for 25 years now. On desktops, laptops, and servers. x86, x86-64, and Arm 64. I have never had a segfault with APT. Not a single time. Problems with dependencies or such a few times, but I don’t recall APT ever crashing on me.

Please, share more details.

ekjhgkejhgk• 8 months ago

This thing gets everywhere.

phkahler• 8 months ago

I don't think programs should use mixed languages if its at all avoidable. Linux would be an exception because I think it can benefit from oxidation and it'll be decades before RedoxOS is ready.

renewiltord3• 8 months ago

Overall, I think Rust is probably too dangerous to introduce into core software. Every time there is a donation to the Rust Foundation, the Rust community is in an uproar that it is not a large enough fraction of gross revenue. Linux, apt, are all currently both free as in speech and free as in beer. If we have to start donating to the Rust Foundation a percentage of gross revenue for every tool that we use written in Rust, it will cost a lot. Probably much better to just not put Rust in the kernel or in apt.

It's a Trojan horse language. There are no demands from C users that anyone donate to C non-profits. Much better, safer language to use from an ecosystem perspective.

steveklabnik25• 8 months ago

Every time there is a donation to the Rust Foundation, the Rust community is in an uproar that it is not a large enough fraction of gross revenue.

Where are you seeing this happen? I'm curious because I never have, which means that I'm missing out on discussions somewhere.

renewiltord3• 8 months ago

Sure, it's on Reddit /r/rust. I'll provide links at the end, but it happens every time there is a donation.

> > Multi trillion dollar conglomerate invests a minuscule fraction of a fraction of their monthly revenue into the nonprofit foundation that maintains the tool that will save them billions
> 115 Billion / 365 days / 1440 minutes = ~ 220k
> So they make around 220k per minute, 350k in under 2 minutes. Still, any amount is better than nothing at all.
I genuinely hate the thought of "Better than nothing". We should be saying "go big or go home."

Pretty popular thread. Approximate 900 upvotes over those three comments.

That's like a millisecond of Google revenue.

and separately

I mean thats nice. But in all honesty, is 1 Million still a lot?

That's from a while ago so it's smaller. But you can tell the sentiment is rising because these expressions of "it's not enough" are becoming more popular. Just a matter of time before the community tries to strong-arm other orgs with boycotts and this and that. We've seen this before.

> Cool, but also depressing how relatively small these “huge” investments in core technologies actually are.
Yeah, seriously. This is comparatively like me leaving a penny in the “take a penny leave a penny” plate at the gas station.

and separately

Ah yes, the confidence displayed by allocating 0.0004% of your yearly revenue.
Satya alone earns that in a 40 hr work week.

It's a pretty old playbook to use free-software language to get one's technology entrenched, then there's murmurs about how not enough money is being sent back to the people making it, the organization then uses the community as the stalking horse to promote this theory, and then finally comes the Elastic License relicensing.

Elastic did it. MongoDB did it. Hashicorp did it. Redis did it. I get the idea, but we should pre-empt the trojan horse when we see it coming. I know I know. You can fork when it happens etc. but I'm not looking forward to switching my toolchain to "Patina" or whatever they call the fork.

And if you think I'm some guy with an axe to grind, I have receipts for Rustlang enthusiasm:

https://news.ycombinator.com/item?id=24127438

https://news.ycombinator.com/item?id=24328686

https://news.ycombinator.com/item?id=30756184

https://news.ycombinator.com/item?id=37573389

https://news.ycombinator.com/item?id=41639619

List of donation posts follows:

https://old.reddit.com/r/rust/comments/1noyqak/media_google_...

https://old.reddit.com/r/rust/comments/1ajm56w/google_donate...

https://old.reddit.com/r/rust/comments/1cnehqt/microsofts_1m...

leo_e• 8 months ago

As someone fighting the C++ toolchain daily, there is a painful irony in seeing APT—the tool supposed to solve dependency hell—creating its own dependency crisis.

I sympathize with the maintainers of retro hardware. But honestly? Holding back the security and maintainability of a modern OS base layer just so an AlphaStation from 1998 can boot feels backwards.

The transition pain is real, and Canonical handled the communication poorly. But the 'legacy C tax' is eternal. We have to move critical infrastructure off it eventually.

major505• 8 months ago

IS funny because thanks to efforts from companies like Valve, Linux seens to finally been receiving the recognition it deserves, Rust evangelists and weirdos who claim morality superiority to the rest of mortals, are going to put everything to loose, because of this obsession of rewriting tools that actually work for many years without bigger issues, just so they can say their language is superior.

IF there was some glaring problems with tools like sudo, sort, apt, and you have a superior version, sure, go ahead. But this is clearly not the case. Sometimes the rust version is just the same, or even inferior, but people are ready to plunge into destruction just to say their distro have the latest and greatest. Its just vanity.

Maybe the conspiracy theories that big tech finance the crazy incopetent people from in position of power in open source projects that they no longer can compete, in order to destroy them from the inside, is not that far fetched.

Surac• 8 months ago

my biggest problem with rust is. i can't read it. i never know what this symbol means. is it a keyword? a type, a variable, a constant or a macro? Sure loading it into a IDE with a language server may help understanding the code.

xiej• 8 months ago

There are only a few common keywords. Types are PascalCase. Variables are snake_case. constants are SCREAMING_CASE. macros have an exclamation point !

pornel4• 8 months ago

That's just your lack of familiarity with the foreign-to-you language (you may be unable to read Korean too, despite Korean being pretty readable).

Syntactically, Rust is pretty unambiguous, especially compared to C-style function and variable definitions. You get fn and let keywords, and definitions that are generally read left-to-right, instead of starting with an arbitrary identifier that may be a typedef, a preprocessor macro, or part of a type that is read in so-called "spiral" order (which isn't even a spiral, but more complex than than).

APT Rust requirement raises questions

Related Stories