Live data from Hacker News

A Sad Day for Rust

words.steveklabnik.com

201–210 of 1001 posts

Re: A Sad Day for Rust

#201

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 the code is "easy" (OK, maybe not based on the other comments), but anyway...

Another (persistent) problem has been the crates.io namespace.

You can fork actix, but then you'll need to come up with a new name for it, and then educate the wider community of that. It is a big hassle, and slows adoption.

Adding onto the issue is that crates.io does not (yet) support the username/projectname naming scheme as on github and other popular code repositories. So it isn't enough to just people to go to a different username, you must use a new project name.

Re: A Sad Day for Rust

#202

Earlier quoted context omitted.

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…

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"?

Re: A Sad Day for Rust

#205
post #9

I can see where Steve is coming from about the difficulties of maintainer-ship - I only have a few projects that I am actively maintaining and obviously nothing close to the scale of a popular library. But at the same time I really think almost all of the blame in this case rests solely with the reception (or lack thereof entirely) of PRs/issues that are intending to improve the quality of a library that many people…

The problem is that people didn't choose Actix only for performance. I personally haven't used Actix, but it seems that all other contenders were lacking in some way, not only performance but also feature sets and flexibility and easiness. And thus we are now left with a horde of safe but otherwise lacking libraries instead of what could possibly be the best of breeds.

Well a lot of the reason other rust web frameworks were lacking was that actix-web was so dominant in the space. If the actix-web project is indeed dead, some other projects (such as warp/tower) will get more attention and hopefully become more feature-complete.

Re: A Sad Day for Rust

#206

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…

Thank You, you nailed it. There are always a high chances of being heavily downvoted on HN every time the question of entitlement comes into discussion. So I am glad this is the top reply at the moment.

And I think that is the problem I have with this blog post, It reads to me as trying to spin it as something else with anxiety or Reddit, when what I see the problem is something very different based on principles and values.

Re: A Sad Day for Rust

#207
post #58

I think the Rust compiler should write as its final log message "Resulting binary contains x bytes of unsafe code" (or something similar). That way, people are constantly reminded that their code depends on unsafe code, and they can try to reduce that with visible results.

You can use cargo-geiger to figure out whether a binary is going to depend on problematic unsafe code.

Re: A Sad Day for Rust

#209

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…

When you write "... the Rust project saw Rust as more than just the language. The community and the people mattered." I have to ask why anyone thinks this isn't true for ANY code/stack/dep out there?

When I evaluate a technology for its appropriateness I first look at who's using it: Literally "Who are these people and what are they working on with this stuff?" The answer to this question determines more than 80% of the decision on whether the thing is going to be my choice.

Rust seems to be being used most by people who are interested in blockchain and crypto. They tend to be of a near monolithic ideological caste, too, which has its own problems. Do I want to get into a situation where I might have my hat in my hand with these folks? Not really.

(also the rust compiler is so slow I cannot believe it)

Re: A Sad Day for Rust

#210
I cannot help but to think there are deep parallels between software projects and any good old company. Dealing with a group of people around an "idea" is far from easy.
Post reply on HN