Live data from Hacker News

A Sad Day for Rust

words.steveklabnik.com

271–280 of 1001 posts

Re: A Sad Day for Rust

#271

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…

Agreed. I think there is quite a lot of entitlement on the internet and as Klabnik pointed out: on reddit. And while it's definitely a maintainer's responsibility to make their code serve the interest of its users to the best of their ability, fundamental disagreement should result in forks, not vitriol. It's moments like this that I reflect on the past and the public and virtual forums I have participated in... and…

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.

Re: A Sad Day for Rust

#272

I understand maintaining open source is a lot of work and why someone might want to call it a day - but this is probably the least professional way someone could do it. People depend on this software. It is inconsiderate to just move it to private instead of taking the time to hand it off to someone else. I'm 80% through building an API using actix-web. Time to reassess whether or not I should start over - wonder wha…

You don't get to invoke professionalism, or lack thereof in regards to some individuals work they've made available for free. Open source gives you access to source code to do with as you please. Storing your own copy is a good idea if it's something critical to your endeavors. The possibility of having to maintain anything of that nature yourself is always a risk. Expecting, demanding, or begging for anything except…

Yes I do.

I used to lead a volunteer organization. I had many people depending on me for what I provided. Eventually, it became too much and I needed to step down.

A) I could have just left, let the organization collapse on itself, burnt every individual, organization and volunteer that depended on me - and just said, "doesn't matter was a volunteer organization."

B) I could have taken the time to ensure that there is a system in place such that the organization stays afloat, supporting the individuals, organizations, volunteers that are dependent upon it while it finds a new leader.

Either of those choices were mine to make - but I wouldn't be surprised at all if someone called me unprofessional if had picked A.

Re: A Sad Day for Rust

#273

Earlier quoted context omitted.

> Why is the maintainer responsible for that? It just seems to me that there's a give-and-take to being the maintainer of a popular open source project. You get help on the project in the form of people contributing patches, right? Doesn't simple human curtesy and a modicum of wisdom suggest that you should explain your rationale in accepting or rejecting them, to manage expectations, so that it doesn't end up like t…

And this is why I honestly don't ever want to release an open-source project. At the very least, I'm not going to make it easy for people to contribute. I'll keep the git repo private, go without a ticketing system, and just post tarballs full of code on a self-hosted website (I guess like the NetHack team used to do before 3.6, but they had a ticketing system, and I wouldn't). Maybe I'll even use a non-free license…

Why? I mean, if you're that hostile to collaboration, why not just keep it closed source and maybe try to charge for it?

Re: A Sad Day for Rust

#274

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…

My viewpoint is as follows:

1. Just because a thing exists, does not give you the absolute moral right to criticize it, especially in a way that is toxic for the person or persons that created it.

Criticism affects both the people criticized and the community/universe at large, and not always in positive, productive ways.

2. Just because a thing is free, does not grant the thing or its creator absolute immunity from criticism.

Things that exist have an impact on communities or the universe in general, and people are going to be affected. And not always in positive, productive ways.

1 and 2 can both be true, and I think they are both true.

There is a judgment call involved as to when criticism is unfounded, unproductive, a distraction, and/or outright toxic, just as there is a judgement call involved as to when a thing’s existence in its current form is a net negative.

You are not wrong about user entitlement being a problem, as noted by #1, and you are not wrong in a commercial sense about maintainers not owing any one person anything.

But as per #2, I do not believe that is an absolute blanket injunction to never have an opinion about their choices or about the net positive or negative effect of the existence of the thing they maintain in its current form.

Re: A Sad Day for Rust

#276
post #155

Earlier quoted context omitted.

Of course you can criticize, but people are continuously demanding things, like "he should have labeled it as a toy project", "he should have given reasons why he didn't accept the patch", etc. And Drew is very right to say: No, he didn't have to do any of that.

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.

Maybe. The main issue I see with github is that it's impossible to disable pull requests there. We have that issue in the coreboot project, which uses github as a read-only mirror.

Maybe we should just shut that down to make clear that coreboot is not part of the "GitHub community".

Re: A Sad Day for Rust

#277

> Can we reject the idea of a BDFL? Can we include as many people as possible? Can we be welcoming to folks who historically have not had great representation in open source? Can we reject contempt culture? Can we be inclusive of beginners? I feel like in any language, beginners are more than encourage to write things in said language. Yet when working on language internals, you need to be more careful. Reading the F…

> I stopped using it the moment one of their CEOs altered someone's comments during the election and was not asked to step down. That CEO is still there.

That was not a CEO but a founder, AIUI. Can't really fire them or ask them to step down, they literally own the place.

Re: A Sad Day for Rust

#278

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…

> 1. YOU are responsible for your dependencies.

This is an understatement.

I work in regulated environments where a software error has consequences. Dependencies must be vetted. If we end up relying on a dependency with known vulnerabilities the auditors are going to want to know what we did to mitigate the risk of this out-come. You need to have an answer for that question.

I recommend packaging your upstream dependencies. That way you can patch vulnerabilities you find and ship those fixes today before those patches make it up stream. That's a risk mitigation strategy and often good enough to fend off auditors.

Many (all?) open source licenses provide the software without any warranty or guarantee of merchantability or fitness for use. None. At all.

Re: A Sad Day for Rust

#279
post #252

That's okay, Rust should never be used for web anyway. I don't like the idea of Rust, C, C++, or Assembly for directly web-facing services. Any non-GC language should be a non-starter. There are literally (uncountably?) infinite ways you can have memory errors in a native program. The consequences of any of these can be devastating because absolutely anyone can access your endpoint. Notice the asymmetry: One small, u…

Depends on how you define web. IOT should be done in low level languages. but yeah I agree that a REST server is better of in something like GO, C#, or JAVA.

Re: A Sad Day for Rust

#280

Earlier quoted context omitted.

The community's response might be valid if it were limited to that. But, quoting TFA, they went beyond that. "It’s extra nasty this time. Some people go far, far, far over the line." When someone polite says this, I picture some of the nastier attacks on the internet - doxxing, death threats, and swatting.

In this case it meant people saying things like "you are bad and you should stop writing rust, forever" possibly with some more colorful words in there. Very hurtful things but at least not threats and actions...

If someone poorly implements something, potential causes harm in doing so, doesn't accept that they have done so poorly and express a desire to learn and improve in future endeavors, it isn't even necessarily incorrect to express that they may not want to pursue that particular field anymore. Of course it should be done tactfully which I doubt most of the comments on Reddit did. I see this same sentiment expressed fairly often on HN in usually but not always more polite terms.
Post reply on HN