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

671–680 of 797 posts

Re: Hard Rust requirements from May onward

#671

Post by testdelacc1 »

hunterpayne wrote: post #629
testdelacc1 wrote: post #124

Earlier quoted context omitted.

> not the same as having a hostile community Hostile according to who? According to the haters, maybe. I’m sure the Go community was called “hostile” by haters back in the day. Look at the drama created by Linux maintainers who were being insanely hostile, coming up with spurious objections, being absolute asshats - to the point where even Linus said enough was enough. The Rust for Linux members conducted themselves…

My friend, the OP in this very thread has in multiple posts, made outright slanderous comments about C programmers. The reputation of the Rust community is very much the making of the Rust promoters. If you are seeing pushback, that's just the consequences of such behavior. I also notice that these language debates are very much generational. That has a few consequences. First is that older devs have thicker skin. Se…

Here, find the “null result” in this study by the Android team - Eliminating Memory Safety Vulnerabilities at the Source (https://security.googleblog.com/2024/09/eliminating-memory-s...). They stopped adding new memory unsafe code and they saw a dramatic drop in the number of memory safety vulnerabilities. They only write new code in Kotlin or Rust now.

The Android team shipped a more secure operating system to billions of people. Their lives are better because of choosing more Rust and Kotlin and less C++.

> You can't write a device driver without manipulating memory directly.

This isn’t the gotcha you think it is. Check out this upstreamed driver - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

This is a successful kernel driver that powers all IPC in Android. This is the most load bearing component in Android, especially because it is constantly being attacked by malware. It manipulates memory just fine actually.

In your hurry to dismiss Rust, you haven’t done a technical evaluation of it. If you had you wouldn’t conflate memory safety with a lack of memory manipulation. You’ve taken the intellectually lazy shortcut of dismissing a new thing because no new thing can be as good as the old things.

I write all this not to convince you to change your mind. I don’t think that’s possible. I write it so anyone else reading this will avoid your thought process. I don’t need to convince you, because this industry is moving ahead regardless.

Re: Hard Rust requirements from May onward

#672

Post by alserio »

spacechild1 wrote: post #636
themafia wrote: post #583

Earlier quoted context omitted.

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

Can I ask what that domain is?

Re: Hard Rust requirements from May onward

#673

Post by im3w1l »

zahlman wrote: post #633
bgwalter wrote: post #620

Earlier quoted context omitted.

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

> All they have to do is make a virtual environment

Okay so to create a five line script I have to make a virtual environment. Then I have to activate and deactivate it whenever using it. And I have to remember to update the dependenceis regularly. For my five line script.

Seems to me the companies managing mloc-codebases pushed their tradeoffs on everyone else.

Re: Hard Rust requirements from May onward

#674

Post by loeg »

LtWorf wrote: post #595
loeg wrote: post #357

Earlier quoted context omitted.

Yeah, and you can still run i386 binaries on widely available amd64 CPUs. So this is an even stronger argument for killing these other obsolete platforms.

You can only run the binaries if you have the libc to run them.

You say that like it is a higher or even comparable barrier to having alpha/m68k/sh4 hardware; it isn't.

Re: Hard Rust requirements from May onward

#675

Post by loeg »

ChocolateGod wrote: post #585
loeg wrote: post #400

Earlier quoted context omitted.

We have an alternative that isn't 10x slower, and comes with many other benefits (Rust). The only cost is losing hardware support for some very obsolete and very unpopular platforms. (Nevermind that Fil-C's hardware support is narrower than Rust's.)

Rust doesn't automatically add memory safety to all existing C code, which will need to be maintained for decades, Fil-C nearly does and its still early days. > We have an alternative that isn't 10x slower, and comes with many other benefits Anyone involved with development around a fruity company would say Swift ;)

I don't get the impression the Swift team is especially interested in use cases outside of OS X and iOS. (The context here is Debian.)

Re: Hard Rust requirements from May onward

#676

Post by blub »

bigstrat2003 wrote: post #652
cardanome wrote: post #460

Earlier quoted context omitted.

So a change to the worse. The GPL protects the freedom of the users while MIT-licensed software can be easily rug-pulled or be co-opted by the big tech monopolists. Using GitHub is unacceptable as it is banning many countries from using it. You are excluding devs around the world from contributing. Plus it is owned by Microsoft. So we replaced a strong copyleft license and a solid decentralized workflow with a centra…

> The GPL protects the freedom of the users while MIT-licensed software can be easily rug-pulled or be co-opted by the big tech monopolists. That is not at all true. If someone were to change the license of a project from MIT to something proprietary, the original will still exist and be just as available to users. No freedom is lost.

With GPL I can compile my own copy and use it with their software. They have to allow that. They also have to give me their sources, changes included.

MIT is a big joke at the expense of the open-source community.

Re: Hard Rust requirements from May onward

#677

Post by throwaway7356 »

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…

> my point is it would be more sensible to say "I'm going to introduce an oxidized fork of apt and a method to use it as your system apt if you prefer" and then over the next year or so he could say "look at all these great benefits!" (if there are any). At that point, the community could decide that the rust version should become the default because it is so much better/safer/"modern"/whatever.

That's not how open source software development works.

I wasn't asked by Linus whether ipchains should become the default over ipfirewall nor whether iptables should become over ipchains.

I wasn't asked whether GCC should use C++ instead of C as the language to build GCC itself.

I can go on with lots of examples.

Why should APT be different and require the maintainers to fork their own project do introduce changes? Why should an undefined "community" (who is that? apparently not the APT developers...) decide? Does this have to be done for every code change in APT?

Re: Hard Rust requirements from May onward

#678

Post by julian-klode »

mkl wrote: post #577
julian-klode wrote: post #514

Earlier quoted context omitted.

Do keep in mind that a lot of the people involved in these sorts of things are neurodiverse in some ways, and may have significant trouble dealing with change. As teh64 helpfully pointed out in https://news.ycombinator.com/item?id=45784445 some hours ago, 4ish years ago my position on this was a total 360 and I'd have had the same reaction to now-me's proposal.

*180, for other people confused by this.

/me hides in shame

Re: Hard Rust requirements from May onward

#679

Post by blub »

jeroenhd wrote: post #437
teh64 wrote: post #403

Interesting how a person's opinion can change: https://news.ycombinator.com/item?id=27594688

If only more people were willing to let their opinions be changed over time like that, rather than clinging onto them.

It depends if the original opinion was a reasoned one or just based on personal feelings.

The dependency explosion is still a problem and I’m not aware of any real solution. It would have been interesting to to see why their opinion changed… I’m guessing it’s as simple as the perceived benefits overriding any concerns and no major supply-chain attacks being known so far.

Re: Hard Rust requirements from May onward

#680

Post by solidsnack9000 »

Antibabelic wrote: post #26
Mond_ wrote: post #11

Earlier quoted context omitted.

> IMHO Rust has severe problems and what is considered "modern" is mostly taste. Really? As opposed to e.g. C or C++ (as the most important languages which Rust is competing with)? Sure, taste plays into everything, but I think a lot of people work with Rust since it's genuinely a better tool. I hear you on free software being controlled by corporate interests, but that's imo a separate discussion from how good Rust…

Ada and SPARK fulfilled the promise of a safe systems language decades ago without making most of the mistakes Rust does. Rust has its strong sides, sure, but it's far from the only shop in town. The GCC happens to include an Ada compiler as well.

What are those mistakes?

It seems like Ada more or less has to have memory safety bolted on -- that is what SPARK does -- and it's not clear that Ada's bias towards OO is better than Rust's bias towards functional programming.

Are you talking about features like type inference (so the Rust code could be less clear, since types are not always written out)?

Post reply on HN