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

Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

gist.github.com

Post reply on HN
Print view View original

221–230 of 245 posts

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#221

Post by stormbrew »

jasode wrote: post #220
stormbrew wrote: post #214

Earlier quoted context omitted.

While that's true, do you think maybe a few things have changed about the nature of coding or open source in the intervening 30 years ? Anyways, I'll ignore for the moment that your argument wasn't actually about linux in 1991, since you used an example from 2014 and said that people continue to contribute, implying that you think recent friction is relevant, because either way it doesn't hold water. Even by 1995 Lin…

> argument wasn't actually about linux in 1991, since you used an example from 2014 and said that people continue to contribute, implying that you think recent friction is relevant, No, my argument was about the entire timeline of Linux kernel which was a continuation of gp's (xyzzy_plugh) example when he wrote: >Take a look on LKML, or Git's mailing list, or on any serious project from the last 20 years. I just pick…

Linux hasn't been a "toy project" compared to alacritty since maybe like.. 1992? I got my first CD-ROM with linux on it (yggdrasil) in 1993 or 1994. The scale difference here is so massive, even going back quite far.

I think you're really underestimating the rapidity with which linux grew, as well as the pure cachet that linux (or any project associated with Linus, like git) has and has had for most of its existence that makes it fundamentally different in terms of motivation and appeal from basically any other OSS project.

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#222

Post by DannyBee »

abstract_put wrote: post #210
DannyBee wrote: post #186

Earlier quoted context omitted.

Yeah, that's the party line for sure, but the end effectiveness of waiting until "it's okay for release" is low. You will never reach that point. Most experimental branches basically see no use outside of who is developing them. So a lot of time you are only really getting them to the point they pass existing tests, and maybe whatever additional testing the person writing the code is doing. As a result it's really ra…

Acknowledging my bias towards correctness first (or a harness for explicitly experimenting), I think your step 3 ("3. Fix and iterate it") is rarely ever done and that absence puts people off. In the corporate environments I work in, the PR sets the standard for what is acceptable and there's vanishingly little motivation to fix anything that isn't blowing up a high profile client. Basically mini tragedy of the commo…

My bias is from watching a lot of smart people experiment well.

I think you are not wrong in the limit, but it's a bit more complex than that:

1. You need to set expectations up front of what it means to contribute.

2. You need to be willing to spend time to help ensure people know how to iterate it, etc. Check in with them, etc. We often expect people to just figure out what you want or be completely self-sufficient. Especially with folks who have never interacted with your project, how could they possibly know how to do it well? We often motivate (positively or negatively).

But we often suck at training people at things they aren't used to. Training goes a long way. etc

Again, this will never work 100% of the time. You will find people who in fact, will just want to get it in and run away. I'm just trying to get that percent to say 5-10%, rather than 80% :)

I agree with the aspect you see - people are not always willing to trust. This often turns into "you are all helping me with my software" rather than "we are all working together to produce software". In practice - the process i gave is also one of the only good ways i know to build long term trust and contributor relationships. You trust them to work on their code once added, and to care. They trust you to help them. That is how you start to build good team relationships. They will be good at things you are not, you will be good at things they are not.

I'm not sure how you ever build a trust or community relationship if you say "i don't want to trust you to do anything, please drop it on me in a perfect state so i don't have to trust you"

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#223

Post by DarylZero »

purple_turtle wrote: post #189
couchand wrote: post #105

Earlier quoted context omitted.

I've found Rust programmers to be eminently pragmatic. The economics of bugs have been clear for decades: it is orders of magnitude more expensive to find and fix bugs after they've been shipped.

And, additionally, if someone is unwilling to fix known issues in PR - then they will definitely not fix bugs in it after it become merged. So for maintainers merging PRs with known issue is basically promising to fix everything not finished.

To the contrary, a developer is MUCH MORE likely to fix bugs in merged code that has users, than in an unmerged PR.

It's the users that give motivation to work on the project. Working on a PR is like working on spec. Working on the development branch gives you direct access to the "payment" of users using your code.

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#224

Post by oconnor663 »

> If you feel like the goals of Kitty are more aligned with your personal preferences, why not support Kitty, it's a great terminal emulator.

For what it's worth, I think this is an incredibly healthy attitude for a project maintainer to take. There are a lot of ways to go wrong managing a software project, and this attitude is a good way to avoid a big subset of common mistakes. It comes with downsides, of course, but it's important to think about the upsides too.

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#225

Post by atoav »

brabel wrote: post #45
rtfeldman wrote: post #28

Posts like this are major contributors to maintainer burnout. Whatever value they have as a signal boost is a rounding error compared to the harm they cause to individuals as well as to the culture as a whole. Please don't ever post things like this. If you're this frustrated that the people who make free things for you aren't donating their time to you in the way you'd prefer, grab a drink with a friend and vent to…

As I maintainter myself, I completely disagree. It's a fair complaint that everyone contributing to open source will eventually suffer from. > Please don't ever post things like this. What the hell, is this against any HN policy? Or you think no one should post their point of view here if it's against yours? EDIT: I think it's important to note that burnout is a result of you having an issue within yourself (at least…

> I think it's important to note that burnout is a result of you having an issue within yourself

I think this is an oversimplification. You can be perfectly happy with yourself, but if your environment creates a neverending treadmill of situations that drains your soul, you will get burnout if you cannot find any mechanism to cope with it, to avoid it or to deal with it.

And in open source we are each others environment. If you have 100 well researched issues written in a friendly tone you will certainly feel a different motivation to tackle that backlog than if it are 100 toxic spitting well-researched issues. The same goes for how we talk about each other in public. If you think a PR should have been merged, just talk to the maintainers in a non-public setting (Chat or whatever) and explain why you want it merged, what you would be willing to do for it and how they could see this happen. If they still don't like to do it, just fork it and do it yourself.

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#226

Post by antihero »

the_gipsy wrote: post #165
antihero wrote: post #51

Ha, trying to get Alacritty to have a native-feel icon for macOS which had basically zero drawbacks and most other applications do was met with a straight up NOPE. Not up for debate, people supplied the assets and I even made a PR, nope, closed. Even though it was in a directory full of platform specific stuff (Alacritty.app resources), it was decided that it couldn't differ from the other icons, so Alacritty has to…

How many other non-apple apps “stick out like a sore thumb”?

Currently the only other ones are Firefox and Focusrite Control.

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#227

Post by coldtea »

nixpulvis wrote: post #114
coldtea wrote: post #97

> Let's look at another project, alacritty. Don't we all remember it? It was supposed to bring Rust to the mainstream Linux desktop. It was supposed to be the new standard tty. It was supposed to be a revolution, shaking the foundations of the Earth No, it was just supposed to be one of the many projects with ambitious goals, that more often than not, go nowhere, and are abandoned a few years down the line... If you'…

You sound like you speak from experience. What makes for a project's success then? Is it the leadership? The raw motivation? How do you facilitate interest? Where are the developers and productive users coming together to talk? I ask because I don't know how long I've really been on "the scene" myself and I do truly still feel there's something special about projects like Alacritty and Rust. When I look around and co…

>What makes for a project's success then?

I've seen a few factors play an important role:

(a) dev's persistence - many projects come with grandiose goals, go some of the way, but the dev loses interest after 1 year or so and abandons them.

(b) good marketing - many project are good and maintained well, but just don't market themselves nicely. A nice landing page, examples, documentation, screenshots, and even some superficial stuff like a nice logo and icon, all play quite a role in the success of one FOSS over another. It's not enough to welcome users/contributors, you also need to make yourself known well.

(c) solving a unique need (this is not necessary - e.g. you can be "just another editor" and do well - but it's a big bonus if you have that.

>I ask because I don't know how long I've really been on "the scene" myself and I do truly still feel there's something special about projects like Alacritty and Rust.

About Rust yes. It has proven itself, shipped code in major companies, got books, wide adoption, even interest from Microsoft, Facebook, and others.

Allacrity, I'm not so sure. A lot of big early claims, but still nothing special to write home about.

It's also that Rust solved a real problem (memory safe, close to the metal, modern language), whereas Allacrity is just one of many terminals.

And nobody really thought "what I need is a secure terminal" - as if terminals are a big security issue. A faster terminal sure, but there are several plenty fast terminals, with GPU support and everything.

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#228

Post by lamontcg »

xyzzy_plugh wrote: post #39

> So, here we are in 2020, and nix#864 remains unmerged. Fred, you say, you overreact. I read the entire PR. I _want_ to agree with the author, but I didn't find this reasonable. The feedback, for the most part, was not about being perfectionism. Not remotely. It's about being correct . This is not unique to Rust, which as a language spends a lot of time being correct in a few dimensions, but pretty traditional. You…

Yeah this is an open-source problem.

Contributions are very often scratch-my-own-itch bugfixes that don't consider other users or the project at large.

It is easier in projects that are greenfield where there's few existing users and a more cowboy attitude toward getting any code accepted to move the project forward.

In mature projects that have lots of complicated requirements and external APIs that can't be broken it becomes extremely hard for external contributors to be successful because contributing becomes something that resembles actual $DAYJOB work that people get paid for. Which is a lot of sitting around for hours thinking of ways that the simple and obvious solution is poor and needs to get tweaked, then hours of sadness over breaking existing tests and refactoring the whole idea until you boil it down to something which is often quite a lot of work and may fix many problems outside of the initial scope of the issue, spread over multiple pull requests.

That is what software development in a mature codebase looks like, and its not something that is fun and something that people usually want to get paid to do.

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#229

Post by lamontcg »

andkon wrote: post #144
DannyBee wrote: post #134

Earlier quoted context omitted.

"As an open source author and maintainer, I think you're looking at this from the wrong way around. Good contributions are not the norm, they're the exception, " I've contributed to hundreds of projects, and maintained a ton, so i feel this pain, so please take what i say in that vein :) The question i usually ask when i see this is: "What is the thing you did that you think should have caused people's behavior to ch…

Wowwww this is lovely! Have you written anywhere about what you've done on the projects you've maintained along these lines? I think we'd all benefit from hearing more about what you can do in a project to make contributors more capable and helpful. After all, it seems like their incentives should align? Like, why wouldn't they want to make a contribution that actually helps? Making that easier to actually do seems l…

A lot of the time making a contribution that actually helps means fixing something foundational rather than bolting on another quick bug fix.

That takes work, sometimes quite a lot of it, and there's no trick around getting the work done any easier.

A lot of contributions to open source are simply worth what you paid for them, which is nothing.

Early in a project it is possible to find areas of the codebase where easy things haven't yet been done because there just haven't been enough programmer-hours done yet to burn through the simple stuff. Late in a mature project the easy things have mostly gotten done and finding more easy stuff becomes difficult, and as you pull apart simple looking issues they start to look hard.

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#230

Post by maxekman »

rbanffy wrote: post #41
maxekman wrote: post #3

Ah! The “classic” ligature issue. Have been following that for a while. Kind of given up hope that there will ever be any support for it. Edit: punctuation

> The “classic” ligature issue. We try to make our terminals do things no terminal (remember those boxes with a CRT that used to be in a room, then became ubiquitous enough to end up on our desks) ever did, or considered doing. Do I enjoy being able to partition a window without needing tmux? Yes. Do I like text reflowing when I resize the window? Sure. Do I find Tektronix mode useful? No. Do I find it fun? Of course…

Absolutely! And the ligatures is definitely a nice-to-have, not a must. I really enjoy Alacritty and use it every day. The performance is amazing!
Post reply on HN