APT Rust requirement raises questions • Hacker News Board

Re: APT Rust requirement raises questions

#121

Post by steveklabnik » Tue, Nov 25, 2025, 3:52 PM UTC

handwarmers wrote: post #79

steveklabnik wrote: post #41

Earlier quoted context omitted.

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

Are the many who disagree that it is unreadable more than the people who agree? I have been involved with the language for a while now, and while I appreciate what you and many others have done for it, the sense that the group is immune to feedback just becomes too palpable too often. That, and the really aggressive PR. Rust is trying to solve a really important problem, and so far it might well be one of the best so…

> Are the many who disagree that it is unreadable more than the people who agree?

I have no way to properly evaluate that statement. My gut says no, because I see people complain about other things far more often, but I do think it's unknowable.

I'm not involved with Rust any more, and I also agree with you that sometimes Rust leadership can be insular and opaque. But the parent isn't really feedback. It's just a complaint. There's nothing actionable to do here. In fact, when I read the parent's post, I said "hm, I'm not that familiar with Kotlin actually, maybe I'll go check it out," loaded up https://kotlinlang.org/docs/basic-syntax.html, and frankly, it looks a lot like Rust.

But even beyond that: it's not reasonably possible to change a language's entire syntax ten years post 1.0. Sure, you can make tweaks, but turning Rust into Python simply is not going to happen. It would be irresponsible.

Re: APT Rust requirement raises questions

#122

Post by sorcercode » Tue, Nov 25, 2025, 3:52 PM UTC

dv35z wrote: post #31

Every time I consider learning Rust, I am thrown back by how... "janky" the syntax is. It seems to me that we ought to have a system-level language which builds upon the learnings of the past 20+ years. Can someone help me understand this? Why are we pushing forward with a language that has a Perl-esque unreadability...? Comparison: I often program in Python (and teach it) - and while it has its own syntax warts & fr…

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.

Re: APT Rust requirement raises questions

#123

Post by superxpro12 » Tue, Nov 25, 2025, 3:52 PM UTC

enriquto wrote: post #96

dv35z wrote: post #31

Every time I consider learning Rust, I am thrown back by how... "janky" the syntax is. It seems to me that we ought to have a system-level language which builds upon the learnings of the past 20+ years. Can someone help me understand this? Why are we pushing forward with a language that has a Perl-esque unreadability...? Comparison: I often program in Python (and teach it) - and while it has its own syntax warts & fr…

> I am thrown back by how... "janky" the syntax is. Well if you come from C++ it's a breath of fresh air! Rust is like a "cleaned-up" C++, that does not carry the historical baggage forced by backwards compatibility. It is well-thought out from the start. The syntax may appear a bit too synthetic; but that's just the first day of use. If you use it for a few days, you'll soon find that it's a great, beautiful languag…

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.

Re: APT Rust requirement raises questions

#124

Post by frizlab » Tue, Nov 25, 2025, 3:53 PM UTC

ModernMech wrote: post #119

frizlab wrote: post #105

Earlier quoted context omitted.

On the contrary, Swift is very relevant on this subject. It has high feature parity with rust, with a much readable syntax.

But Swift is not "Kotlin for Rust" though, I can't see the connection at all. "Kotlin for Rust" would be a language that keeps you in the Rust ecosystem.

Ah yeah ok, makes sense in that way

Re: APT Rust requirement raises questions

#125

Post by tsimionescu » Tue, Nov 25, 2025, 3:53 PM UTC

sidewndr46 wrote: post #8

petcat wrote: post #3

Interesting how instead of embracing Rust as a required toolchain for APT, the conversation quickly devolved into "why don't we just build a tool that can translate memory-safe Rust code into memory-unsafe C code? Then we don't have to do anything." This feels like swimming upstream just for spite.

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.

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.

Re: APT Rust requirement raises questions

#126

Post by bgwalter » Tue, Nov 25, 2025, 3:53 PM UTC

tcfhgj wrote: post #90

simonw wrote: post #71

Earlier quoted context omitted.

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

now show me an alternative syntax encoding the same information

...

Re: APT Rust requirement raises questions

#127

Post by kataklasm » Tue, Nov 25, 2025, 3:53 PM UTC

tcfhgj wrote: post #113

enriquto wrote: post #96

Earlier quoted context omitted.

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

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.

But that is the kind of convenience and ease of use that brings us another npm malware incident every other month at this point.

Re: APT Rust requirement raises questions

#128

Post by echelon » Tue, Nov 25, 2025, 3:54 PM UTC

movpasd wrote: post #84

dv35z wrote: post #31

Every time I consider learning Rust, I am thrown back by how... "janky" the syntax is. It seems to me that we ought to have a system-level language which builds upon the learnings of the past 20+ years. Can someone help me understand this? Why are we pushing forward with a language that has a Perl-esque unreadability...? Comparison: I often program in Python (and teach it) - and while it has its own syntax warts & fr…

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

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.

Re: APT Rust requirement raises questions

#129

Post by torben-friis » Tue, Nov 25, 2025, 3:54 PM UTC

dv35z wrote: post #31

Every time I consider learning Rust, I am thrown back by how... "janky" the syntax is. It seems to me that we ought to have a system-level language which builds upon the learnings of the past 20+ years. Can someone help me understand this? Why are we pushing forward with a language that has a Perl-esque unreadability...? Comparison: I often program in Python (and teach it) - and while it has its own syntax warts & fr…

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.

Re: APT Rust requirement raises questions

#130

Post by pbohun » Tue, Nov 25, 2025, 3:54 PM UTC

petcat wrote: post #3

Interesting how instead of embracing Rust as a required toolchain for APT, the conversation quickly devolved into "why don't we just build a tool that can translate memory-safe Rust code into memory-unsafe C code? Then we don't have to do anything." This feels like swimming upstream just for spite.

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.