Live data from Hacker News

A Sad Day for Rust

words.steveklabnik.com

471–480 of 1001 posts

Re: A Sad Day for Rust

#471
post #385

I love Rust and use it daily. Unsafe isn’t something you live without, you just avoid unless there’s a decent reason. Setting aside actix-web, the community has this really annoying obsession with not using unsafe anywhere. You’re not replacing decades of computing overnight, though, and it’s not the end of the world if it’s there sometimes. It often feels like newcomers and zealots preaching the unsafe issue, too. I…

You can't squat and redirect subreddits to external sites. I have personally been granted mod of a subreddit that had been redirecting to another website. Its against the rules and the subreddit will be banned at which point anyone can use /r/redditrequest to take it over. Even if that did work however, people would create adjacent subreddits that would end up to be defacto sureddit, for example /r/competitiveoverwat…

I’ll defer to you on this, but I definitely know I’ve come across subs where this has been happening for years and they’re not shut down.

Re: A Sad Day for Rust

#472

Question: why didn’t the more safety-focused developers just fork the project? I feel like fork-o-phobia causes 90% of the incidents like this.

Forking is extremely aggressive, and just because someone has the time to write a patch doesn't mean they have the desire or time to run a project.

Forking is an act of love. If you fork a project of mine, you show that you care enough about it to maintain it yourself, but your time and energy into my "original" code.

Forking can be aggressive if you write deprecating things into the forked project's readme, but of course you don't have to do that.

You could also talk to the old maintainer before forking; maybe they are happy to give up some responsibility, or maybe they even endorse a fork.

Re: A Sad Day for Rust

#473

Earlier quoted context omitted.

Not everyone who uploads an open source project to some random cloud hosting service (i.e. Github) is qualified or wants to be a maintainer. Remember that being a maintainer is equivalent to project management. A lot of people publishing open source code don't seem to care about this and just want to write interesting programs. And that's fine. I personally have sent patches to lots of people who just never responded…

No, no, no - none of this is about legality. Just sometimes people bring it up as a framework for determining responsibilities, so I addressed it ahead of time. I don't think (legal requirements) == (responsibilities). The sets may have some overlap but clearly they are not identical. Instead, I am just saying that if I upload a "cool tool" to github, and I notice that it has become super popular, and I don't have ti…

Maybe you do, I'm sure people would appreciate that, but it's not necessary. The nature of these things is that the users are already "following the herd" to a degree. So if the maintainer becomes inactive and a fork picks up the interest, they will just move to that. No ceremony required.

Re: A Sad Day for Rust

#474

Earlier quoted context omitted.

Ada’s language is probably clearer and less loaded: checked and unchecked.

Yeah, and interestingly, a lot of unsafe functions use "unchecked" in their names. The issue was that by the time this was recognized, there was too much Rust code, and there was no clear alternative that people universally liked. This kind of conversation is the definition of bikeshedding. I submitted an RFC and it... didn't go well. (I think I picked "trustme" though.)

Back then Rust did not have editions. I think it would be worth exploring renaming `unsafe` blocks to "sound", because when one writes `sound { ... }` what one is actually stating is that the code in the block has been proven sound.

The `unsafe` function type modifier can be left as unsafe, or renamed to unsound, since that what that is doing is stating that a particular function is not always sound to call.

Re: A Sad Day for Rust

#475
post #343
post #302

Earlier quoted context omitted.

> 1. YOU are responsible for your dependencies. They not only created issues, they also created patches. That is taking responsibility. They were contributing time and expertise back. Having a project maintainer then call those patches boring or otherwise disregard them? That's childish. He showed time and time again he would respond without civility when an issue was demonstrated in his code. Sadly, that led to some…

> Having a project maintainer then call those patches boring or otherwise disregard them? That's childish So what? Along the same lines, it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them. The fact that you call them childish for not acting they way you want them to makes me think you are the childish one. With those PRs w…

It was advertised as a production-ready web-framework, and it was very popular. When do people get to complain? "Oh, my credit card information was stolen due to memory issues in this web-service, it's fine though, we didn't pay the guy, so we can't blame him.". Web-frameworks are cornerstones for security, and if you write one, advertise one, you need to care about security. Features, code-style, ad-hoc PRs, bug-fixes: little responsibility there, but security is something that can hurt a lot of people if done wrong. The use-after-free bug this was about could've been exploited in the right circumstances.

If I build a playground for free and it gets popular in my neighbourhood, and then collapses on some poor kid, I'm still responsible, even if I did it for free.

The way it was handled was definitely NOT productive though, the guy didn't deserve the flames.

Re: A Sad Day for Rust

#476

A lot of this thread has it wrong, and this wrongness contributes to the problem which led to this. I have two simple mantras which establish my philosophy here: 1. YOU are responsible for your dependencies. 2. Open source participants are volunteers and owe you nothing. It was never Nikolay's job to vet actix-web for you, nor did it become his job when the library became popular, nor does invoking "security" change…

> It was never Nikolay's job to vet actix-web for you Imagine if the linux maintainers took this attitude. This attitude severely undermines the credibility of opensource. If users of opensource libraries can't have confidence that those libraries are written correctly, we might as well all go back to commercial software.

They do. It is right there, in the LICENSE file.

It is a simple cost/benefit analysis. Your risk of presuming that Linux today is sufficiently good for what you need to do is lower than it was 10 years ago, which is why Linux today is more popular than 10 years ago and a lot more popular than it was 20 years ago.

Re: A Sad Day for Rust

#477
post #271

Earlier quoted context omitted.

Open source maintainers have no such responsibility. Anything you get for free is a gift, and giving a gift doesn't create any ongoing responsibility for the giver. Take it or leave it.

I disagree here, but only within the confines of the language I used. A maintainer of open source code is willingly submitting their own work to be used for free by others. They have no responsibility to extend it at all, but to maintain it is to do so in the interest of the users... they have a responsibility to do it to the best of their ability, and if not, the maintenance should be given to someone who will.

No. Just no. They may do so to the worst of their abilities. Thats their prerogative.

The only limit might be publishing something that is actively intended to do harm. But I can't imagine a plausible example of that...

Re: A Sad Day for Rust

#478
A necessary step on the way to Maturity. On Schedule.

Congratulations, Rust!

I mean this with no trace of irony. With maturity comes being used in ways you didn't intend, and might not want, even with unwelcome publicity. Rust will sail through more of these, and more, and they will cease to shock. People who care will start to pay attention to modules' underpinnings, and start to keep track, and certify. It takes a lot of conscientious people caring to uphold that, but maturity brings them.

Rust is designed to a high standard, and it takes extra work and extra armor to maintain it, just as it is worth the extra effort to learn it. It aims to be worth that, so we cannot begrudge that without betraying its purpose.

Re: A Sad Day for Rust

#479

> “Why Reddit is like this” is a whole other essay; I think it’s built into reddit’s structure itself. Classic Eternal September. Around 60k subscribers, the cultural identity starts degrading, as the amount of "old guard" is outmatched by "new blood." Therefore, the old "monkey see, monkey do" phenomenon, where new users would slowly mimic the culture of the prevailing older users to "fit in," is replaced with new u…

>distrust and aggression towards authority

Not an exclusive characteristic of a reddit user, there are many different levels and types of authority. Perhaps the aggression towards all authority, or weighted to certain personalities of authority rather than the ones in the background, especially the ones that don't really matter i.e. internet forum moderators

I agree with your general point that reddit fills a social vacuum in people's lives, like most social media does for others in different ways. Validation and expression etc.

Personally I think think that's why society in general has become generally more toxic, everyone is really telling it straight to others but not being honest with themselves.

Re: A Sad Day for Rust

#480
We always look at number of stars or installs of libraries before deciding to put them in a production project. It'd be cool if there was a "percent unsafe" badge that was commonly used for Rust repos. If folks started paying attention to it it'd be harder for unsafe libraries to become popular.
Post reply on HN