Live data from Hacker News

A Sad Day for Rust

words.steveklabnik.com

801–810 of 1001 posts

Re: A Sad Day for Rust

#801
post #6

I don't know how to word this so I'll say it bluntly (and probably bear the blunt of this community as a consequence): If you're a developer of a project that is used in a security-sensitive context, you either be receptive to security concerns or you clearly label your project as a toy project. No one expects you to write perfect code, but we do expect you to fix flaws when you learn about them. Of course, you could…

What must have gone horribly wrong during the course of software history that led to people acting so entitled about free open source projects? You use it, you evaluate then accept the consequences. You don't? Well Patch it. You can't? Use an alternative. Nothing else available? Fork it and fix it. If nothing works for you, then either you're the problem, or the entire field has an unsolved problem (and you're not he…

The thing that changed is we began building off of more and more open source, and so it became more and more important. Nobody is expecting a project's original creator to slave over it eternally. They are instead expecting them to clearly signal their intentions. A "Not Maintained" flag, or "Read my design philosophy before using", after understanding community expectations, is no effort and a reasonable expectation. Counter arguments like to think we are islands and that because we never signed an official contract, we have no responsibilities to anyone but ourselves. But that is not how society ever has or ever will work, and there never has nor ever will be any such thing as "leaving" society (other than death). There's a social contract that you are (unwillingly) a part of, and that's reality. Entitlement here is merely people implicitly recognizing that fact.

EDIT: This rant is a general reply to your general sentiment, not a specific reply to this particular case. I have no idea whether the author did in fact signal appropriately their design, risk, etc.

Re: A Sad Day for Rust

#802

Earlier quoted context omitted.

This isn't a serious response. As amply demonstrated in TFA and elsewhere, the harassment was far more than "reporting bugs". And, anyway, yes, reporting bugs can be extremely annoying. Different devs respond to this annoyance differently. npm devs, for example, have decided not to pay too much attention to bugs reported by the public. [0] [0] https://npm.community/c/bugs

> And, anyway, yes, reporting bugs can be extremely annoying. I would never touch the product of someone who found bug reports annoying.

Strangely, I would rather deal with developers who find bug reports annoying than folks who simply ignore them. The former have a touch of pride and you have a chance to get them to see your point of view. Better that than speaking to a black-hole.

Re: A Sad Day for Rust

#803
post #746
post #685

Earlier quoted context omitted.

> but there'd probably be a couple weeks of chaos. Does Linus bear zero responsibility because he's a volunteer Linux Foundation would appoint somebody else on his place and have him sign similar contract. It would be likely a person that is already employed in similar capacity - one of current paid maintainers. No fork would be needed. Linus Torwalds is not a volunteer at this point. Linus Torwalds will leave linux…

It is a bad example but most major open source projects are in that regard. However, the community driven ecosystems (Rust, Go, JavaScript ..) have significant components in that particular unpaid maintainer situation. And that is a problem.

Go is done and maintained by google employees. JavaScript specification has syndicate behind it. Rust has clear governance, through I cant find who pays for it all.

Any big enough project will formalize relationships at one point or another - latest when they need to raise money or organize conference. These projects are too big to be run over the weekend, they do have to pay regular staff.

Re: A Sad Day for Rust

#804
post #460

Earlier quoted context omitted.

Right now, if you want async/await, you either have warp or tide. Hopefully gotham or rocket gets around to updating.

Can anyone comment on how close Rocket is to a 0.5 release? I’ve been wondering for awhile, but opening an issue to ask seems annoying.

I don't have any insight but you can subscribe to this issue to see how things are moving: https://github.com/SergioBenitez/Rocket/issues/1065

Re: A Sad Day for Rust

#805

I've written a lot of Rust code that's in production in web, messaging and telephony contexts. I considered using Actix early on, but as soon as I saw the large amount of unsafe code, I stopped considering it at all. I did not go on the Internet and try to convince other people not to use it. I did not complain at the maintainer that he should manage his project differently. I just didn't see why a library doing what…

as soon as I saw the large amount of unsafe code, I stopped considering it at all

So in that case you wouldn’t use any software written in plain C, right?

Re: A Sad Day for Rust

#806
post #661

Earlier quoted context omitted.

The license only frames the projects legal responsibilities. It is entirely unrelated in every way to how the project is run on a day to day basis. Alternatively if we're going to just go strictly by the license then the maintainer deserved all the flames & flak he got. After all, it wasn't against the license, therefore he cannot complain about it. Just like that idea is unreasonable, so too is trying to hide behind…

> The license only frames the projects legal responsibilities. It is entirely unrelated in every way to how the project is run on a day to day basis. You completely missed the point. At the end of the day, the legal obligations are the only ones, and both the Apache and MIT licenses very clearly state that the creator of the software has no obligations to any user. Therefore, any other supposed obligations only exist…

> Sorry, this doesn't make sense, because you're comparing an explicit statement of liability in the license to the social norm of not being a massive jerk.

Of course it doesn't make sense, that was my point! In the same way it doesn't make any sense to do what you're doing, which is comparing the explicit statement of liability in the license to the social norm of how open source projects are framed & run.

You missed the point that everything we're talking about is just social norms. The license is irrelevant here, for all sides. There is no legal issue being disputed.

Re: A Sad Day for Rust

#807
post #16
post #6

I don't know how to word this so I'll say it bluntly (and probably bear the blunt of this community as a consequence): If you're a developer of a project that is used in a security-sensitive context, you either be receptive to security concerns or you clearly label your project as a toy project. No one expects you to write perfect code, but we do expect you to fix flaws when you learn about them. Of course, you could…

I'm not sure which license was used by actix-web, but let me quote the last section of the MIT license as a reply: > THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILIT…

OpenSSL's license (Apache v2), also has the "AS IS" clause. I guess we should just wholesale dump any concept of security since the very basic technique of protecting oneself from litigation on the possibility of something going wrong should instead now be interpreted to mean "this is a toy project with zero guarantees".

There is a difference between "Hey, this is a silly side project so definitely use at your own risk, as far as I'm concerned its a place for me to learn and should be treated as a toy" and "Hey, I think this is worth your time, you should use this in your production stack, and obviously I've set up legal protections so you can't sue me if something goes wrong, but I am trying to push this as something lots of people should use and trust".

If someone walks into my house and tries cookies I'm clearly learning how to make and then throws up, that's very different than me putting up a big "FREE AMAZING BETTER COOKIES" sign on the sidewalk and handing them out and having people throw up. In both scenarios, the cookies are free! What are you blaming me for! How entitled! In the first, I think that position is more defendable. In the second, ehhh.....

For the record -- I'm not super familiar with this project, but I think that a lot of people don't consider the ramifications of being successful sometimes: your project could be used by a big company and lead to people's information getting hacked (and those people had nothing to do with any of these decisions). The only thing asked is to be upfront that this is not intended for that, as opposed to the temptation of calling your thing the best and telling everyone to use it. In the run up of a project, I think it's easy to forget that and get really hyped on showing how your thing is better than some incumbent for example. Just something to keep in mind.

Re: A Sad Day for Rust

#808
post #325

Earlier quoted context omitted.

Here is an example of an actual comment. I believe the thread is deleted now: > "seriously? Please just stop writing Rust. You do not respect semver, you do not respect soundness, so why are you using a language predominantly based around doing these things right?" This is what I was thinking of when I wrote "far, far over the line."

Depending on the context that doesn't seem to be "far, far over the line." Just about any thread on HN regarding any aspect of systemd or Google will have comments which are much more vitriolic.

HN discussions do not always live up to HN ideals. This is not be used as a reason to drag others down to our level. Instead it should make us reflect on our own behaviour.

Re: A Sad Day for Rust

#809

Earlier quoted context omitted.

I think you're missing a point. If you promise something, people will get upset if you don't deliver. There were no promises made here. If you want to compare it to your example, it's more like your "primary teacher" would ask you to cover one week after other and after 3 years you'd say you just won't do it anymore - should anybody be upset at you?

I don't know enough about the specifics of this situation. My point is, I don't agree with the idea that volunteers inherently owe nothing. And to focus on a different part of the analogy for a moment—if somebody looks more closely at what I'm teaching students, and sees that I'm actually showing them how to use flamethrowers, yeah, they have a right to be upset. Again, it doesn't matter that I'm a volunteer, they've…

He's the author, not a voluneer. He didn't promise/volunteer to do anything.

Re: A Sad Day for Rust

#810

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

A community grows and eventually reaches the point where users cannot recognize who they're interacting with nearly every time, where the submission queue is trailing down too fast for any single reader to process. When that happens, it can no longer function as a cohesive community. It becomes about as personal as a magazine about the very same topic. Furthermore, the incentives to post change due to the higher pote…

> Armchair psychology, coupled with pure distilled condescension.

Please edit out name-calling from your comments on HN, as the site guidelines ask: https://news.ycombinator.com/newsguidelines.html

Your comment would be fine without the first sentence.

Post reply on HN