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

551–560 of 797 posts

Re: Hard Rust requirements from May onward

#551

Post by [deleted] »

coderjames wrote: post #368
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…

> In particular, our code to parse .deb, .ar, .tar, and the HTTP signature verification code would strongly benefit from memory safe languages > 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. But hasn't all that foundational code been stable and wrung out already over the last 30+ years? The .tar and…

[deleted]

Re: Hard Rust requirements from May onward

#552

Post by AlotOfReading »

tialaramex wrote: post #527
steveklabnik wrote: post #510

Earlier quoted context omitted.

With crypto, you really want to just write the assembly, due to timing issues that higher level languages simply cannot guarantee.

I would like a special purpose language to exist precisely for writing crytographic code where you always want the constant time algorithm. In this niche language "We found a 20% speed-up for Blemvich-Smith, oops, it actually isn't constant time on the Arrow Lake micro-code version 18 through 46" wouldn't even get into a nightly let alone be released for use. It seems that for reasons I don't understand this idea isn…

There's been plenty, like RobustIsoCrypt or FaCT:

https://github.com/PLSysSec/FaCT

They struggle to guarantee constant time for subroutines within a non-constant time application, which is how most people want to use cryptography.

Re: Hard Rust requirements from May onward

#553

Post by the__alchemist »

woodruffw wrote: post #544
lpribis wrote: post #394

Earlier quoted context omitted.

The unfortunate reality is that you must write almost all of your drivers from scratch if you want to rust in embedded. There is no OEM driver support, and as you said the open source drivers are all crap and written for arduino-level hobby projects. Lack of drivers is prohibitive if your are a small/medium team or are using a lot of complicated peripherals or SoC. Compare to C where any MCU or embedded SoC or modera…

I'm not following: Rust excels at C interop, so why wouldn't you use the OEM drivers/SDK and bind them through Rust for your own code? That's what I've always done when I need to interact with a C library in Rust.

Hmm. You raise a good point. I've been doing a bit of C FFI on std-rust applications, but hadn't thought to apply this to embedded much. I have wrapped CMSIS-DSP (ARM-official DSP toolkit; filters etc) with Rust embedded, and it works out well! Increases compile times, but worth it. Perhaps we should apply this approach more broadly.

One problem: It's tedious going from the pointer-level API bindgen gives you to a high-level rust API that has references, arrays etc. In that you have to do some boilerplate for each bit of functionality you want. Not a big deal for a specific application, but not ideal if making a general library. And C libs tend to be sloppy with integer types, which works, but is not really idiomatic for rust. Maybe that could be automated with codegen or proc macros?

I believe the ESP-IDF rust lib is mostly FFI (?); maybe that's a good example. We've been re-inventing the wheel re STM-32 and Nordic support.

Re: Hard Rust requirements from May onward

#554

Post by chrsw »

krautburglar wrote: post #81

I think polyglot causes more problems than it solves. It is gross how many different toolchains and package managers it now takes to build a distro. One person wants python, another wants node, another wants go, and now this. with node we traded buffer overflows for supply chain attacks. If they don’t want C, it would be better to start fresh. Robert Morris re-wrote enough of Linux in golang to be usable, and the ove…

Linux gave up the fight against complexity a couple of decades ago.

Re: Hard Rust requirements from May onward

#555

Post by yolovoe »

Surac wrote: post #94

I think this is the wrong way to promote rust. For me rust is just a hype. I know nobody that programms or even thinks about rust. I’m from the embedded world an there c is still king. I understand that some will see rust as a good alternative, but as long as the real money is made in c it is not ready

AWS is very heavy on Rust internally for core services.

EC2 (lots of embedded work on servers), IAM, DynamoDB, and parts of S3 all heavily use Rust for quite a few years now already.

We can move really fast with Rust as compared to C, while still saving loads of compute and memory compared to other languages. The biggest issue we've hit is the binary size which matters in embedded world.

Linux has added support for Rust now. I don't think Rust's future supremacy over C is doubtful at this point.

AWS might honestly be the biggest on Rust out of all the FAANGs based on what I've heard too. We employ loads of Rust core developers (incl Niko, who is a Sr PE here) and have great internal Rust support at this point :). People still use the JVM where performance doesn't matter, but anywhere where performance matters,I don't see anyone being okay-ed to use C over Rust internally at this point.

Re: Hard Rust requirements from May onward

#556

Post by jeffparsons »

richard_todd wrote: post #550

I'm not sure if it's an insecurity thing or an immaturity thing, but when all these stories pop up, I always wonder why rust enthusiasts don't just prove their point by making their own "modern" and non-"retro" tech. If you can make something better, just do it already, and people will switch to it when they see the benefits. This parasitic "you must accept rust in your long-standing project" model is so off-putting,…

This email is from a Debian maintainer, about Debian introducing a new hard dependency on Rust. It's not some random Rust advocate telling Debian folks that they should use Rust against their will.

Yes there are absolutely some obnoxious "you should rewrite this in Rust" folks out there, but this is not a case of that.

Re: Hard Rust requirements from May onward

#557

Post by sn9 »

steveklabnik wrote: post #510
kelnos wrote: post #502

Earlier quoted context omitted.

> Formally verified _always_ beats anything else. Formally verified in an obscure language where it's difficult to find maintainers does not beat something written in a more "popular" language, even if it hasn't been formally verified (yet?). And these days I would (unfortunately) consider assembly as an "obscure language". (At any rate, I assume Rust versions of cryptographic primitives will still have some inline a…

With crypto, you really want to just write the assembly, due to timing issues that higher level languages simply cannot guarantee.

You can't avoid those with NASA Power of 10 sorts of restrictions?

Re: Hard Rust requirements from May onward

#558

Post by pizlonator »

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

Earlier quoted context omitted.

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

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

Easier, because you won't have to port Fil-C to all of the architectures in order to use it on amd64.

> C++ doesn't attract a lot of developers, Rust attracts many more.

C is #2 on TIOBE.

C++ is #3 on TIOBE.

Rust is #16 on TIOBE.

So I don't know what you're talking about

Re: Hard Rust requirements from May onward

#559

Post by kelnos »

uecker wrote: post #289
mirashii wrote: post #18

Earlier quoted context omitted.

This whole it used to be different thing is looking back with rose tinted glasses. It’s always been the case that project maintainers were able to make choices that the community didn’t necessarily agree with, corporate backed contributors or not, and it’s still a possibility to fork and try to prove out that the other stance is better. Nobody is being forced out of the community, you can fork and not adopt the chang…

The point of freedom in software is certainly that I can create my own fork. And individual projects a maintainer can certainly do what he wants. But it is still worrying if in community projects such as Debian when decisions that come with a cost to some part of the community are pushed through without full consensus. It would be certainly not the first time. systemd was similar and for similar reasons (commercial i…

> pushed through without full consensus

Requiring full consensus for decisions is a great way to make no decisions.

Re: Hard Rust requirements from May onward

#560

Post by doubletwoyou »

krautburglar wrote: post #81

I think polyglot causes more problems than it solves. It is gross how many different toolchains and package managers it now takes to build a distro. One person wants python, another wants node, another wants go, and now this. with node we traded buffer overflows for supply chain attacks. If they don’t want C, it would be better to start fresh. Robert Morris re-wrote enough of Linux in golang to be usable, and the ove…

Unfortunately, the world is a complicated place and each one of these languages have their own benefits and tradeoffs that suit themselves to one particular language or another (ask an ML scientist to switch to raw C), leading to all of these languages having a valid place in the pantheon of softwares (except maybe for js). Since debian is a pragmatic OS, it needs to adapt to solve for the real problem of being generally usable, and thus supporting all of these languages. Rewriting Everything in one language would be a massive pain and likely a massive waste of time and supporting an OS with less reputation and stable footing like Redox would almost if not more counterproductive as rewriting everything in debian from scratch (it’s a bit hyperbolic to state the goal is to Rewrite Everything in rust), so supporting the gradual replacement of some mission critical components like the apt parser or whatever they’re talking about is likely more realistic. Although an OS definitely shouldn’t “move fast and break things” (especially not one like Debian) I don’t think it’s too ridiculous to drop support for architectures that can’t support a language that was released almost a decade ago. Having a proven language (I think it’s safe to say rust is proven by now, right?) that is much less prone to self-combustion on modification than C, yet maintains a directly compiled nature as well as being to interface relatively well with normal C libraries in some standard applications is a pretty good value-deal proposition in my opinion.
Post reply on HN