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

301–310 of 1001 posts

Re: A Sad Day for Rust

#301

Post by steveklabnik »

cle wrote: post #264
stanferder wrote: post #80

Earlier quoted context omitted.

It might not be just reddit though. The author's summary points to a volatile combination of elements in Rust itself: 1) [T]he Rust project saw Rust as more than just the language... 2) unsafe... is a really important part of Rust, but also a very dangerous one, hence the name. If a project is considered to be not just a project, but something closer to a cause, people are going to defend their understanding of that…

> And introducing the language of "safe" and "unsafe" isn't just descriptive, it's a value judgment. It has connotations of recklessness at least, and explicit threat at worst. Is it really a value judgment? Coming from a formal PL background, I had just assumed that the "unsafe" keyword was referring to the PL concept of "safety", AKA "soundness", which has a specific technical definition, and not that it was necess…

You are correct.

That doesn't mean that people will incorrectly interpret it, though.

Re: A Sad Day for Rust

#302

Post by dbcfd »

ddevault wrote: post #38

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.

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 comments by people frustrated with the project, since they had likely invested considerable time at least using, if not more. But this was a situation that is entirely avoidable if Nikolay would have stopped promoting Actix as for production use.

Re: A Sad Day for Rust

#303

Post by derefr »

deng wrote: post #100
dashwav wrote: post #73

Earlier quoted context omitted.

> 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 anything in the slightest. I don't think the anger is directed at there being security issues, the anger is directed at the fact that even when security vulnerabilities where found and patched, there was major pushback even getting those patches merged into the library.…

As a maintainer, it is his choice which patches to accept. If you're not happy with his decisions, choose another project, fork it, or pay someone to do it for you.

Sure, but once you’ve forked, now you have a fork only you use, but which you know is more secure than its upstream for reason X. That’s an unstable equilibrium—you want others to know of your fork, and to switch to it, so that other downstream projects can also be more secure.

Adding to this, you might still transitively depend on the upstream through your other deps in ways you can’t change without either forking all your deps... or getting them to switch.

And what does “getting the ecosystem to switch” look like? It looks a lot like complaining about the upstream, such that others in the community understand what the problem is that your fork is solving.

Re: A Sad Day for Rust

#304

Post by zelly »

Grue3 wrote: post #242

I remember when people were claiming Common Lisp community is toxic, but I find that it is the languages which tend to focus on "building community" with Community Managers and Codes of Conduct that end up becoming truly toxic cesspools in the end. See also node.js. The focus on community attracts people who aren't interested in programming, but rather those who want a playground for gaining clout and trolling. You n…

Primates tend to attack each other out of envy when they become too similar and all behave the same exact way. They look to find someone to crucify to get rid of the angst built up from being too similar to the next person.

The Common Lisp community was pretty much the opposite of the Node/Rust crowd. Everyone was different. Lots of people were using different implementations of CL. Most people even had their own custom editors. And of course everyone had their own DSL of macros they carried around with them, so basically everyone had their own language. The supposed toxicity of the CL community was from the constant arguments because they all had strong opinions different from each other.

If this were the CL community, there would be 20 different versions of actix-web or something like it. There would be no need to create drama and make whiny demands of other people, because everyone in CL actually knows how to program.

Re: A Sad Day for Rust

#305

Post by krn »

disintegore wrote: post #202
endothrowho333 wrote: post #122

Earlier quoted context omitted.

The above was from personal experience and observation from having been a part of many online communities -- pre-dating reddit -- in all ways including: here-and-there member, first-hand maintainer and manager, and antisocial member causing a ruckus. Armchair psychology? No, I've made many friends and acquaintances, both online and in real life. The ones that bubble around posting online heavily, have developed antis…

If I understand correctly, your anecdotal evidence is what makes this not "armchair psychology"?

What's wrong with simply sharing personal observations based on the decades of related personal experience? Anyone who has some training in science has learned to always be looking for patterns.

Re: A Sad Day for Rust

#306

Post by solipsism »

elefantastisch wrote: post #189
ddevault wrote: post #38

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…

Meta-comment: Thank you. Online discussion would be much more productive if everyone clearly laid out the principles on which their viewpoint was based. Fundamentally, there are only a few ways honest people can disagree: Different principles, different information, different interpretation, or just plain misunderstanding. (Meta-meta: This is the principle that I believe and based this comment on.) Much of what makes…

This is a bit Pollyanna. People aren't logic robots that start from first principles and then derive all knowledge from logical reasoning. People are emotional, irrational beings. Those of us who fancy ourselves rational are constantly involved in irrational motivated reasoning helping us maintain that desired worldview.

Not to say we shouldn't try to live up to the ideal you set forth. We should do our best. But there's not some category of honest people among whom you can avoid human nature.

Re: A Sad Day for Rust

#307

Post by kd5bjo »

zpallin wrote: post #137
ddevault wrote: post #38

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…

Actualy, it’s the maintainer’s responsibility to make their code serve their own interests. Those often, but not always, align with the users’ interests.

Re: A Sad Day for Rust

#308

Post by GrinningFool »

AnonymousPlanet wrote: post #143
manish_gill wrote: post #26

Earlier quoted context omitted.

> No one expects you to write perfect code, but we do expect you to fix flaws when you learn about them. It's not like he was getting paid to work on this, was it? And people do have a life beyond open source. People could have forked and worked on the issues themselves, but that's asking too much. Why do the hard work when you can just write a comment/tweet blaming someone else, right? Your comment is precisely what…

> It's not like he was getting paid to work on this, was it? That is completely beside the point. Do the Debian maintainers that were responsible for famous security slipups regarding SSH keys got paid? No. Would the backlash if they had been unwilling to fix the issues been warranted? Absolutely. Once you are a part of people's infrastructure and these people rely on you to not be irresponsible, you can't afford to…

    > Open source is not some backyard game anymore. It 
    > involves companies and their commitment in form of 
    > infrastructure and participation.
I think this approach leads to sustainability problems, and discourages individuals from sharing their work in open source form. I make a project because I need it, and maybe it's fun to build. I generally share it because I think others might find it useful too.

What I'm reading in your comment is that once it becomes widely used, it becomes my responsibility to meet the needs of these people and organizations who have started using the work I freely give to them. The act of having it used by other people obligates me to them.

That perspective seems like it will eventually force the people who share their work in this way down the path of burnout.

    > Open source is like capitalism. But a project's success 
    > is measured in commitment instead of capital.
I would argue that the goals of any given open source project - and therefore the measures of its success - are under the control of the owner(s) of that project. If one of the goals is to make a widely distributed and used thing, then yes - there are obligations such as you've described; they are inherent in that goal.

If the goal is only to build a thing and share it, there can be no such obligation - regardless of how popular it gets.

Re: A Sad Day for Rust

#309

Post by stanferder »

cle wrote: post #264
stanferder wrote: post #80

Earlier quoted context omitted.

It might not be just reddit though. The author's summary points to a volatile combination of elements in Rust itself: 1) [T]he Rust project saw Rust as more than just the language... 2) unsafe... is a really important part of Rust, but also a very dangerous one, hence the name. If a project is considered to be not just a project, but something closer to a cause, people are going to defend their understanding of that…

> And introducing the language of "safe" and "unsafe" isn't just descriptive, it's a value judgment. It has connotations of recklessness at least, and explicit threat at worst. Is it really a value judgment? Coming from a formal PL background, I had just assumed that the "unsafe" keyword was referring to the PL concept of "safety", AKA "soundness", which has a specific technical definition, and not that it was necess…

Points well taken, but I think "unsafe" turns it into a value judgment, especially (as samatman says adjacent) since it isn't necessarily really unsafe.

Re: A Sad Day for Rust

#310

Post by School-Cotton »

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

The set of all computer programs is countable, so I don't think there can be uncountably many ways to have memory errors.
Post reply on HN