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

661–670 of 797 posts

Re: Hard Rust requirements from May onward

#661

Post by physicsguy »

jbv027 wrote: post #397
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 is not only about memory safety. C community is aging fast and young developers choose different languages. We started to rewrite all C and C++ code in my team because it is really hard to find people willing to maintain it. From my experience typical C or C++ programer is around 40 and not willing to switch jobs.

My experience in working in C++ was that the salary wasn’t as good as what I could get elsewhere. That was a big part of why I left, I didn’t hate the job.

Re: Hard Rust requirements from May onward

#662

Post by iknowstuff »

DaSHacka wrote: post #650
iknowstuff wrote: post #582

Earlier quoted context omitted.

Spend more effort on looking before posting then!

I'm not gonna waste effort on a fool's errand. So far, neither claim has been backed up whatsoever. It's obviously more likely it's just fans of the language with a knee-jerk reaction of "ackshully you're totally definetely wrong, but uh... don't ask me how, you just are" than legitimate talking points.

stay ignant then, keep making stupid claims and asking people to correct them lol

Re: Hard Rust requirements from May onward

#663

Post by paulf38 »

zenxyzzy wrote: post #501

Rust evangelists are tiresome. It's not gonna fix the tech debt problem, No matter how much rust crack you smoke. Disciplined use of c, with modern tools like valgrind, will give you safe code without having to lobotomize yourself into fighting the borrow checker for everything, even manifestly simple code.

It would be nice (speaking as a Valgrind developer) if Valgrind could guarantee safe code. Unfortunately it doesn’t. Firstly, it does not detect all kinds of errors (and indeed no tool does). Secondly, it is unlikely that the test coverage is perfect.

Delusional overconfidence that developer “skill” is all that is needed to overcome the many shortcomings of C is not a solution to the problem of guaranteeing security and safety.

Re: Hard Rust requirements from May onward

#664

Post by solidsnack9000 »

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…

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

What are some concrete cases you can point to where a decision was made with full consensus? Literally everyone agreed? All the users?

I'm not sure many projects have ever been run that way. I'm sure we've all heard of the Benevolent Dictator for Life (BDfL). I'm sure Linus has made an executive decision once in a while.

Re: Hard Rust requirements from May onward

#665

Post by physicsguy »

tempest_ wrote: post #206
astockwell wrote: post #194

Earlier quoted context omitted.

Would this logically extend to also include C-reliant languages like Python and Ruby (the latter being mostly a grammar underpinned by C) as technical debt also?

Yes, which is why in 2025 it is a good idea to use Rust with python bindings for your performance sensitive code. A lot of the C code used in python is calling out to old, battle tested and niche libraries so it is unlikely that someone is going to replace those any time soon but Rust is definitely increasing as time goes on for greenfield work.

Most Python libraries that relies on C are numerical stuff.

From experience with this type of code you typically end up with a load of functions that take in a numpy array and its length/dimensions to a C function that works on that array in place or an output array that was also supplied. In terms of getting this wrong, it’s usually a crash caused by out of bounds memory access which would still be a runtime crash in Rust. So I’m not sure there’s a massive benefit for these types of code other than the fun of learning Rust. Other than that, you’re typically writing C/C++ to interface with C and Fortran libraries that are really battle tested, and for which it will take decades for Rust to have equivalents. So moving to Rust will just cause you to have lots of unsafe statements - not a bad thing necessarily if you are doing a lot of work at the C level in existing code but less of a benefit if you are doing a straight wrap of a library.

On the flip side, things on the web side of Python like uWSGI which is written in C are important for the security aspect but they’re a very small part of the Python ecosystem.

Re: Hard Rust requirements from May onward

#666

Post by physicsguy »

uecker wrote: post #314
illuminator83 wrote: post #303

Earlier quoted context omitted.

I think it's mostly the fact that C dependencies are much rarer and much harder to add and maintain. The average C project has at most a handful of other C dependencies. The average Rust, Go or NodeJS project? A couple hundred. Ironically, because dependency management is so easy in modern languages, people started adding a lot of dependencies everywhere. Need a leftpad? Just add one line in some yaml file or an "Alt…

I never found it hard to add a C library to my projects using pkg-config. And yes, when the package came from Debian I have some trust that it is not a huge supply chain risk. I think the problem started with the idea over language-level managers that are just github collections instead of curated distribution-level package managers. So my response "C has no good package manager" is: It should not have a packager man…

pkg-config isn’t the hard bit though, is it?

Usually the hard bit with C libraries is having dependencies with dependencies all of which use their own complex build systems, a mix of Make, CMake, Autotools, Ninja, etc.

Then within that for e.g. a mix of using normal standard names for build parameters and not e.g. PROJECTNAME_COMPILER instead of CMAKE_C_COMPILER

Re: Hard Rust requirements from May onward

#667

Post by jurschreuder »

dataflow wrote: post #648
embedding-shape wrote: post #386

Earlier quoted context omitted.

> Interestingly, I wonder if the debates over the addition of C++, Python, and Perl to the base system language set were this acrimonious. I think any projects that are run by people that see themselves as "X-people" (like Python-people, Perl-people) always have a bit "ick" reaction to new languages being added to projects they might see as part of a language's community. So say you're a C++ developer, contributed to…

> So say you're a C++ developer, contributed to APT over the years, see all of it linked to the C++ community which you are part of too, and someone wants to start migrating parts of it to Rust/$NewLang. I think it might sometimes affect more for these people than just the code, might even be "attacking" (strong word perhaps) their sense of identity, for better or worse. How is language relevant here? If someone just…

This is really a Rust specific thing, since so many C++ projects were 1-on-1 translated to Rust only changing the licence.

Rust has been the tool of choice for stealing GPL3 open source projects where some people have spent all their free time on at some point in their life.

Re: Hard Rust requirements from May onward

#668

Post by blub »

julian-klode wrote: post #497
blub wrote: post #393

Earlier quoted context omitted.

Recently the rust coreutils had a bug and this essentially disabled auto-updates on Ubuntu. :) Seeing this tone-deaf message from an Ubuntu employee would be funny if I didn’t actually use Ubuntu. Looks like I have to correct that…

Isn't it also funny that all of these things are done by the same person? In all seriousness though, let me assure you that I plan to take a very considerate approach to Rust in APT. A significant benefit of doing Rust in APT rather than rewriting APT from scratch in Rust means that we can avoid redoing all our past mistakes because we can look at our own code and translate it directly.

Seems reasonable. I wish you would have written that in your original message. Good luck…

Re: Hard Rust requirements from May onward

#669

Post by solidsnack9000 »

uecker wrote: post #297
crote wrote: post #61

Earlier quoted context omitted.

> I think the spin that Rust is necessarily the way forward is what is wrong. Well, what's the alternative? The memory safety problem is real, I don't think there is any doubt about that. C/C++ is a dead end: the community has thoroughly rejected technical solutions like the Circle compiler, and "profiles" are nothing more than a mirage. They are yet again trying to make a magical compiler which rejects all the bad c…

While memory safety is important, I do not believe it is now suddenly so important that it needs now needs to be solved quickly at all cost. There are far more pressing issues. I also do not think at all that C/C++ are dead end. In fact, I think it would be far more cost effective to continue to improve safety of C and C++ code via gradual improvement than adding another language into the mix. The reason is that comp…

What are realistic options for "gradual improvement" of memory safety in C and C++?

My first thought is that it is kind of like talking about gradually improving manual memory allocation in Java. C and C++ are fundamentally memory unsafe; it's part of their design, to offer complete control over memory in a straightforward, direct way.

Re: Hard Rust requirements from May onward

#670

Post by blub »

jbv027 wrote: post #397
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 is not only about memory safety. C community is aging fast and young developers choose different languages. We started to rewrite all C and C++ code in my team because it is really hard to find people willing to maintain it. From my experience typical C or C++ programer is around 40 and not willing to switch jobs.

Is the pay good at your job? Rust jobs are few and far between, so I think Rustafarians are willing to take lower pay to work in their dream language. Companies will of course abuse this.
Post reply on HN