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

631–640 of 797 posts

Re: Hard Rust requirements from May onward

#631

Post by richard_todd »

pornel wrote: post #604
richard_todd wrote: post #571

Earlier quoted context omitted.

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

Nah, I called out redox and another commenter pointed out ripgrep as an even better example of what I’d prefer to see, and those are also by what I would call rust enthusiasts. I don’t think of them as a monolithic group.

Where we disagree is I would not call injecting rust into an established project “writing a better version”. I would love it if they did write a better version, so we could witness its advantages before switching to it.

Re: Hard Rust requirements from May onward

#632

Post by cozzyd »

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…

and storage is a big deal for debian! It is basically the other player in embedded Linux other than rolling your own where a 4GB or smaller emmc is pretty common.

Re: Hard Rust requirements from May onward

#633

Post by zahlman »

bgwalter wrote: post #620
zahlman wrote: post #606

Earlier quoted context omitted.

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

Well the essential system Python should be in /usr/sbin and read-only (insofar Python allows that with its __pycache__ spam). The fact that users have to keep up with multiple PEPs, error messages, --single-version-externally-managed, --break-system-packages, config files everywhere, stealth packages in .local and uv to paper over all of this shows that Python packaging is completely broken.

> the essential system Python should be in /usr/sbin

There's still quite a bit you can do with the "system Python". Mine includes NumPy, bindings for GTK, QT5 and QT6, Freetype, PIL....

> insofar Python allows that with its __pycache__ spam

This is, to my understanding, precisely why the standard library is pre-compiled during installation (when the process already has sudo rights, and can therefore create the `__pycache__` folders in those locations). This leverages the standard library `compileall` module — from the Makefile:

   @ # Build PYC files for the 3 optimization levels (0, 1, 2)
   -PYTHONPATH=$(DESTDIR)$(LIBDEST) $(RUNSHARED) \
    $(PYTHON_FOR_BUILD) -Wi $(DESTDIR)$(LIBDEST)/compileall.py \
    -o 0 -o 1 -o 2 $(COMPILEALL_OPTS) -d $(LIBDEST) -f \
    -x 'bad_coding|badsyntax|site-packages' \
    $(DESTDIR)$(LIBDEST)
> The fact that users have to keep up with multiple PEPs, error messages, --single-version-externally-managed, --break-system-packages, config files everywhere, stealth packages in .local and uv to paper over all of this shows that Python packaging is completely broken.

Please do not spread FUD.

They don't have to do any of that. All they have to do is make a virtual environment, which can have any name, and the creation of which is explicitly supported by the standard library. Further, reading the PEPs is completely irrelevant to end users. They only describe the motivation for changes like --break-system-packages. Developers may care about PEPs, but they can get a better summary of the necessary information from https://packaging.python.org ; and none of the problems there have anything to do with Linux system Python environments. The config files that developers care about are at the project root.

Today, on any Debian system, you can install an up-to-date user-level copy of yt-dlp (for example) like so, among many other options:

  sudo apt install pipx
  pipx install yt-dlp
You only have to know how one of many options works, in order to get a working system.

Re: Hard Rust requirements from May onward

#634

Post by zamalek »

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 was done with uutils. I'm daily driving them.

Re: Hard Rust requirements from May onward

#635

Post by sprash »

parliament32 wrote: post #331

It makes me uncomfortable that this mandate is coming from a Canonical employee. After all, if this switch was a good idea on merit alone, it would happen organically without requiring this kind of combative communication. What's the long-term play for Canonical here?

The long term play is to drive out community participation and bring in corporate control in the apt/Debian ecosystem.

Re: Hard Rust requirements from May onward

#636

Post by spacechild1 »

themafia wrote: post #583
spacechild1 wrote: post #511

Earlier quoted context omitted.

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

> that you can't design a language without an official standard? No, just that it's not 1968 anymore, and if you want to claim your language has learned lessons from the past, then this is one that clearly got missed. > The phrase "design by committee" isn't typically used as a compliment... While the phrase "emergent incompatibilities" is only known as a detriment. > It's "only" the single most important class of bu…

Ah, now I realize that you don't necessarily meant something like an ISO standard. I definitely agree that a programm language should have some kind of normative specification and it's not sufficient to say "the spec is the behavior of the compiler".

> Again, I ask for a reference, "according to what?" I understand this is the zeitgeist.

I think that at this point it is pretty well-established that the majority of security CVEs in C or C++ applications are caused by memory safety bugs. For sources see https://www.cisa.gov/news-events/news/urgent-need-memory-saf.... As a C++ dev this totally makes sense. (I just happen to work in a domain where security doesn't really matter :)

Re: Hard Rust requirements from May onward

#637

Post by Panzer04 »

kstrauser wrote: post #225
allisdust wrote: post #204

Earlier quoted context omitted.

Sadly most people don't agree with this I have been seeing hatred on this forum towards Rust since long time. Initially it didn't make any kind of sense. Only after actually trying to learn it did I understand the backlash. It actually is so difficult, that most people might never be able to be proficient in it. Even if they tried. Especially coming from the world of memory managed languages. This creates push back a…

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…

I'm very confused, explain how this is not the case with C?

I haven't written rust, but my impression is the benefit is more about deeper introspection of things like lifetime than basic typesafety, which already exists in C/C++ (and is likewise occasionally bypassed for convenience, so I wonder how often the same is done for Rust)

Re: Hard Rust requirements from May onward

#638

Post by pjmlp »

cma wrote: post #486
gpm wrote: post #358

Earlier quoted context omitted.

I really like the idea of Fil-C for derisking legacy code, but - It's not an option for debian core infrastructure until it supports at least the same platforms debian does (arm, riscv, etc) and it currently only supports x86_64. - It doesn't turn C into a modern language, since it looks like there's active development here getting the productivity benefits of moving away from C is likely still worth it.

If C isn't going away yet, just doing filc for x84_64 might still be a big win as it could catch a lot of stuff at runtime for x84_64 users that can then be fixed for everyone.

Given that a few languages from similar timeframe are still around, even if with fewer users, it is guaranteed to stay around as long as current computing models stay relevant.

Re: Hard Rust requirements from May onward

#639

Post by pjmlp »

zahlman wrote: post #609
jbv027 wrote: post #397

Earlier quoted context omitted.

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

They did, Java and .NET.

Re: Hard Rust requirements from May onward

#640

Post by hedora »

nmstoker wrote: post #626
zahlman wrote: post #606

Earlier quoted context omitted.

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

Thank you! Exactly what I wanted to explain.

Yet, if I write a dockerfile, and need to use perl, system perl is fine.

If I need a python script, I have to arrange for all the RUN lines to live inside a virtual environment inside the container.

Post reply on HN