I think it's about escaping local minima? You can always look at the biggest sink for performance and say "there's definitely something we can do better in there" but unless you have something objectively better to compare it to, you'd never be sure.
Imitation is the sincerest form of flattery. And knowing that of the hard problems you solved, someone else can solve them and in a different language, I think there's quite a bit of value to be obtained just through the competitive process that emerges when there is competition.
You can't fully have competitiveness without an actual alternative to compare yourself against. If the Rust folks can do the problem slightly faster by shaving off just 5% or less of the test suite, what all does that tell us about the theoretical limits of a solution when compared against the canonical version?
I have only limited understanding of the problem space, but I think there's always something intangible to be gained from having a quite similar implementation in a different language.
Yes. It’s also been said (not often enough) “if we don’t compete with ourselves someone else will”. Getting out of one’s own head (and repo) is gold. It shows humility and respect as well as creates innovation and resilience.
https://biomejs.dev/formatter/#differences-with-prettier
Turns out Biome found several pain points that they chose to not follow the same decisions than Prettier, instead diverging from it. This alone could be already a reason why a parallel development is worth it.
Less "the team" per se, and more vjeux, I think.
Presumably the creators of the bounty believe that this bounty is in fact a good way to directly improve Prettier. The acceptance criterion of the bounty doesn't need to literally be "improve Prettier" for the work to improve Prettier.
I think that a lot of projects would be a lot better if they insisted on not solving everything, and stuck to solving one problem well, and instead of merging every new feature on offer instead help make it easier for others to "compete" with them by e.g. separating out shared functionality or writing about lessons learned...
I'd love to find each and every one of my projects are no longer needed because there's a better option (now, I may be very difficult about what is "better", so that's a tall order), because my list of projects I'd like to pursue is longer than I will stand any chance of getting to in my lifetime, so if some are taken off my plate, awesome...
Age for example always has someone complaining about a feature they want - the refusal to oblige is exactly why it's a better product than gpg.
My own experiences with open source suggest that no one would stick around for very long if they were motivated by fame or wealth. Being a FOSS maintainer seems to be a constant exercise in dealing with people whining at you for not fixing their problems for free, not something that brings any significant personal attention and certainly not something that provides a sustainable source of income.
Of course I'd love to learn rust! But, for the most part, I just need to get stuff done so I'd prefer to stick with what I know and can mod easily and leave the "learn an entire new language" part for something that actually needed that language.
Those are the two main things that rust is expected to help improve.
It's quite easy to empathize with somebody that sees a JS software having problem with those two and picking a language that is known to help with those instead of being known to increase those problems.
There are three reasons, I think:
1. Writing a rust compiler is separate from prettier project because of its nature. Prettier is not written in Rust, and Rust has proven to be a robust option to write a formatter, so the goal really is to write a formatter in Rust itself, and it can't be replaced with improving prettier within its current codebase
2. Asking someone to write a Prettier-branded and owned Rust compiler for $20k is not enticing enough. It is essentially equivalent to contracting someone to write some code for Prettier, with an open bid. It would cost a lot more to hire someone to write these code. Great programmer who has the skill to answer this bounty get paid at least $200 an hour (extremely conservative estimate), $20k is enough for 100 hours of work for one person, not enough to finish the project. But getting rewarded for $20k for stuff you write and will own is enticing!
3. Good ecosystem going forward. If prettier owns the winner project, prettier is responsible to maintaining and improving it. The good that the bounty did ends when the project is handed over. Prettier team get burdened with a project that they didn't write themselves, and the original team (the best people for the job) is not incentivized to keep maintaining it. There is no ongoing competition to keep this field active.
Dang! What do you base this estimate on? The Rust aspect, or parsing aspect, or intersection of both?
Being a subject matter expert means that you can be paid well for your work, but the numbers of jobs that require expertise in the Kura-Aras river basin can be few are far between.
I always used 2x, but probably 2.5x is a sensible way to think about it in a patio11 "charge more than you think you should" mold.
This is less true following the Affordable Care Act than it used to be. The unsubsidised marketplace rate for my Kaiser health insurance seems fairly close to what I pay for COBRA from my former big tech employer.
My Kaiser almost doubled from COBRA and coverage went from better-than-platinum to high deductible gold.
Google / SF market.
Age makes a huge difference to the marketplace premiums though.
When I was doing pricing for service contracts it was usually around 1.50:1 burdened billing rate vs direct labor (income)
232/1864 is a base increase of 12.5% for PTO
Payroll taxes, Medical, workers comp, etc add about 30% - though medical is flat so at higher wages like discussed here the % increase it represents goes down further
I did not have to factor in increasing skill on the job or time between jobs - but I did have to account for overhead and g&a which would be similar to time between jobs since those would be for bills
Big companies would have a lot of markup on OH/g&a/fee, but a software dev working remote for themselves on contract could competitively go down to 5-10% or less here to simply cover the minor added burden to bills.
That totals up to about a 50% increase on the salary rate. You can't outright bill someone for time you spend looking for a new job or improving your skills. You may charge a premium that you use to do such things but that would have to go under fee which tends to top out at 15% with the government, not something that can be expected to be accounted for. In my experience at least.
Again though, this was for service contracts - particularly with the US government, subject to certified cost and pricing data disclosures.
I was genuinely curious about the 2.5 number though, as i have spent a lot of time dealing with market rates in various conditions I was interested to know the context. I could see a few ways that could happen, but I wouldn't want to speculate too much
As a datapoint, the average Dutch contracting rates I see for IT development (think: Java, Swift, Kotlin) range somewhere from €75 - €150/h. Higher is possible, but then you're talking very specific expertise and typically shorter projects.
I'm on the hiring side, this is a figure across some 20 external devs. I think it's representative of the middle of the market.
What I'm trying to say, I don't see the correlation between having a huge hourly rate vs family time. 40 hours a week of work is still 40 hours regardless of how much you're paid.
It's not a perfect comparison/analogy, so I'd rather not get nitpicked, as the overall thrust of my argument is that $200/hr is not outlandish imho.
I once had some contractors in my team that were paid $500/hour due to vendor markup. I consider that extravagant.
It varies though, the market also exists for $80/hour java developers, which tend to be new grads
Contract Developers going to technical companies will earn more like $180+.
i have been a contract developer, and have worked at technical companies in canada, and have never seen rates that are even close (and im not a jr / have never used java for work outside of small amounts for mobile.) there's no way these rates are as common as you are all making them out to be, unless it's some niche, or you're talking about extremely short contracts, or there's some other missing piece of context
These rates are at financial services , banks, transportation / logistics, manufacturing, telecom, etc. in Canada, US, and Japan.
You should read patio11's posts on this topic on HN or his website, for example : https://www.kalzumeus.com/2012/09/21/ramit-sethi-and-patrick...
So if you hire an agency to perform a contract, they'll bill you $2000 per day and send you their employee who makes $100 an hour. Agency pockets the $1200 (it's a simplification, but should paint the picture).
Freelancer and agency both run the same business model. If you think like employee and charge extravagantly less, you will never grow.
You should typically charge enough, so that for any given project you could hire an employee to do the work, while you look for new leads or you can keep the money in the company and do the work yourself until you amass enough capital to move up the business ladder.
There's reasonably good data about this that contradicts this?
$1000 as a day rate isn't unusual or unreasonable for a specialist IT contractor; and I don't say that idly; I say it from both experience and you know; aggregated data:
- https://www.hays.com.au/documents/276732/1102429/Hays+Techno...
- https://www.itcontracting.com/rate-checker/
- https://news.ycombinator.com/item?id=32606348
Yes, if you want someone to slap a php website together (or javascript, or many other entry level frameworks), you can pay less.
...but that's not what they were asking; they were asking for a technically sophisticated analysis of an existing project and a performant re-implementation in rust.
They got a bargain.
That's a good question. But a new, Rust (or whatever is fast) version of prettier is effectively Prettier. If it has the same config, switches, and defaults, it's Prettier.
The value of prettier is that it's a standard most of JS/TS agrees on, saving discussions for more important topics. The code that gets us there is a side effect.
Basically I'd assume, if a project targeted at JS, switched to rust, the number of useful pull requests would be 50-100x less.
I wonder if anyone has any data on that (and similar projects re-written in C++ or Go etc...).
Furthermore, projects like Ruff show you can have a lot of contributors for projects like this. Maybe because there are lots of devs who use TS or Python in their day job, but want excuses to use Rust on the side.
But performance is a field that's really hard to accurately measure as there are so many variables, machines, benchmarks... You can see this in the JavaScript ecosystem where every project says that they are faster than the other one and they are in practice all right depending on which benchmarks they use.
So, creating a big bounty with something that's very hard to accurately measure is likely not going to work out very well.
In practice in the ecosystem, the Rust community really cares about performance. So it feels that this is the right audience to build something really fast. But, so far, none of the Rust-based printers were even close to outputting the same thing as prettier. They all decided to implement a different set of options, made different design decisions...
So every time somebody mentioned using one of those, I was getting annoyed that I would --love-- to recommend them, but it wasn't going to be the same. And I believe from experience that one of the main reason Prettier has been so successful is because of this --very very very very-- laborious last few percent of edge cases.
So goal #1 is to convince at least one of those projects to start being compatible with Prettier so that we had a viable alternative. In practice, there was no way I could talk to them directly and convince them to align with Prettier. So the idea of the bounty came to be, if I made a bounty big enough, it would be a way to convince them to do so (and it worked!).
The bounty to work needs to be very easy to test (percentage of tests that pass is very easy to test), cannot easily be cheated (unless you run prettier itself, you need to go through the laborious work of doing the same logic) and cover real world use case (all the tests were added over time based on using it in prod). It also mentioned a "project" and not a "person" to encourage collaboration.
It's a bit unorthodox but I've learned my lesson with code formatting that people are obsessed about discussing this topic so you need to find alternative ways to convince them.
Now, going back to Prettier, I've been very annoyed that nobody had looked at performance of the project since after I stopped working on the project. For example, I wrote a way to keep the prettier process alive for editor integration instead of paying for the startup cost every single time https://github.com/prettier/prettier-rpc and nobody used it. I needed to find a way to convince people that prettier's performance actually matters.
One of the most powerful way to get people to improve performance is to have two competing offerings battling against each others. We've seen this very successful between JS engines, JS frameworks... But, due to the success of prettier, there was no competition, the JS Survey admins even stopped asking about it because it was the only choice.
So having a proper competitor which is faster and uses a relatively controversial language, was a good setup to get a competition going. And it also worked, since the bounty was announced, Fabio Spampinato got nerd snipped thinking he can make the JS version faster than Rust and has been working every day profiling and rewriting the Prettier CLI to be orders of magnitude faster. We are using the open collective money to contract him to work on this.
Outside of performance, by having another group of people work on the same tests, they uncovered a lot of broken behaviors and edge cases on prettier that should be fixed.
Last but not least, having a bounty incentivizing another project was intriguing enough to generate a lot of discussion and therefore receive a lot more coverage than just asking people to work on your project.
----
So, overall, it achieved all the outcomes I wanted: by the end of the year, prettier itself is going to be a lot faster, and we actually have -less- fragmentation in the space where the other big project is now aligned in terms of the way code is formatted.
Would have I been able to spend $10k more effectively, I can't think of how. But I'm pretty sure I'm missing some better strats!
I was indeed wondering that but the answer doesn't really answer the question for me. Why not set a bounty to improve Prettier instead of building a competing project just to increase the motivation to improve Prettier? Or is the end goal to shut down the Prettier project and encourage people to switch to the Rust based one? Seems like an unnecessary fragmentation of an already confusing landscape.
Maybe I'm misunderstanding something though.