This whole thread seems to be unaware about Debian… so I’ll give an actual answer.

Debian only actually updates their software packages every 2 years, this is for stability purposes. However you still need to fix some severe bugs so about every 2-3 months Debian does point releases that are only updating for security fixes. This is one of them.

When Debian 14 actually releases it will upgrade nearly all of the packages that are in your base system.

Chatgpt just cribs from stack overflow, which in turn just cribs their answers from documentation. Once you figure that out, they both become surprisingly useless.

deleted by creator

The bizarre thing is that they are only analysing something like 40 programs/library. You could reach the same conclusion clicking through their gitlab for a few minutes.

The translation rate is the actually interesting part.

“Game dev… Just force Rust into it”

What’s wrong with Rust for game dev? It seems similar to C++, and C# which are the dominant languages.

I can see arguments that the current projects have poor approaches, but not that the language itself is ill-suited.

You’re correct in your assessment of the worst-case of distro maintainers, however many distro developers/maintainers do contribute to the upstream ( Debian policy explicitly encourages it, I only speak for Debian because that’s the only project I’ve worked in) and do vet and understand the software.

“It can’t be better”. Except distro maintainers can block it from being included if they find errors. As noted above they also often file pull requests against the upstream. This happens a fair amount actually.

I think you are completely missing the point. Packages distributed by Debian are less likely to be insecure because Debian policy requires reviewing all source code to make sure it meets interoperability and open-source standards.

Regardless of how frequently this is actually done, if it’s done at all is a point in favor of using Debian distribution. The fact that Debian has introduced errors themselves in a few cases is irrelevant, any developer can do that and crates.io is full of them with not even an attempt at additional review.

You need to balance whether or not the distributor is fixing or introducing more bugs, and in the case of Debian it seems to be overwhelmingly the former.

Your argument that crates.io is a known organization therefore we should trust the packages distributed is undermined by your acknowledgement that crates.io does not produce any code. Instead we are relying on the individual crate developers, who can be as anonymous as they want.

Debían developer is a specific position that you apply for. Anyone can be a maintainer. Well, I had to get approved but I don’t know the qualifications, I already had code in Debían vía GNOME.

bc can handle extended-precision integers, unlike bash which maps them to floats.

I think that there are certain attitudes that mainly occur to people outside the domain. Like how people endlessly shit on open-source projects, but few of those people are ever actually at the wheel of one.

Not hentai but “Anubis”, the webscraper deterrent has an anime girl and it looks quite unprofessional, and what’s worse is something like balancing Anubis’ scales would be a much better image than a girl with a magnifying glass.

It’s very hard to get a good look at which arguments are good or not without having the experience to evaluate them.

Here’s my view on Rust vs C or C++. Rust is a stricter language which makes it easier to code with low run-time errors, which is great for writing large scale projects. Now the problem with this is that you can write C++ to also be strict but it’s a lot more verbose than the standard approach, so most developers don’t. This causes disagreement among Rustaceans and C/C++'ers. The C++'ers are correct that you can replicate anything in Rust in C++. A correct program is a correct program regardless of the language it’s written in. Rustaceans also oversell when it comes to program correctness, tons of Rust programs have errors; Rust can help minimize errors but it’s not a silver bullet. Rewriting-in-Rust for an already good program is a fools errand; the outcome will probably be a worse program. However Rustaceans are correct in pointing out that the C++ written programs tend to have more errors, it’s just not the rule they pretend it is.

In summary, Rust is a great language but Rustaceans oversell it. Many of it’s apparent advantages can be mitigated by good development practice. It’s just that good practices are difficult and uncommon.

(Note that there are also 3-rd party tools like static analysers, which can help developers detect errors. So again Rust is better out of the box, but ultimately you can get the same outcome with some work).

If what the original commenter said is true about simply replacing keywords with another string, then it’s questionable if they are actually learning anything about language design or demonstrating skill.

“Take them at their word”

Who? Has there been a survey of contributors?

“Genuinely think that coreutils would be better if it were written in Rust”

I feel like the skill-level of the contributors is high enough that they would not be so naive.

Programs in different languages can compile to the same machine code. Any advantage would be in language constructs. But if you already have an existing C implementation what advantage do you do from a Rust implementation?

I personally write in 3 languages: Rust, C++, and Fortran ( or rarely SPARK). I don’t port my code across languages, because there is no advantage. If I wanted it better, I would work on my existing codebase.

Porting really only helps if the original language was hindering development, deployment or runtime. These arguments don’t really hold with C, a fast, low-dependency language that is more widely used than Rust.

Being written in Rust has mixed effects. Rust is still less mainstream than C, so fewer people can contribute. However, it does attract more interest because it’s different.

However, the reasons why you create/contribute to new-but-similar projects is to add functionality that the original project doesn’t have. By nature a coreutils replacement has to behave like coreutils or else it will break many configurations. This severely limits the functionality you can provide. So why are people (and Canonical) contributing so much labor to something that still doesn’t function as intended?

I say it’s the licensing. I say this as someone who regularly gets requests to change the licensing of my software (more than any feature request). I think licensing is a big deal, and most software devs recognize that.

You are fixating on the incorrect premise. I noted that it was started a decade ago as a analogy for how labor intensive the project is. A project that by design has to mirror the behaviour of coreutils.So why are people investing the time in this? What makes it worthwhile? It’s the permissive license. If uutils used GPL individuals would instead try to contribute to the much more utilised coreutils, where their contributions would be guaranteed to have an impact.

Edit: Some of the earlier issues date from 2013, so it has been a decade, although it probably was very obscure at the time.

I’m fairly certain that people who advocate for teaching ethics, only do it under the assumption that people are being taught to do what the proponent wants. In reality learning ethics is just learning different theories of ethics.

But the permissive license is why it gained traction, otherwise who would spend so much resources on something that a decade later only accomplishes 85 percent of what coreutils does?

Removed by mod

I write quite a bit of Rust, and I’m still at a loss.

It’s easier to write a low-error program in Rust. But low-error program in any compiled language is going to be essentially identical.