> "And secondly, even if it were massive, it's not massive per-property which is the only thing that matters in terms of transactions here. Database sharding in this case is incredibly straightforward, compared to many other types of websites. And in both cases, just use standard database transactions."
This is such an important point that a lot of software devs don't get. If you think about the shape of the data, you can often find ways to naturally partition the data so that you are dealing with much smaller scale.
No need to hide the information on the methodology of the survey:
"YouGov Ratings
YouGov Ratings measures Airbnb’s popularity and fame every quarter. The latest data is based on 1532 nationally representative interviews of the US population, collected during Q2 2023."
In that case the volume of traffic such a communication medium would need to handle is likely small enough that you can bump the key size higher to ensure greater longevity, currently past the lifetimes of those involved, and accept that transmitting data will take a small fraction of time longer.
You are never going to get broad adoption if you require someone to sign up to use something locally. Full stop. People who will install any software that comes across Hacker news are going to pause the moment you make them sign up to use a local application.
All of the explanations about how it's not intrusive and only collects X, Y, or Z doesn't matter. There are many apps I use that send crash reporting data, and the only time they do that is when they crash and then they ask me if it's ok. I don't have to sign up to do that.
His point was that there is a big difference between building a product and operating a service. I can understanding not wanting to do the latter, because it's a COO job and unless you like doing that it is not fun.
Framing it as "give me money and I'll stop making things difficult for you" is disingenuous. The proper framing was "buy the app out and the API usage, and thus the $20mm/year in costs, will stop, or whatever you want to do with the product at that point".
If their operating income is accurately reflected above, there is no indication they are going in the right direction. There is a period of several years where a company is in innovation mode and they will burn through investment, but there must be an inflection point where Operating Income starts increasing YoY, even if they are still operating at a loss. Hashicorp has gone too far in the wrong direction.
Rails is fine, any Python framework is fine, Spring Boot is fine, whatever the PHP hotness is is also fine, some NodeJS frameworks are also probably fine.
I use a refillable cartridge on my pens and have dialed in about how much ink I should load at any given point in time based on my writing habits. It might help to play around with that.
So glad people like you are pushing back on this nonsense. Whether a ban is the right approach, or just a band-aid, this is all a national security issue. No one can seriously look at the cyber security space over the past 5 - 10 years and not conclude there are nation-state actors exploiting technology for spying and cyber attacks.
This is a pretty good write up on the actual implementation problems of the solution vs. just a rant. The company I'm at now built their own custom graph database years ago and is plagued by problems that would be cousins of some of those listed here, so I see the pain the author is dealing with because I'm hearing about similar problems from some team or customer support at least 1x/month.
Back in the day, about 15 years ago now, when I was pair-programming every day and trying to teach new people how to do it, everyone was awkward at first. People who were Vim experts suddenly started stumbling over basic tasks. All of them who persisted eventually got over the awkwardness. Not all of them enjoyed the pair programming, but the ones who I talked to later found that it wasn't as awkward after a bit.
This isn't a hindsight thing, this is a well-understood risk in finance. The lead time on rising interest rates was also significant enough for SVB to have shifted their investment strategy. Regulatory bodies in the US are both underfunded and hamstrung in their ability to regulate, and for a bank of SVBs size, they would not have been a prime target for regulators.
Any investment strategy will require addressing various forms of risk and making tradeoffs, but it is a choice. SVB did not properly hedge against this risk which, as soon as interest rates started rising, should have been a priority for their leadership to have a plan to address.
Do you have examples of companies in this space that actually reached break-even? Heroku never hit profitability as far as I remember and with the Salesforce acquisition the question of profitability is moot. AWS is a counter-example to using a free tier as a GTM strategy. AWS did not start with a free-tier offering for S3 or EC2, that only came years later. By then they already had significant traction in the market.
I wish I shared your enthusiasm for where Heroku could go but I have a few friends at Salesforce I've asked about how they see Heroku internally and it really doesn't seem like it is going to get much love. Hope to be wrong though.
This is likely the biggest culprit for a lot of these companies. Too many of us have grown up in the culture of getting hosting and platform for "free", but at some point the companies providing it still have to pay the bills. There has to be a better pricing model that let's someone deploy their relatively small, low-traffic app for $10s/month or even $200 - $300 / year for the basics (e.g. - Heroku free tier type capabilities). It's not going to save these companies but it would limit excessive growth of their own costs from a free tier while at the same time still being affordable for 1 - 2 person teams who are trying to get something in front of users.
That's a pretty poor understanding of basic prob & stats. What if you are not an average company? What if you're not an average company and on the low end of that bell curve? If the author is only 10% correct, maybe the author is only 10% right about the type of company that could benefit from "applying data science".
> I've generally found that if you can't measure something well, large American companies act extremely poorly with regards to that thing.
You've got it. The number of companies I've worked with who talk about being "data-driven" and who do not use any data for a majority of their decision making is ridiculous.
I think it was more of a tragedy of the commons where some companies started aggressively hiring, and other companies followed suit to avoid losing access to talent. The pandemic was a huge societal event, but nothing indicated it was going to be the new normal and CEOs who grew headcount expecting it to go on indefinitely made a huge, and arguably an easily avoidable, misstep.
When Google announced 12,000 layoffs, for anyone reading past the headline this came on the back of hiring 41,000 people over the last two years. 41,000 is about 1/2 the total employees of Salesforce as of October 2022.
Those companies expected a major societal event to become the new normal without strong data to support it, and chased growth that was not going to be sustained.
This was the sense I got as well, though I have only started playing w/ Meilisearch. Clustering was one of the top 3 features that let Elasticsearch take over the market so quickly. In the playing around w/ Meilisearch I've done, it seems more like a replacement for something like Sphinx so far.
It is if you don't want to wind up like IBM, i.e. - a company that could have been so much more, knew it had to change at the leadership level, and yet still couldn't get out of their own way. Apple's renaissance came because they started releasing innovative products and cannibalizing their own business.
Stepping back from any emotional assessment, the growth of these businesses was not commensurate with the hiring. You can look at both the financial reporting and the economic indicators from that period and a reasonable measure of growth was warranted but not at the level these companies [edited from "comments"] hired at. It was more of an irrational tragedy of the commons, where companies were hiring because they were afraid of losing access to talent due to other company's hiring. It was not rational through the lens of business growth.