Live data from Hacker News

The Rust project has a burnout problem

jyn.dev

241–250 of 258 posts

Re: The Rust project has a burnout problem

#241

Earlier quoted context omitted.

> " Westerners are struggling hard with this [...] it's the easiest thing in the world " But why pride yourself on taking the easy way out? It isn't being honest and direct and straight to the point, it's a power move being deliberately rude/offensive/cruel hiding behind "just being honest and direct". Which only works as long as you have the power behind the powerslam putdown (in a personal project you do) and can d…

> But why pride yourself on taking the easy way out? Meaningless question. I can prove that to you by turning it around: why choose a harder path? What is to gain? You only lose mental health. Having to grind my teeth and not telling someone they're being an arse is bad for me. > It isn't being honest and direct and straight to the point, it's a power move being deliberately rude/offensive/cruel hiding behind "just b…

> "Nowhere did I even implied I want a "bouncer" or that he/she must be "shouty". Stop projecting (4th time now)."

You gave an example of calling someone a dickhead and telling them to piss off, then said "I firmly believe all open-contribution projects need a Linus type of person", someone who will "be a bit of a dick when necessary"; if that isn't describing a "bouncer" role ... what is?

I'm not against showing people the door, I'm against the needlessly provocative and rude Linus style of doing that. You say "Meaningless question. I can prove that to you by turning it around: why choose a harder path? What is to gain?" then you say "I can protect people from my bad moods and bad days. I expect all people I interact with to do the same" - so I can ask the same question back - why choose the harder path when doing that? What is to gain? Obviously you can see it when it suits you, the intangibles of higher standards, trying to build something which is better than dog-eat-dog, might-makes-right, rudest-wins, flamewars everywhere world.

> "No idea why you fixated on me as some sort of an enemy but you have aimed wrongly. Severely so."

As I said repeatedly, you can run your personal project however you like, but you are here in a Rust discussion arguing that Rust shouldn't have problems of coordinating with people because you find it easy to swear at people and get rid of them, and all projects should be run like that. I am arguing against that.

> "The hell are you even talking about, and even bringing class / accent / nationality to the picture? It seems you just wanted to get stuff off of your chest and I was a convenient target. You're not even talking to me, again, you are talking to some fictional guy who does not exist."

I'm talking about the programmy world culture of "piss off dickhead, RTFM noob, I can say that because Linus did!" which permeates too much software development world. It's mistakes of correlation and causation thinking "Linus is clever and that excuses his bad behaviours, I'm clever so that excuses me behaving the same way" or "If Linus is successful and rude, if I'm rude I will be successful" or "If he can get away with it, I should be able to". Those patterns drive a kind of filter which is not meaningfully different from any other filter based on or only "the right people" can be involved - race, class, wealth, etc. being the traditional ones, and rude/smart/technical male being the common one in this scope.

Encouraging projects to be run that way, saying all projects should have someone being rude to people, is objectionable for similar reasons that the others are objectionable.

> "You conflate a very classic case of "fear of missing out" with "showing rude a-holes the door"."

And you conflate a case of "showing rude people the door" with "here's a place I can abuse people and get away with it, which is a good thing". This is showing a rude person the door without invoking flamewars (@dang): https://news.ycombinator.com/item?id=39037519

I'm not saying you have to behave like dang, I'm saying nobody is going to be quoting dang's epic flame putdown win over THIS asshole like people do with Linus' newsgroup posts, and that's a good thing.

Re: The Rust project has a burnout problem

#242
post #156

Earlier quoted context omitted.

Wow a lot of people have very strong feelings about this. Parent comment is fine but some of the replies are quite out there, calling this "arrogant" and "dumb". Let me provide my own opinion. IMO content over style. Nobody owes you adherence to a particular set of rules, nor do they owe you their thoughts at all. If the writer's style is a bridge too far for you, kindly just close the tab, don't complain about it. C…

> Nobody owes you adherence to a particular set of rules, nor do they owe you their thoughts at all. What the hell? English has rules. If those rules aren't followed, it makes communication needlessly more difficult. This isn't just a typo we're talking about. This is someone making a deliberate choice to be harder to understand because they see it as quirky and cool.

It seems to be something new generations are increasingly doing. I remember someone saying that he was texting with his gen-z child, and the child felt like properly capitalized sentences sound like they are formally chiding you. I've learnt to mirror whomever I'm talking to (e.g. on Slack at work).

Re: The Rust project has a burnout problem

#243

Earlier quoted context omitted.

I mean ... https://news.ycombinator.com/newsguidelines.html > Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.

No capitalization is not a tangential annoyance, it is a major complain akin to complaining about a text written in one block (without anything distinguishing sentences and paragraphs from each other).

i strongly disagree and i think you do too.

whichofthesesentencesdidyoufindeasiertoreadhowcouldyoueventhinkthatinthefirstplace

Re: The Rust project has a burnout problem

#244

Earlier quoted context omitted.

Because the known system effect means that the more arbitrary developers engage with them, the more likely it is that at least some of them will drive corporate adoption and, by extension, sales. Tailscale put it well: https://tailscale.com/blog/free-plan > increased word-of-mouth from free plans sells the more valuable corporate plans

Why is it a given that GitHub slowing me down by making me engaged with the site more, will make me spread more word of mouth/etc? Everyone in this thread is just assuming a link here, but I don’t see it at all. GH annoys the shit of me by making me click more shit to get my job done, it “increases engagement”, and then… what exactly? My annoyance is supposed to lead to me… thinking about GitHub more? And thus I’ll p…

I think you misunderstand me.

I'm not saying MSFT is intentionally frustrating you to increase sales.

But that, where engagement drives sales, your frustrations are disregarded.

They are different links.

MSFT could easily build a toggle to disable PRs (default, enable PRs). They have these toggles for all other features already.

They don' build this, because, as many other commentors point out, the few people that would benefit from such a toggle, don't outweigh the amount of engagement, data, and usage it generates.

I merely take that a step further: there are quite certainly many features disregarded or not even conceived that would save a (small) group immense effort. Simply because MSFT has done the excel-thingies and knows that features that make people visit GitHub less often, are not positive to their sales.

Re: The Rust project has a burnout problem

#245

I'm a game dev at a small studio. I have a discord full of gamers who all want me to do something or at least pay attention to them. Every time I release something new, someone hates it. It was hard for a bit, but I've been doing this for years. Honestly you just gotta tune out the noise and prioritize what you want. Open source project is a bit harder because you have to collaborate more than I have to collaborate w…

There's little I hate more than watching game devs engage with and respond to vitriolic fuming. Communities try so hard to tell people not to shit on devs, to be polite, to engage calmly and rationally, and then a certain subset of devs see a shitty, cranky post or comment getting attention and just can't help but weigh in to defend themselves. I understand the temptation, but it's deeply frustrating to see.

I'm pretty hard on the gamers. I'm a dad now and most of the gamers are like 13 year old boys. So I try to teach them life lessons and I give them real consequences. I'm not very sensitive to negative feedback.

Re: The Rust project has a burnout problem

#246
post #244

Earlier quoted context omitted.

Why is it a given that GitHub slowing me down by making me engaged with the site more, will make me spread more word of mouth/etc? Everyone in this thread is just assuming a link here, but I don’t see it at all. GH annoys the shit of me by making me click more shit to get my job done, it “increases engagement”, and then… what exactly? My annoyance is supposed to lead to me… thinking about GitHub more? And thus I’ll p…

I think you misunderstand me. I'm not saying MSFT is intentionally frustrating you to increase sales. But that, where engagement drives sales, your frustrations are disregarded. They are different links. MSFT could easily build a toggle to disable PRs (default, enable PRs). They have these toggles for all other features already. They don' build this, because, as many other commentors point out, the few people that wo…

> They don' build this, because, as many other commentors point out, the few people that would benefit from such a toggle, don't outweigh the amount of engagement, data, and usage it generates.

That makes no sense. Say I'm an open source project maintainer who doesn't want PR's in my repo. I have to continually log in to GitHub to check the PR tab and close all active PR's (or as others have pointed out, use a bot to do this, but that's beside the point: The discussion is about why this isn't a built-in feature.)

What value does Microsoft get out of the "data" generated by me having to continually log in and close PR's? "Yup, people who don't want PR's on github log in a lot to close them". Why is that valuable? We keep talking about engagement as a thing but nobody's explaining why it matters at all for MS. "Engaging" me by forcing me to open up the website to do mundane stuff doesn't move any of MS's needles. "Usage" goes up only because I have to keep doing this mundane shit.

Here's a VASTLY more likely reason why MS doesn't want to make it easy to disable PR's: Lock-in. Microsoft wants to encourage users to use GitHub for everything involved in software engineering, end-to-end. Because if you do so, leaving GitHub becomes a lot harder, because GitHub has your PR history, your issue history, and is hosting your wiki, etc etc. This is not the same thing as "engagement", it already has a term, and that term is "lock-in". (Apropos: I consider PR discussions to be indispensably valuable in finding out why some particular line of code looks like it does: Finding the PR that introduced it and looking at the discussion is a great way to find out the motivation of the original author.)

MS does not like users that purely use GitHub as a mirror and don't use any of the GH-specific features, because those users can trivially migrate their code to another hosting provider if MS ever decides to do something silly like charge them.

Engagement makes no sense whatsoever as a motivation to not let users disable PR's. Lock-in makes perfect sense.

Re: The Rust project has a burnout problem

#247
post #207

Earlier quoted context omitted.

It's more like "let's improve on C by catching errors C compilers don't check." Rust took a lot of inspiration from Cyclone, which was meant to be a safe version of C. Writing C makes certain classes of sloppy assembly bugs unwritable, like accidentally using the wrong calling convention, forgetting to preserve a register, or forgetting to pop something off the stack. Similarly, Rust makes classes of sloppy C bugs un…

The attack is the idea that everybody needs to have the same priorities that Rust has and so everybody else is wrong. With regard to memory safety, this even something I could partially agree with, but then there is another problem: In contrast to Cyclone, which was a safe version of C, Rust changes a lot more than simply adding memory safety features. It is not at all like C but has completely different syntax, diff…

[deleted]

Re: The Rust project has a burnout problem

#248
post #207

Earlier quoted context omitted.

It's more like "let's improve on C by catching errors C compilers don't check." Rust took a lot of inspiration from Cyclone, which was meant to be a safe version of C. Writing C makes certain classes of sloppy assembly bugs unwritable, like accidentally using the wrong calling convention, forgetting to preserve a register, or forgetting to pop something off the stack. Similarly, Rust makes classes of sloppy C bugs un…

The attack is the idea that everybody needs to have the same priorities that Rust has and so everybody else is wrong. With regard to memory safety, this even something I could partially agree with, but then there is another problem: In contrast to Cyclone, which was a safe version of C, Rust changes a lot more than simply adding memory safety features. It is not at all like C but has completely different syntax, diff…

It's true, not everyone has the same priorities, and Rust may not provide the right set of tradeoffs when one is deciding which language to use. I don't believe that C is strictly inferior to Rust. There are cases where it's not worth trying to use Rust instead of C.

Unsafe Rust is more complex to use than C in some ways. For example, an iterator for a slice, which contains two raw pointers, relies on the lifetime of the array it refers to lasting longer than the slice, and to encode this you need to use PhantomData [1]. Things like this make it look more arcane than plain C, simply because in C, this is implicit, and on the programmer to enforce.

[1]: https://doc.rust-lang.org/nomicon/phantom-data.html

Re: The Rust project has a burnout problem

#249
post #243

Earlier quoted context omitted.

No capitalization is not a tangential annoyance, it is a major complain akin to complaining about a text written in one block (without anything distinguishing sentences and paragraphs from each other).

i strongly disagree and i think you do too. whichofthesesentencesdidyoufindeasiertoreadhowcouldyoueventhinkthatinthefirstplace

i said sentences and paragraphs not words not having punctuation is absolutely akin to not capitalizing after all new lines and dots are designed and are working together and in unison to when combined convey the important information information of separation of pieces of information ways of compartmentalization if anything capitalized words are more visible than dots

Re: The Rust project has a burnout problem

#250

Earlier quoted context omitted.

> But why pride yourself on taking the easy way out? Meaningless question. I can prove that to you by turning it around: why choose a harder path? What is to gain? You only lose mental health. Having to grind my teeth and not telling someone they're being an arse is bad for me. > It isn't being honest and direct and straight to the point, it's a power move being deliberately rude/offensive/cruel hiding behind "just b…

> " Nowhere did I even implied I want a "bouncer" or that he/she must be "shouty". Stop projecting (4th time now). " You gave an example of calling someone a dickhead and telling them to piss off, then said "I firmly believe all open-contribution projects need a Linus type of person", someone who will "be a bit of a dick when necessary"; if that isn't describing a "bouncer" role ... what is? I'm not against showing p…

> if that isn't describing a "bouncer" role ... what is?

I still wouldn't call it a bouncer; I'd call it a moderator who is not afraid to tell people off.

> I'm not against showing people the door, I'm against the needlessly provocative and rude Linus style of doing that.

If you read my other sibling comments you'll see that I partially agree. To me swearing is unnecessary; if somebody is crossing lines I'll just try and quickly chase them away. I guess for others cursing is one vehicle through which to achieve that.

> As I said repeatedly, you can run your personal project however you like, but you are here in a Rust discussion arguing that Rust shouldn't have problems of coordinating with people because you find it easy to swear at people and get rid of them, and all projects should be run like that.

I see where the disconnect lies now. I haven't argued about how should the Rust project be ran at all. I got off on a tangent that was borne out of my disdain for the "being too nice" thing I am noticing in many Westerners. As a former bullied kid I understand better than many that never retaliating even a little encourages bullies. So in my eyes not showing some teeth just furthers the having a-holes problem.

> I'm talking about the programmy world culture of "piss off dickhead, RTFM noob, I can say that because Linus did!" which permeates too much software development world.

An assumption on your part is that I am imitating / emulating Linus. I don't. I simply understand what it is to have to read and listen to the same BS every day which is taking away from your time, energy and motivation to do what you truly love (in his case: kernel development).

If Linus did not exist I'd be 100% the same person in open-source contribution discussions.

> Those patterns drive a kind of filter...

Yes and that's a good thing. I don't subscribe under the "inclusivity at all costs" ideology. Are you?

> Encouraging projects to be run that way, saying all projects should have someone being rude to people, is objectionable for similar reasons that the others are objectionable.

Why are you so polarizing? I didn't "encourage" any project be run this way. Blindly doing stuff always, no matter the circumstances, is a bad idea regardless on which end of the spectrum you are. I preach for people on the receiving end of toxic (or stupid) posts to NOT shrivel away and strike back whenever necessary.

> I'm not saying you have to behave like dang

Are you not really? I already addressed this. I don't aim to be like him and I already said that I admire people like him. At the same time, I know that having to bottle up certain reactions is destroying my mental health so I simply don't put myself in situations where I have to do it. But I also have plans to start open-sourcing things. And there I know for a fact that I'll just be super cold (not emotional, and won't curse) but would still quickly stop any toxic discourse.

--

Is that the best policy for high-profile stuff like Rust? I can't say. I have witnessed language maintainers engaging in forums and I noticed how some people were EXTREMELY sensitive even to the mildest of "no" answers, very quickly escalating them to "you don't care and your community is full of a-holes" which made me facepalm hard.

I understand they don't want the bad PR. I get that. But I would never want to be in that position. So when I start my open-source projects I'll be like "OK, if you feel that I don't care and I am an a-hole, there's nothing I can do about that. Have a nice life." and will block the person if they keep escalating.

Even if that gives me bad reputation, I absolutely don't care. I get how language maintainers don't want such bad reputation but again and again, I think they overdo do the "be passively polite to the point of being taken for a doormat" behavior.

I ain't telling anyone how to run their projects. But I do have the right to think they're wrong in certain aspects.

Post reply on HN