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

601–610 of 797 posts

Re: Hard Rust requirements from May onward

#601

Post by stefan_ »

cozzyd wrote: post #596
mike_d wrote: post #570

Earlier quoted context omitted.

> there are approximately five languages that are presumed to be acceptable for core applications in the base system: [...] Python I don't know if you've tried to get someone else's Python running recently, but it has devolved into a disaster effectively requiring containers to accurately replicate the exact environment it was written in. Core system applications should be binaries that run with absolutely minimal de…

this is not normally a problem for a distro where the environment is well known

It is such a non problem it forced them to hack a „fuck you this Python is owned by the distribution not you“ message into pip requiring you to agree to „breaking your system“ to use it.

Of all the languages, python in the base system has been an unmitigated garbage fire.

Re: Hard Rust requirements from May onward

#602

Post by cozzyd »

capyba wrote: post #478
kstrauser wrote: post #225

Earlier quoted context omitted.

I find Rust much easier to write than C. Its types let me be reasonably sure I’ve written appropriate code before I even get to the point of running tests, and I don’t have to memorize the flow of the whole program to have that assurance. For instance, struct Feet(i32); struct Meters(i32); fn hover(altitude: Meters) { println!("At {} meters", altitude.0); } fn main() { let altitude1 = Meters(16); hover(altitude1); le…

All you're doing is passing an argument of the incorrect type to your function. The exact same thing fails to compile in C: ``` #include typedef struct { int value; } Feet; typedef struct { int value; } Meters; void hover(Meters altitude) { printf("At %i meters\n", altitude.value); } int main() { Meters altitude1 = {.value = 16}; hover(altitude1); Feet altitude2 = {.value = 16}; hover(altitude2); } ``` ``` error: pas…

right and in C++ you have amazing zero-overhead units libraries

Re: Hard Rust requirements from May onward

#603

Post by zahlman »

mike_d wrote: post #570
jcranmer wrote: post #316

Earlier quoted context omitted.

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…

> there are approximately five languages that are presumed to be acceptable for core applications in the base system: [...] Python I don't know if you've tried to get someone else's Python running recently, but it has devolved into a disaster effectively requiring containers to accurately replicate the exact environment it was written in. Core system applications should be binaries that run with absolutely minimal de…

> I don't know if you've tried to get someone else's Python running recently, but it has devolved into a disaster effectively requiring containers to accurately replicate the exact environment it was written in.

Please show me a project where you believe you "effectively require containers" just to run the code, and I will do my best to refute that.

> since we no longer live in a storage constrained world.

I think you do care about the storage use if you're complaining about containers.

And I definitely care, on principle. It adds up.

For reasons I can only assume have to do with poorly configured CI, pip gets downloaded billions of times annually (https://pypistats.org/packages/pip), and I assume those files get unpacked and copied all the time since there would be no good reason to use uv to install pip. That's dozens of petabytes of disk I/O.

Re: Hard Rust requirements from May onward

#604

Post by pornel »

richard_todd wrote: post #571
jeffparsons wrote: post #556

Earlier quoted context omitted.

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.

There are like 1000 Debian maintainers, right? This person doesn't speak for the project as a whole, and as far as I can tell he is telling Debian folks they will be accepting rust whether they want it or not, and whether their preferred architecture is supported or not. Maybe there was some organizational vote on this, but if so it isn't referenced in the thread. It says "I plan", not "Debian decided to". And regard…

You seem to think of "rust enthusiasts" as some organized group with a goal of writing Rust for the sake of it. Rust is long past such extremely early adopter phase.

What you're seeing now is developers who are interested in writing a better version of whatever they're already working on, and they're choosing Rust to do it. It's not a group "Rust enthusiasts" ninjas infiltrating projects. It's more and more developers everywhere adopting Rust as a tool to get their job done, not to play language wars.

Re: Hard Rust requirements from May onward

#605

Post by cozzyd »

kstrauser wrote: post #232
OptionOfT wrote: post #230

Earlier quoted context omitted.

It would've saved the Mars Climate Orbiter: https://en.wikipedia.org/wiki/Mars_Climate_Orbiter > An investigation attributed the failure to a measurement mismatch between two measurement systems: SI units (metric) by NASA and US customary units by spacecraft builder Lockheed Martin.[3]

That was exactly what I was thinking of when I wrote that. But also think of how many libc functions take multiple ints or multiple chars in various orders. You can get carried away with typing, i.e. by having a separate type for everything*. Still, imagine you’re writing, say, a hypothetical IDE device driver and had separate types for BlockNumber and ByteInBlock so that it’s impossible to transpose read(byte_offset…

A bit clunky but more foolproof is something like:

ide_read ( &(struct ide_loc) { .byte_offset = 10, .block = 20 } )

Re: Hard Rust requirements from May onward

#606

Post by zahlman »

stefan_ wrote: post #601
cozzyd wrote: post #596

Earlier quoted context omitted.

this is not normally a problem for a distro where the environment is well known

It is such a non problem it forced them to hack a „fuck you this Python is owned by the distribution not you“ message into pip requiring you to agree to „breaking your system“ to use it. Of all the languages, python in the base system has been an unmitigated garbage fire.

> it forced them to hack a

It was not their action, nor is it hacked, nor is the message contained within pip.

The system works by pip voluntarily recognizing a marker file, the meaning of which was defined by https://peps.python.org/pep-0668/ — which was the joint effort of people representing multiple Linux distros, pip, and Python itself. (Many other tools ignore the system Python environment entirely, as mine will by default.)

Further, none of this causes containers to be necessary for installing ordinary projects.

Further, it is not a problem unique to Python. The distro simply can't package all the Python software out there available for download; it's completely fair that people who use the Python-native packaging system should be expected not to interfere with a system package manager that doesn't understand that system. Especially when the distro wants to create its tools in Python.

You only notice it with Python because distros aren't coming with JavaScript, Ruby etc. pre-installed in order to support the system.

Re: Hard Rust requirements from May onward

#607

Post by zahlman »

ashirviskas wrote: post #598
cozzyd wrote: post #596

Earlier quoted context omitted.

this is not normally a problem for a distro where the environment is well known

Can you expand? I'm honestly curious how it is not a problem in Pythons case

That asks GP to prove a negative. What problems have you encountered, and why do you believe them to be common?

Re: Hard Rust requirements from May onward

#608

Post by zahlman »

fweimer wrote: post #422
throwaway2037 wrote: post #413

Earlier quoted context omitted.

Is X11/KDE considered part of the "base system"? If yes, then: > indeed, there's quite a few commenters here who I think would be surprised to learn that not only is C++ on this list, but that it's been on it for at least 25 years ... isn't so surprising.

The Debian base system is much, much smaller. I'm surprised that people consider Python to be part of it. However, APT depends on Perl and the C++ run-time library, so those two languages have been part of the base system for a very long time.

> I'm surprised that people consider Python to be part of it. However, APT depends on Perl

Pardon?

  $ file `which apt`
  /usr/local/bin/apt: Python script, ASCII text executable

Re: Hard Rust requirements from May onward

#609

Post by zahlman »

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.

A pity the banks didn't do that with COBOL....

Re: Hard Rust requirements from May onward

#610

Post by alfiedotwtf »

einpoklum wrote: post #433
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…

> Critical infrastructure still written in C ... is technical debt that is only going to get worse over time. No. Rust is not magic, it just forces a discipline in which certain safety checks can be made automatically (or are obviated entirely). In other languages like C, the programmer needs to perform those checks; and it's technical debt if the C code is not coded carefully and reviewed for such issues. If coding…

> If coding is careful and the code is review - there is no technical debt, or perhaps I should say no more than the unsafe parts of a rust codebase or the standard libraries.

History shows again and again that this statement is impossible..

Name a large C application that’s widely used, and I’ll show you at least one CVE that’s caused by a memory leak from the project

Post reply on HN