yazaddaruvala

> On the other hand, I heard that leather is a by-product of the meat industry - i.e. the cattle would be raised either way.

Sure, but still seem worth it!

Right now the by-product generates additional profit per animal. If we all stop using leather, the by-product becomes a liability and they need to do something else with it that costs them money.

All of this means to retain their initial profit per animal, the cost is transferred to the meat consumer. Which in turn might help drive sustainability through lower meat consumption.

Out of curiosity, why not go all in on Tokio? Make everything a future, including writing to the GPU.

And are you using an ECS based architecture? Do you feel you’d have a different opinion if you were?

> That's their problem, no? Nobody's forcing them to have an architecture where a request propagates to hundreds of services.

I mean, physics kinda is.

Just the volume of data that needs to be hosted, needs multiple nodes. ElasticSearch has some good general documentation of search engines if you want to learn more. In Amazon's case, a general query will hit a fanout of about 10,000x nodes - I wasn't even counting that fanout because it is all technically 1 service.

Meanwhile, Bun.js (no offense to Bun) is built for IO-bounded workloads and 65k req/s is great for that. However, executing the required Natural Language Processing (i.e. multiple ML models) would result in an exhausted CPU (even if Bun could distribute the compute across cores or compute the ML inference on a GPU). I'd be willing to bet even on a great CPU it gets throttled at 10 req/s (at most 100 req/s).

This really isn't some "They should have just done it all in Postgress, Bun.js can just use a nice ORM and be IO-bounded" type situation - which is a philosophy I very much agree with for 99.9999% of usecases.

> If it's the real-deal, and not like people saying "Bun.js can serve 65k req/s+ (cough cough to localhost,)" that's impressive.

Not all req/s are made the same.

Amazon search is made of 100s of services, and Amazon's search page loads 20 products per page, that means 80k search req/s translates to 1.6 MM product API req/s for example.

FWIW a search request at Amazon hits roughly 100 unique search clusters (think of this as ElasticSearch clusters - but its not ES), with different product groupings in each cluster. Each cluster is made up of 1000s of nodes running Lucene (think similar to ES shards). This is just for the "match set", i.e. which products to return.

Then there are services to re-sort those matched products based on popularity, likelihood of purchase, etc. Think giant ML models. Then there are product lookups. Before all of this, there is Query analysis to simplify/improve the query (think giant ML models) to classify "Apple" into electronics vs groceries based on the other keywords and your current context.

Meanwhile, Bun.js is talking about 65k "hello world" type req/s. The compute per req is magnitudes different.

Not all requests per second are made the same.

For example, it is just as true for this title to have said "How Amazon uses ... to load 1.6 MM requests per second, from just the search page."

Each search page load, is 1 request to the search backend, but 20x request fanout to the product's key-value store to render the images and titles, etc.

Disclaimer: Used to work at Amazon.

Funny story, internally Amazon Search doesn't consider the ads products to be part of the "search results". It is tracked and accounted to Ads.

The way Ads are handled on Amazon is really poorly done. The Ads teams claim to make a lot of money (and based on the internal accounting tricks they do), and as such have been pushing Amazon's leadership to go more into Ads, even tho every person I've met that worked at Amazon also hated the prevalence of Ads.

Literally, Directors and VPs at Amazon are afraid to step on the toes of Ads' leadership team because of how well they have told the story about "Ads is excessively profitable".

Meanwhile, all of us in the thread can easily say, even if it is short term profitable, it most certainly is not long term profitable for Amazon.

Both from internally and externally it has been very disappointing to watch actually.

"Baby bonding leave" should still apply just the same to a child born at 18 months.

React-likes (including Vue, Preact, etc) have the most ergonomic interface for UX devs to develop with.

They sold more than they have created. Ie they need money to finish the ones they have sold.

And they have excess debts that their assets no longer cover because the housing market crashed.

Additionally, they just took on obscene debts. The banks did not do the appropriate due diligence (hypothesis is the local governments interfered).

But I know only what rando YouTube videos have told me.

Having the file and line number automatically added is quite useful for server logs - especially in production.

Very, very few end up in front of an end user. Typically only in a CLI.

I took away that it was 100 miles in Track Mode. In Range Mode it was a lot more. Not sure how much.

> Most accidents are caused by licensed drivers

Exactly, the point I’ve been trying to emphasize is:

The bar to become a driver in California is really LOW. We should push for the robots to be even better, but given the low bar for humans, I don’t see a good reason to stop them from training on public roads.

Should we give the robots the same test, if they pass they get the drivers license?

Seems like a low bar to me - for both robots and humans. We should instead raise the standards even higher for both!

Sleep deprivation causes a reduction in ability to reason. Similar to being drunk. A drunk person can also feel drunk, but “how drunk is too drunk?” Similarly “how sleep deprived is too deprived?”

The answer is, at a minimum, that a second “sober” party make that judgement.

> No need to increase that number by allowing half-developed machine to kill even more people

1. To my knowledge there has been only one death by a robot car. It was Uber’s and that program has been shut down for many reasons.

2. Given robot cars already have a higher bar for safety (ie fewer deaths, injuries, etc) than 15 year olds, wouldn’t the more prudent use of time/energy be to invest more into robot cars while changing policy so driving becomes (at minimum) 18+?

The myth about good vs bad drivers has long been out to bed.

All drivers are better than average drivers.

The problem for all humans is alcohol, sleep deprivation, stress, phones, coffee, makeup, shaving, food, etc.

Everyone, including you, has read at least one text while driving. Sleep deprived actors by definition cannot correctly judge their ability to be sleep deprived. None of us are immune to these realities.

The only way safely (with data) testing self-driving robots is “net worsening” for humanity is if you aren’t taking a long term view.

> [2015] In California alone, 431 people died in accidents involving young drivers[0]

By your logic we should also stop allowing 15-20 year olds to learn how to drive in public.

So far the robots have done less damage.

[0] https://www.inlandempirelawyers.com/blog/young-driver-accide...

The only goal of any democratically elected government program is: improved citizens.

It is in the definition: “for the people”.

Pointer arithmetic optimization based on undefined behavior is a problem regardless.

Life is always better after minimizing the total number of types of undefined behavior.

I think you’re missing the point.

NASA and ULA like programs trained and built expert training to create those citizens.

Being able to recruit them is a non-goal.

I worked there for 10 years.

Sure, when AWS was created Amazon.com didn’t use it.

However today, Amazon.com is built entirely on AWS. It has been using EC2 and S3 since at least around 2010 (by 2013 “legacy hardware” was almost non-existent). Until 2020, it was all “hidden” behind Amazon’s internal tooling. Around 2019 there started to be a big push to just use AWS directly ie teams get AWS accounts owned by the Amazon.com org. There is still internal tooling to hook the code repo, build systems, and “pipelines” to directly deploy to AWS resources.

Meanwhile, the “serverless” I was talking about in the previous post was an internal service that hosts a Lisp dialect called Datapath. As a developer, you write some Datapath and give them the money and it executes as much as you need it to. This service is the core of Amazon.com and was actively being migrated to Graviton.

The job is to communicate effectively while producing software more reliably and with less time than someone else that might get hired.

There are many of us who think Java has very little to learn - asking us to go slower - while probably good for society in general, is a losing strategy in a Capitalist economy.

You can keep up, or be left behind. Meanwhile, fortunately the “communicate effectively” is 100x more valuable as “produce software more reliably and faster” ie learning all of these new languages and language improvements.

Even in 2021, most of Amazon Retail’s workloads were “serverless” and the entire platform was actively flipping to Graviton one cluster at a time.

Yeah, I can see that getting stuck on ideology.

It just feels to me Nintendo doesn't have many options. Other than the IP, people would rather use the Steam Deck over the Switch. This was also a similar hardware story for non-mobile consoles.

Meanwhile, both the Switch and Deck are roughly an iPad with dedicated controllers. And the future is VR, but Nintendo is struggling with frame-rates even on the Switch.

I can see Apple making a deal with Nintendo, to build its next console as a peripheral on-top-of the iPad / visionOS. All the power of Apple Silicon and all of the inspiration of Nintendo IP.

I think they are going to buy Nintendo

> Utilization levels will be driven by peak demand

Exactly! Just like a data center, the economics are gonna work out very well for high scale medium returns and over time: minimal returns.

> I don't think Lyfts get 10x cheaper with robocars. It's not like 90% of your fare goes to driver net profit.

Ok let’s do this one more time:

Lyft currently takes 25% of the fare. The driver and the car take the other 75%.

Lyft’s 25% includes R&D for building the platform, support issues, and solving the chicken and egg problem in new launch regions. ie Lyft operates at a loss in a new city to attract drivers so riders can start using the app. This loss is roughly made up for by profitable cities like LA. 1. There is no chicken and egg problem with robotaxis. It’s just a matter of capital cost and ROI time horizons. 2. The robotaxi will be more consistent and as reduced support costs. 3. The platform will have been built, and limited R&D for KTLO. 4. Competition in the space between large robotaxi fleets will push down margins, reducing overall profits.

It’s very easy to see Lyft only requiring 5% rather than 25% to continue being profitable and competitive.

Meanwhile, regarding the driver and car: Robotaxis require roughly $10-20k more in car manufacturing, but can also be used 24/7 so better capital utilization on the initial investment for the car (it really is hard to imagine the worth of a car that is used 99% of the time rather than parked 95% of the time). Maintenance costs reduce with scale (+in house mechanics to improve margins). Maintenance costs reduce with electric drive trains. Maintenance costs reduce with better initial manufacturing (to optimize overall car costs rather than optimizing for initial sale costs to sell to individuals).

Increased scale can mean reduced margins i.e. Amazon. Vertical integration also yields better efficiency: When robotaxis have been real for a decade, car manufacturers will build and run robotaxi fleets. Unlike today, vertical integration of manufacturing, maintenance, recycling and operating the fleet of cars creates a lot of consistent demand and can bring significant economic advantages. Even the car manufacturers goals change. Rather than optimizing to sell cars (have them degrade and sell more), cars will be optimized for durability, maximum materials reuse, lowest variable cost per ride, ergonomic rides. A professional driver can put on 25k-50k miles per year[1]. Compared to 10k-15k miles per year on average[2]. Meaning professional drivers hit the car’s mileage limit, 200k-300k in 6-8 years. Already it would be better for them to have cars that are optimized for cleaning, maintainability, and longer lifespans. And this doesn’t even talk about lifespans of wheels or the expedited cost of maintenance. Taking this math further: This is targeting 40 hour work weeks for professional drivers. If we targeted 75% (a lower bound) of the total hours in a week 168, we see robotaxis will drive 3-4x the miles of today’s Uber drivers. Setting lifespans of 2-4 years per taxi. Large robotaxi fleet operators will likely become manufacturers but regardless they will change the mental model of how car manufacturing currently operates. Robotaxis will not only absorb the profits of the taxi industry but also the profits from the car manufacturing industry, car maintenance industry, car rental industry, last-mile delivery (including food delivery) industry, rental housing industry, and more. Fleet operators will also optimize the cars for most recycling ability. Just look at the trend with a manufacturing company like Apple. Metal frames not only look good but also recycle better and are better for business as a whole. Apple has an iPhone tradein program because recycling materials can be cost effective for them. The scale will eventually be unimaginable, allowing the margins to be astonishingly low.

[1] https://www.quora.com/How-many-miles-does-a-full-time-driver...

[2] https://www.carinsurance.com/Articles/average-miles-driven-p...

> but I doubt they will make it that much cheaper.

All other tech has gotten 10x cheaper across 10 years. No reason to doubt robotaxi fleets won’t as well.

Vehicles in general are inordinately expensive.

Lyft just quoted me: $20 for 3.5 miles, in 15mins. That is a reasonable daily commute. 2 * $20 = $40 per day round trip. $40 * 5 = $200 per week. $200 * 50 = $10,000 per year.

For a 45 min commute: that is $30k per year.

Clearly should buy a vehicle.

However, with 10x cheaper Lyfts: at 1-3k per year; that is the cost of maintenance, registration, and insurance. Then the car payments on top of that... Owning a car would be inordinately expensive.

This doesn't even include the benefit of getting 45-90 mins back to learn or play while commuting.

This is overcome with super human sensing and reaction time and better visual angles.

i.e. radar based deceleration to avoid accidents already helps many humans avoid collision. It'll help the robot too.

The rest of driving is relatively simple, methodological, and slow.