Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hard Rust requirements from May onward

lists.debian.org

Post reply on HN
Print view View original

511–520 of 797 posts

Re: Hard Rust requirements from May onward

#511

Post by spacechild1 »

themafia wrote: post #496
lambdaone wrote: post #161

It's about time. Critical infrastructure still written in C - particularly code that parses data from untrusted sources - is technical debt that is only going to get worse over time. It's not as if Rust is that much more difficult to write than C. Rust is explicitly designed to be what you'd get if you were to re-create C knowing what we know now about language design and code safety. If 32-bit x86 support can be dro…

> It's not as if Rust is that much more difficult to write than C According to what? > Rust is explicitly designed There is no standard. It's accidentally designed. > knowing what we know now about language design and code safety. You've solved one class of bugs outside of "unsafe {}". The rest are still present.

> There is no standard. It's accidentally designed.

Are you really claiming that you can't design a language without an official standard? Not to mention that C itself has been designed long before its first ISO standard. Finally, the idea that a standard committee is a preconditionfor good language design is rather bold, I have to say. The phrase "design by committee" isn't typically used as a compliment...

> You've solved one class of bugs outside of "unsafe {}".

It's "only" the single most important class of bugs for system safety.

This kind of deflection and denialism isn't helping. And I'm saying this as someone who really likes C++.

Re: Hard Rust requirements from May onward

#512

Post by modulared »

egorfine wrote: post #342
ameliaquining wrote: post #197

Earlier quoted context omitted.

By that definition, all languages are "memory safe when used properly".

Well. Yes. Lol

That doesn't really make sense since memory safety is a property of a language. You can have code that is unsafe (read unsound), but that is a separate issue.

For a language to be memory safe it means there must be no way to mishandle a function or use some object wrong that would result in an "unsafe" operation (for Rust, that means undefined behavior).

That is to say the default is safe, and you are given an escape hatch. While in something like c/c++ the default is unsafe.

I'd also like to add that program correctness is another separate concept from language safety and code safety, since you could be using an unsafe language writing unsafe ub code and still have a correct binary.

Re: Hard Rust requirements from May onward

#513

Post by woodruffw »

csande17 wrote: post #404
woodruffw wrote: post #371

Earlier quoted context omitted.

“There’s a standard, but it’s performative” is a different argument than the top level one. But even if we accept that, it doesn’t seem like a good comparative argument: anybody who has written a nontrivial amount of C or C++ has dealt with compiler-defined behavior or compiler language extensions. These would suggest that the C and C++ standards are “performative” in the same sense, but repeated claims about the vir…

They have a document that they sometimes describe using the word "specification", but its README clarifies that it's not actually a specification: > The FLS is not intended to be used as the normative specification of the Rust language

To be clear, my argument doesn't hinge on whether FLS is a normative specification of Rust or not. The argument is that being "specified" is neither necessary nor sufficient for language maturity or quality.

Re: Hard Rust requirements from May onward

#514

Post by julian-klode »

Defletter wrote: post #184
lazyfanatic42 wrote: post #155

Earlier quoted context omitted.

The HN post doesn't seem very confrontational to me, but some folks see it so, weird.

The level of knee-jerk reaction to anything Rust into traditionally C projects borders on the pathological. That email is about as polite as it gets without being coddling.

Do keep in mind that a lot of the people involved in these sorts of things are neurodiverse in some ways, and may have significant trouble dealing with change.

As teh64 helpfully pointed out in https://news.ycombinator.com/item?id=45784445 some hours ago, 4ish years ago my position on this was a total 360 and I'd have had the same reaction to now-me's proposal.

Re: Hard Rust requirements from May onward

#515

Post by JuniperMesos »

4bpp wrote: post #192
tcfhgj wrote: post #10

Earlier quoted context omitted.

I haven't either, until I read comments on Rust in Linux on social media outside HN. Apparently, Rust is part of the "woke agenda"

That is a crude and politically inept way of putting it, but do you not think there is some grain of truth to it? If you opt into something with as high a barrier to entry and necessary time commitment as a programming language, you naturally also opt into the existing community around that language, because that will be where the potential contributors, people to help you solve issues, and people you have to talk to…

> As such, it is natural that bringing Rust into your project would over time result in it becoming more "woke", just like using Ruby would make it more likely that you attract Japanese contributors, or targeting Baikal CPUs would result in you getting pulled into the Russian orbit. The "woke" side themselves recognises this effect quite well, which is why they were so disturbed when Framework pushed Omarchy as a Linux distribution.

I think this analysis is basically accurate - there's no conspiracy or even deliberate agenda going on, it's just that the community surrounding Rust happens to have (at the moment, anyway) a relatively high number of American progressives, many of whom are openly interested in imposing American progressive ideological norms in spaces they care about (which is basically what we mean by the term "woke").

I think Rust is a good software tool and I would like to see it be as widely adopted and politically-neutral as C is, and used in all sorts of projects run by all sorts of people with all sorts of other agendas, political or otherwise. Consequently, I would like to see people and projects who do not agree with American progressive norms adopt the language and become active users of it, which will help dilute the amount of Rust users who are progressives. I myself am not an American political progressive and I have lots of issues with the stated politics of many well-known Rust developers.

Re: Hard Rust requirements from May onward

#516

Post by perlgeek »

jcranmer wrote: post #316
lambdaone wrote: post #161

It's about time. Critical infrastructure still written in C - particularly code that parses data from untrusted sources - is technical debt that is only going to get worse over time. It's not as if Rust is that much more difficult to write than C. Rust is explicitly designed to be what you'd get if you were to re-create C knowing what we know now about language design and code safety. If 32-bit x86 support can be dro…

Right now, there are approximately five languages that are presumed to be acceptable for core applications in the base system: C, C++, Shell (which probably means specifically bash), Perl, and Python. The most recent language to be added to that list is Python, about 20 years ago. That's not to say that everybody likes those languages (indeed, there's quite a few commenters here who I think would be surprised to lear…

> Shell (which probably means specifically bash)

Debian has ongoing efforts to make many shell scripts (like postinst Scripts in packages etc.) non-bash-specific.

A minimal Debian installation doesn't contain bash, but rather dash, which doesn't support bash extensions.

Re: Hard Rust requirements from May onward

#517

Post by tialaramex »

cwzwarich wrote: post #443
woodruffw wrote: post #371

Earlier quoted context omitted.

“There’s a standard, but it’s performative” is a different argument than the top level one. But even if we accept that, it doesn’t seem like a good comparative argument: anybody who has written a nontrivial amount of C or C++ has dealt with compiler-defined behavior or compiler language extensions. These would suggest that the C and C++ standards are “performative” in the same sense, but repeated claims about the vir…

The original purpose of the C standard was to solve the problems created by the diversity of increasingly divergent implementations of C. They studied existing behavior across systems, proposed new language constructs, and it was generally a success (look at the proliferation of C in the 90s across many different systems and architectures). The actual informal semantics in the standard and its successors is written i…

Well, the memory ordering model was developed for C++ and is used in C and Rust. But e.g. C++ does not have a pointer provenance model, which is arguably almost as important in this context. It turns out one of the things we really care about with multi-processing, and thus memory models is linked list hacks, and those only work if you have provenance rules, which uh, C++ just has a shrug emoji where the provenance rules would go so that's not great. C has an ISO document, although it's not part of the ISO C standard it's just another document so far, but Rust has specified provenance.

Also, the C++ ordering model is defective in the sense that while it offers the orders we actually use it also offers an order nobody knows how to implement, so it's basically just wishful thinking. For years now the C++ standard has labelled this order "temporarily discouraged" as experts tried to repair the definition and C++ 26 is slated to just deprecate it instead. Rust doesn't copy that defect.

Re: Hard Rust requirements from May onward

#518

Post by pizlonator »

julian-klode wrote: post #465
pizlonator wrote: post #226

They’d be better off just compiling the package manager with Fil-C No changes required. Bringing up the fil-C toolchain on weird ports is probably less work than bringing up the Rust toolchain

Fil-C is amazing but is much more problematic than Rust at this point since it only supports amd64 at this time and is maintained by a single genius. It also doesn't help you to attract new contributors. With the changes we made over in Ubuntu to switch to rust-coreutils and sudo-rs, we have seen an incredible uptake in community contributions amongst other things, and it's very interesting to me to try to push APT m…

> since it only supports amd64

Sorry to double-reply, but this is actually a super important point in favor of Fil-C.

If you adopted Fil-C for apt, then you could adopt it optionally - only on ports that had a Fil-C compiler. Your apt code would work just as well in Fil-C as in Yolo-C. It's not hard to do that. I think about half the software I "ported" to Fil-C worked out of the box, and in those cases where I had to make changes, they're the sort of changes you could upstream and maintain the software for both Fil-C and Yolo-C.

So, with Fil-C, there would be no need to ruffle feathers by telling port maintainers to support a new toolchain!

Re: Hard Rust requirements from May onward

#519

Post by rcxdude »

julian-klode wrote: post #481
rcxdude wrote: post #447

Earlier quoted context omitted.

A substantial fraction of apt is written in perl. It's actually still pretty core to debian, even if applications are using it less.

There is no Perl code in APT itself, nor in dpkg on the installing side; Perl is used by dpkg-dev, i.e. when building packages.

Ah, my apologies. I must admit I am not entirely clear on where the boundaries are between the different tools and other elements of the debian packaging process.

Re: Hard Rust requirements from May onward

#520

Post by julian-klode »

pizlonator wrote: post #508
julian-klode wrote: post #465

Earlier quoted context omitted.

Fil-C is amazing but is much more problematic than Rust at this point since it only supports amd64 at this time and is maintained by a single genius. It also doesn't help you to attract new contributors. With the changes we made over in Ubuntu to switch to rust-coreutils and sudo-rs, we have seen an incredible uptake in community contributions amongst other things, and it's very interesting to me to try to push APT m…

> since it only supports amd64 at this time and is maintained by a single genius. That's easily fixable. > It also doesn't help you to attract new contributors. I don't understand this point.

> > since it only supports amd64 at this time and is maintained by a single genius. > That's easily fixable.

as easily as fixing Rust to work on the remaining 4 architectures?

> > It also doesn't help you to attract new contributors. > I don't understand this point.

C++ doesn't attract a lot of developers, Rust attracts many more. I want more community, particularly _young_ community. I don't wanna work on this alone all the time :D

Post reply on HN