azylman's comments

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.