Live data from Hacker News

Resigning as Asahi Linux project lead

marcan.st

591–600 of 1001 posts

Re: Resigning as Asahi Linux project lead

#591
post #491

Earlier quoted context omitted.

The speaker doesn't understand the audience question and doesn't respond to it. The audience member points out that they shouldn't encode the semantics into the Rust type system because that would mean that refactoring the C code breaks Rust, which is not an acceptable situation. The speaker responds to this by saying essentially "tell me what the semantics are and I'll encode them in the Rust type system." That's ma…

> I have to say that I used to be excited about Rust, but the Rust community seems very toxic to me. I see a lot of anger, aggression, vindictiveness, public drama, etc. I had the same impression. Why all this drama is 90% of the time around Rust people?

Because many of them are still relatively young. There is nothing wrong with youth, but it can contribute to over-zealousness.

Also, for many of them, Rust is the first systems language they've ever touched. And that fact alone excites them. Because now they can "dream big" too.

But they have bought into the whole C/C++ are by default insecure and therefore garbage. In their mind, no mortal could ever write so much as a single safe function in those languages. So their points of view are always going to be based on that premise.

What they fail to recognize is that an operating system kernel, by virtue of the tasks it has to perform- things like mapping and unmapping memory, reading/writing hardware registers, interacting with peripherals, initiating dma transfers, context switching, etc.- have effects on the underlying hardware and the runtime environment; effects that neither the type system nor the temporal memory safety of Rust can model, because it happens at a level lower than the language itself. Rust's safety guarantees are helpful, but they are not infallible at that level. The kernel literally changes the machine out from under you.

They further fail to appreciate the significant impedance mismatch between C and Rust. When one language has concepts that are in fact constraints that another language simply does not have, there is going to be friction around the edges. Friction means more work. For everyone. From planning to coding to testing to rollout.

So you have well-intentioned, excited, but still self-righteous developers operating from what they perceive to be a position of superiority, who silently look down upon the C developers, and behave in a manner that (to outsiders at least) demonstrates that they really do believe they're better, even if they don't come right out and say it.

Just read the comments in any thread involving Rust. It is inconceivable to them that anybody would be so stupid or naive as to question the utility of the Rust language. To them, the language is unassailable.

The petty drama and social media brigading on top of it, along with the propensity to quit when the going gets tough, it's pretty easy to see why some people feel the way they do about the whole thing.

A programming language is not a religion. It is not a way of life. It is a tool. It's not like it's a text editor or something.

Re: Resigning as Asahi Linux project lead

#592

Earlier quoted context omitted.

Rust, which is a language I really enjoy, generates more social media outrage and religious wars than any other technical project I have been following for the past 20 years.

It must be said that from an outsider's point a view, in quite a few aspects it very much sounds like a cult. Get an HN article about C++, and you can be certain the comment section is going to deteriorate at some point into a religious war mentioning Rust. Get an article about Rust, and there is going to be drama in the comments. As a programmer that could potential consider Rust, it is off-putting.

I get the opposite experience, never saw those comments chiming in Rust everytime another programming language is mentioned or pushing in to rewrite everything into Rust, but I get comments complaining about such invisible forces.

Re: Resigning as Asahi Linux project lead

#594

Earlier quoted context omitted.

In practice, C has a couple of significant pitfalls that I've read about. First is if you compile with `-Werror -Wall` or similar; new compiler diagnostics can result in a build failing. That's easy enough to work around. Second, nearly any decent-sized C program has undefined behavior, and new compilers may change their handling of undefined behavior. (E.g., they may add new optimizations that detect and exploit und…

The warning argument is silly. It just means that your code is not up to par with the modern standards. -Wall is a moving goalpost and it's getting new warnings added with every release of a TC because TC developers are trying to make your code more secure.

I mean, yeah, I said it was easy enough to work around. But it's an issue I've seen raised in a discussions of C code maintenance. (The typical conclusion is that using `-Wall -Werror` is a mistake for long-lived, not-actively-developed code.) Apologies if I overstated the case.

Re: Resigning as Asahi Linux project lead

#595

Earlier quoted context omitted.

Maintaining backward compatibility is hard. I am sympathetic. Nonetheless, if the rust dev team think this is a big deal, then clarify in release notes, write a blog post and make a commitment that regression at this level won't happen again. So far, there is little official response to this event. The top comment in the thread I point to basically thinks this is nothing. It is probably too late do anything for this…

> Nonetheless, if the rust dev team think this is a big deal, then clarify in release notes, write a blog post and make a commitment that regression at this level won't happen again. So far, there is little official response to this event. There was an effort to write such a blog post. I pushed for it. Due to personal reasons (between being offline for a month and then quitting my job) I didn't have the bandwidth to…

Thanks for the clarification. This has given me more confidence in rust's future.

Re: Resigning as Asahi Linux project lead

#596

Earlier quoted context omitted.

It's not okay but he's giving them ammunition by mentioning them and complaining about them. It proves that it's working. When I started getting harassed in 2022 over an ill advised post on a site, the only thing that stopped it was to sandbag everything and rethink how I interacted on the internet.

Didn't your change in behavior also prove that your harassment "worked"?

Not at all. I haven't changed my principles. I simply learned how to say things better.

Re: Resigning as Asahi Linux project lead

#597

> My personal Patreon will be paused, and those who supported me personally are encouraged to transfer their support That seems silly; just assume people know about the change in circumstances and are trying to give you money for whatever you are doing at the moment, or in gratitude for what you've done before. The person exists, why pause the personal support?

The Patreon was specifically started to fund the Asahi development, so it's fairly disingenuous to continue taking those donations as not everyone will keep track. He can always start a new patreon.

Re: Resigning as Asahi Linux project lead

#598

One aspect of all of this which I haven't seen directly addressed[0] is the question of what might be going on with Torvalds and the Rust Foundation from a longer term, dare I say "political" standpoint. Torvalds seems to usually position himself as a kind of anti-political, code-is-code type, but then, perhaps there's more to him and to this story? There's an awful lot of money and power associated with operating sy…

I can't agree more. Linus position here is not dissimilar to CEOs and alike. He's trying to deal with R4L using his (allegedly) 100% technical and 0% political perspective but in this case it simply doesn't work. R4L is a political challange that require political discussions; who decides? what's the bar? who maintains what? etc

By not answering this questions and saying he doesn't want to have anything to do with the arguments, Linus simply decided that he doesn't want to solve the problem that only him can solve. The result is clear: R4L will fail if Linus decides that any maintainer can stop the "cancer" to spread and block Rust changes.

R4L implies that Rust will be present in the kernel and will need to be maintained. If Linus is ok with maintainers that have a deep/fundamental problem maintaining/coordinating the maintenance of Rust code, R4L will never happen.

Re: Resigning as Asahi Linux project lead

#599

Earlier quoted context omitted.

The comment you linked to explicitly shows that a maintainer does not consider this "okay" at all. T-libs-api made a mistake, the community got enraged, T-libs-api hasn't made such a mistake since. The fact that it happened sucks, but you can't argue that they didn't admit the failure.

"a maintainer" The way you word that makes it sound like "the maintainers" and "T-libs-api" do not consider this "okay". Reading just above the linked comment, however, puts a very different impression of the situation: > We discussed this regression in today's @rust-lang/libs-api team meeting, and agree there's nothing to change on Rust's end. Those repos that have an old version of time in a lockfile will need to u…

You're reading an artifact of a point in time, before the it hit stable and the rest of the project found out about this. t-libs-api misunderstood the impact because in the past there had been situations that looked similar and were unproblematic to go ahead with, but weren't actually similar. There were follow up conversations, both in public and private, where the consensus arrived was that this was not ok.

Re: Resigning as Asahi Linux project lead

#600

Earlier quoted context omitted.

There's also a level of professionalism depending on the product. When I'm responsible for an MSP team I'm very polite to them and always try to get them good, detailed, high-quality information when I'm telling them about problems with their work product, because I want them to do good work quickly and that's the best way to do that.

Yea, I'm not sure it's open-source vs other software. It's public vs. professional insiders. My company's bug tracker is mostly internally-filed bugs, but accepts bugs from the public. The difference in tone and attitude is night and day. The public-filed bugs can be wild, varying across: Rude, entitled, arrogant, demanding, incoherent, insulting, irrelevant, impatient... They are also the worst when it comes to actu…

> Frequently filed without logs, without reproduction steps, sometimes without even saying what the filer thinks is wrong.

In projects where this is a problem, I've made an issue template that clearly requests all the stuff I think I'll need. There's a big note at the top of the template that says it's not optional and that if it isn't filled out fully, I'll close the issue without comment.

And then I do that, every time. Sometimes they fill it out and reopen, sometimes they don't. Either way, I don't end up wasting time trying to help people who don't respect my time.

Post reply on HN