azylman

This isn't really true, some languages handle I/O much better than other languages. We migrated a Python application to Go that was about as simple as you can get and mostly blocked by I/O (call DB, transform storage format to Thrift, respond to caller with Thrift) and saw SUBSTANTIAL improvements in performance. Approximately 40% improvement in p99 latency and, more notably, 15x improvement in throughput.

There's an important nuance there which is that they don't have to prove that the person knew the actions they were taking were illegal, just that they intended to take those actions. As an example:

Knowingly driving a car someone else stole is illegal, even if you don't actually know it's a crime to drive a car someone else stole (after all you didn't steal it, maybe you bought it from the person). Driving a car that was stolen that you didn't know was stolen is not illegal.

I mean what is uber processing payments itself too?

https://underhood.blog/uber-payments-platform

https://underhood.blog/assets/images/uber_payments/overview....

Usually the way these kinds of things evolve is it will start with some business requirement: "We want to launch in country <X> but our existing PSP <Y> doesn't support the country's most common payment method <Z>" (Uber operates in 71 different countries).

So you build out a system to abstract over multiple different PSPs (such as Stripe, though Stripe isn't listed in that graphic so not sure if Uber uses it at all) to unlock new business growth. Then you find out that some PSPs are cheaper than other PSPs, so you can save the business money by supporting additional PSPs. Then you find out that some PSPs are more reliable than others so you can increase availability by dynamically selecting PSPs based on availability and transaction costs etc. etc., layering on complexity over time.

All these things are actually built for very good reason (in this example, built to grow the business and reduce costs), but the reasons aren't obvious to the outside observer. But the work easily pays for itself many times over.

So could you run Uber with <100 engineers? Probably, if you were okay running in just a single country instead of 71. But that would be a very different Uber.

You can only run Uber with <100 engineers if you cut out a substantial amount of the systems Uber requires to actually function as a company. Goodbye Fraud, Risk, Safety, Insurance, Compliance, etc. That may be true for things like Whatsapp with a simpler feature set, but is certainly not generally true. For instance, people often underestimate the amount of ongoing engineering effort to stay up to date on changes in tax law in all the countries Uber operates in.

Should be max 100 devs and everyone else in sales and support.

People with no experience running systems at scale often underestimate the amount of effort required.

This is not the case, removing dams still can come with huge benefits to the ecosystems those dams disrupted: https://www.mercurynews.com/2019/05/08/four-years-after-cali...

If this still builds a dam, doesn't this have the same environmental concerns as any hydro project? Or is there something that makes this less of a concern?

Sourdough is made with yeast

Yup, that's a lot closer to the kind of numbers I would have expected. And if you look at peak it's probably at least 10k tps for each of them.

That doc is from 2013, so it's pretty out of date.

I can pretty confidently say that all of Visa+Mastercard is way more than a few thousand transactions per second, I'm familiar with several companies that push hundreds of transactions per second through Visa+Mastercard and there's no way they're a significant portion of their business.

This article claims Mastercard alone is 5k: https://cointelegraph.com/news/bitcoin-lightning-network-vs-...

DC and LA are both infamous for having bad public transit systems, so don't base all your decisions on your experience there. Within the USA, Chicago is really good - taking the L is way faster than cars because you get to skip road traffic and the trains come very frequently. I've heard mixed things about NYC (some very positive, some very negative, likely depending on where you're traveling from/to), but have no experience there myself. Outside of the USA, there are lots of countries with fantastic train systems (e.g. Hong Kong) that are way better than driving.

That may be the case for LA, I'm not familiar enough with their situation to speak to it, but it isn't the case generally. There are lots of rail lines in the US and globally that have not come anywhere close to maxing track capacity. One such example is BART in SF, which could just add more cars to existing trains and see 60% increase in capacity [1]. The tracks and stations support trains up to 10 cars long, but very few are actually that long enough because they don't have enough cars in the fleet.

[1] https://www.bart.gov/about/projects/cars/faq

Here in city (Seattle) most people drive because transit tends to be spotty and slow for most people...So, what's the solution? Make driving worse of course. Speedbumps everywhere...Transit still mostly sucks, but now driving sucks too...the transit folks realized it's hard to compete with driving, so they've just given up entirely on making transit great. It's easier to ruin driving.

The claim was that they put up speed bumps (and other measures) _with the intent of_ making driving worse to encourage public transit. That's obviously false. Speed bumps get put up to discourage unsafe driving.

If, when forced to drive safely, people would rather take public transit, that's kind of scary, but also a good thing I guess to get unsafe drivers off the road? However, that's not what the claim was (and in reality is unlikely to be true, though I have no data to back that up).

Building an entirely new bridge isn't going to be cheaper than adding more cars to BART. Even assuming it was (which it wasn't), it's not going to help as much as you think it is. Not sure if you've ever commuted on the San Mateo bridge, but it's basically fully backed up from the exits onto 101, because 101 is also grid-locked. So in addition to building an entirely new bridge (which, again, more expensive than adding more cars to BART), you also need to add more lanes to 101.

Maybe try quoting the entirety of what I said?

Additional highways are at-best a stop-gap for day-to-day traffic, never a solution, due to induced demand [1]. You really need large-scale investments in public transportation for this.

Clearly "improve roads" vs. "improve public transit"...

How many semi truck drivers and their loads can you fit on a public bus?

You're again arguing against something no one ever said. No one suggested that we should just remove all semi-trucks and replace them with buses. Again, we're discussing where to allocate incremental improvements to existing systems. No one is suggesting doing nothing or, worse, shutting down existing systems.

Using your specific example of semi-trucks, moving more traffic (such as daily commute) to rail lines or buses can actually help semi-trucks as well, by freeing up road capacity for things that actually need it. And additionally, freight trains already make up a fairly large percentage of our freight network (~30%) so rail is actually a great alternative to semi-trucks in many cases.

Here in city (Seattle) most people drive because transit tends to be spotty and slow for most people...So, what's the solution? Make driving worse of course. Speedbumps everywhere. Change 4-lane roads to 2-lanes. Remove parking. Lower speed limits to absurd levels. Make through streets dead ends.

This is obviously not the solution that anyone is proposing. You're arguing in bad faith against a strawman. The solution to bad public transit is to make public transit better.

Sometimes you just need a wider road. Pretending that's never the case is preposterous. If that was true then why do we keep multi-lane highways open instead of closing all but one of the lanes? Wouldn't that improve traffic, under this theory?

You're setting up this strawman where the argument is "improve roads" vs. "do nothing". That's obviously not the case. The argument is "improve roads" vs. "improve public transit". Demonstrably, improving roads is worse than improving public transit. You refer to this as a "fool's conclusion" yet this has been a well-known fact in the field for almost a century. The wikipedia article I linked has some good information on this if you'd like to learn more.

Yup, this is a big reason why I said "in most cases" and not "in all cases". When your trains have to go underground and underwater and your highways go over roads and over bridges, that dramatically changes the numbers. Of course, none of those are a requirement of rail systems - just how the BART is built. There are plenty of trains that go over roads (e.g. the L in Chicago) or over bridges over water.

By the way, even BART could increase throughput today without adding more lines. Not all trains are 10-car trains, because they don't have enough cars in the fleet. Adding more cars to their trains is a significantly cheaper prospect than adding a new lane to the Bay Bridge (which was also basically fully maxed out on throughput during peak traffic times, pre-COVID). And BART carries substantially more people across the Bay than the Bay Bridge does.

So, certainly the BART needs more capacity, both now and in the future - but so do the highways.

It's not correct that cities look at road throughput with no concern for how long that travel takes. The success criteria that city planners use always includes travel times which are impacted substantially by traffic congestion.

The way that public transit scales to meet higher demand is different than roads. Whereas roads require more lanes, public transit such as trains can scale by either adding more train cars to existing trains or adding more frequent service. More frequent service, in addition to improving throughput, also helps everyone else using the system by making it more convenient. And, if it "induces" people to move from roads to trains, that also reduces congestion on the roads. So induced demand for rail lines is a good thing.

If induced demand is high enough even that, too, may not be enough - but then building a new rail line is at least no harder than adding a new highway lane (in most cases), and can support substantially more throughput with equal or lower travel times.

It depends what your success criteria is. It's true, you've successfully increased the throughput of the transit network, but you haven't done anything to improve transit times - you just have more people stuck in traffic now. There are other ways you could have spent that same amount of money (public transit) that both increase the throughput of the network _and_ improve transit times.

No comments on emergency situations, but wanted to call out one thing:

You need additional highways (aka: additional offramps) to truly scale day-to-day traffic

Additional highways are at-best a stop-gap for day-to-day traffic, never a solution, due to induced demand [1]. You really need large-scale investments in public transportation for this.

[1] https://en.wikipedia.org/wiki/Induced_demand#Effect_in_trans...

It really depends on the company. Companies like Google and Facebook are very unlikely to hire people at a higher level than their previous level (though certainly it happens). That's easier at smaller companies.

"The guy" - the CEOs of both companies? You're essentially stating that the CEOs of Uber any Lyft are lying to their investors, which is a crime. That's a serious accusation and some actual evidence is needed.

I'm not saying "trust the management", I'm telling you how an investor would think about it. High spend on marketing can absolutely be justified. Additionally, there's rarely enough public info to allow any investor to independently verify whether it's justified in a specific scenario or not. But if an investor thought that there was positive ROI on that spend, they're not going to fret too much about how large that amount is - as long as it's bringing in a positive return.

Yes, companies have ways to do this with a decent amount of precision and accuracy based on existing user behaviors. They can often even be detailed enough to know that LTV differs depending on the channel that the customer was acquired by (e.g. organic vs. Facebook ads vs. search ads) and tailor their ad spend accordingly.

I don't know what AirBnB's numbers are, companies aren't required to disclose this and they guard it very closely :)

This is a common misconception I see on HN.

To evaluate ad spend, you don't look at just short-term return. There's a reason that "lifetime value" is a critical concept for companies. It's fairly normal in large companies that, in a given year, you may spend more on ads than you gain from those ads - but you expect the customers you gain from them to continue spending over many years.

So you may spend $100 to gain a customer who spends $20 in the first year... then $40 in the second... then $80 in the third... now all of a sudden your return on that was positive, three years later.

These are the kind of ads you want to buy, even if in the short term it looks bad. These large marketing expenses should have compounding benefits over many years. The people who care about the short term like that are not the investors you want and not the people you're trying to please.

This is reflective of the adoption of dice, not the adoption of Go... there are lots companies in NYC that hire engineers to develop in Go (Google and Uber immediately come to mind).

Exactly, given a timeout you can't assume the server is clearly successful (or unsuccessful!). That was my point, we're definitely agreeing :) Usually you'd generate some kind of idempotency key (randomized token as you said) and retry with that.

You definitely can't just bubble that up to the user and assume things are fine