Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Sad Day for Rust

words.steveklabnik.com

Post reply on HN
Print view View original

851–860 of 1001 posts

Re: A Sad Day for Rust

#851

Post by unethical_ban »

deng wrote: post #260
unethical_ban wrote: post #221

Earlier quoted context omitted.

You know, there is a lot of "He isn't required" but I will say there are reasonable expectations that people have when a project gets to a certain level of exposure/downloads/etc. and while someone should not be "cancelled" or tarred and feathered for not accepting a merge request, if your project is a leader in its niche (Rust web frameworks) you should do better. You publish your code to Github, you're part of a co…

> You publish your code to Github, you're part of a community. Hell no. It that were the case, I'd never publish anything. > You make it open and allow for contributions and see people are using it, you should be clear about your level of give-a-shit. It is YOUR responsibility to see that for yourself by watching how the project is actually maintained.

Both are true. I obviously can't trust that maintainers will do what they SHOULD do via common sense and online civility, so I SHOULD vet them appropriately.

Why do so many people insist on being aloof and unhelpful in communicating to users of their software? What is so hard about offering a modicum of context for what people can expect of you as a maintainer? It's so ideologically rigid and unreasonable.

Re: A Sad Day for Rust

#852

Post by svick »

jwlake wrote: post #333
boutad wrote: post #180

Earlier quoted context omitted.

Then you might end up with a bunch of different forks each with different fixes applied.

A huge number of npm dependancies I use are basically unmaintained, have tons of forks and multiple PRs with the same fixes. I choose the one I like and move on, the magic of github!

Are you saying that that's a good thing?

Re: A Sad Day for Rust

#853

Post by egdod »

vunie wrote: 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…

>people who already volunteer their time for my benefit have to follow my rules when doing so

Ok.

Re: A Sad Day for Rust

#854

Post by alexashka »

This is what happens when you get attached to a language, a library and especially an idea of how things could be different.

You inevitably get disappointed. Good. Now you can evaluate and see if a different outcome is even theoretically possible.

When you hope, you lose :) It doesn't mean you cease hoping, it just means you don't do it so strongly. It's too much. You know it's too much, so just let go :)

Re: A Sad Day for Rust

#855

Post by unethical_ban »

bloodorange wrote: post #749
unethical_ban wrote: post #221

Earlier quoted context omitted.

You know, there is a lot of "He isn't required" but I will say there are reasonable expectations that people have when a project gets to a certain level of exposure/downloads/etc. and while someone should not be "cancelled" or tarred and feathered for not accepting a merge request, if your project is a leader in its niche (Rust web frameworks) you should do better. You publish your code to Github, you're part of a co…

I urge you (or anyone else who feels similarly) to seek a full refund for what you paid for the maintenance of that piece of software.

I urge you to stop thinking about how aloof and unhelpful you are permitted to be, and consider how minimally helpful you could be in communicating to users of your projects.

Re: A Sad Day for Rust

#856

Post by status_quo69 »

jmull wrote: post #523
status_quo69 wrote: post #401

Earlier quoted context omitted.

I want to preface my comment with "I agree with you" However, in this case patches and reproductions were submitted and rejected as "boring". Whether the author really meant to use the word "boring" is neither here nor there, the result was that the fix was ignored, even though that's how open source works! I've watched from the sidelines with no skin in the game (I use Rocket) and my conclusion from all of this is t…

I think you're still heaping unwarrented expectations on the developer. E.g, "...that's how open source works!" That's your opinion, but what obligates the developer to adhere to this? If the question is, was this a professionally run OSS project I would say, certainly not, and I assume almost everyone would agree. But so what? Why should a maintainer be expected to run an OSS project to a certain level of responsive…

If my comment implied that there was some sort of expectation then I think there was a miscommunication. There's no obligation for anyone to do anything, ever, but that's a pretty useless metric to mark against IMO.

Was this a professional project? Absolutely not. But was this a personal project? I would also say categorically "no", since it wasn't scoped under his personal github profile until recently. I'm very saddened to see something that could have been solely community maintained be revoked instead of there existing a potential mitigation plan in place (for example in the form of a foundation or Org) for situations like this, especially since this has happened twice before and it's sadly caused burnout for the main developer. Again, no obligation to do this but why can't I say "man, that's true that he could follow these actions but that's also shitty" at the same time?

Re: A Sad Day for Rust

#857

Post by tolmasky »

kelnos wrote: post #848
tolmasky wrote: post #807

Earlier quoted context omitted.

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

> 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". Essentially: yes. If you want any guarantees beyond that, you have to pay for them, or trust th…

But I can't fork it, not where it matters, that's the point. Me forking it doesn't get it distributed to all the services I use, some provided by the government for example. This is my point, as a customer, my forking doesn't affect my usage, usage that may be completely out of my control.

There have been times when society has decided that some utility was important enough to "transfer ownership" (imminent domain for example). Obviously that is an extreme case, and I am not advocating for that (in fact I am against that), but I am demonstrating that precedent exists for the feeling that some things ingrain themselves enough such that if you want to abdicate responsibility you should perhaps consider abdicating ownership. More than anything, I am trying to help explain how the other side feels.

But, as a trivial example, it's certainly not the case that they owe you nothing in the strictest sense. Under that model, they could technically put in code to forward all data to their servers and fall back to "well, as is, that's how we wanted it". I think that wouldn't hold up in court. There appears to be at least the basic expectation of good faith (and lack of criminality). Given that, perhaps it can be extended to negligence too. Perhaps not.

My position is actually a rather soft one, it's "If you heavily pitched your project and it ended up in the control systems of nuclear reactors, you should maybe expect people to be pissed at you if you willingly block critical fixes because you deem them boring". See, I'm not even saying what you should do, just more of a like "well, what do you expect".

Re: A Sad Day for Rust

#858

Post by kragen »

_-___________-_ wrote: post #352

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…

> There's no need to flame people for running their open-source project the way they want to run it. You can just not use the code.

Also, you can change your copy of it to work the way you want, and if you decide to share it, other people can choose to use your version if they like it better. You don't have to bully other people to get your needs meet, individually or collectively. These are among the core benefits of open source.

Probably in this case most people would have ended up using the less-unsafe fork of the project, and the original author would have tried harder to extract the potential performance benefits of his more-unsafe version, while both groups constantly learned from one another. Everyone would have benefited.

I've written a bit about the history of some such friendly forks at https://news.ycombinator.com/item?id=22080672

Re: A Sad Day for Rust

#859

Post by kragen »

zvrba wrote: post #414
jimbokun wrote: post #96

Earlier quoted context omitted.

Ok, so here is the article Klabnik cites, comparing various Rust HTTP clients: https://medium.com/@shnatsel/smoke-testing-rust-http-clients... Skimming this, the author doesn't really like any of them. Note, however, the long list of issues reported at the end of the article. Here is the first one I clicked on: https://github.com/algesten/ureq/issues/24 The maintainer is happy to get the report, and has an exchange w…

> Ok, so here is the article Klabnik cites, comparing various Rust HTTP clients: Interesting. I'm being led to believe that the actual problem lies in HTTP itself: it is too convoluted to be safely implementable and should be replaced with something else for security-critical applications. (Or in general.)

While this may or may not be true, it's irrelevant to the use of “unsafe” code in Rust. Rust doesn't attempt a compile-time guarantee that your code is simple or bug-free. It attempts to guarantee that mutable aliasing, use-after-free, double free, and resource leaks don't happen. No wire protocol requires such things or is even relevant to them.

Re: A Sad Day for Rust

#860

Post by svick »

velcrovan wrote: post #211
vunie wrote: 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…

Backing up another level...it’s concerning to me when a language relies heavily on single-maintainer libraries for commonly needed functionality. If actix-web was this important, it should have been adopted by the community before now. Maybe languages need a way of setting the expectation to that if your library becomes essential to the community (and if licensing allows) the core developers are going to fork it and…

I like the direction .Net is attempting to go here: there is a foundation and if you want your project to be taken seriously, you should join it. You still get to maintain your project (mostly) the way you want to, but if you stop maintaining the project, the foundation will take over.

(.Net is probably not unique in this regard, but it's what I'm familiar with.)

Post reply on HN