Hacker Newsnew | past | comments | ask | show | jobs | submit | KolmogorovComp's commentslogin

Honest question, does Uber need that much R&D? And do they expect the ROI to be positive?

Imagine making your product compliant across 100+ countries while regulatiions, labor-laws, tax rules, insurance requirements, and data privacy laws keep changing.

Imagine itegrating dozens of payment methods - many of them highly localized - across emerging and developed markets, while dealing with fraud, chargebacks, KYC, AML, and settlement complexities.

Imagine processing trillions of data points every day - rides, location updates, pricing signals, ETAs, traffic conditions, demand forecasts, payments, support events.... storing it efficiently, querying it in near real time, generating reports, and keeping the whole pipeline reliable. I have woorked in data engineering, and can tell you confidently that this alone requires an enormous R&d budget.

Then there are the apps - not just customer-facing, but driver-facing, courier-facing, merchant-facing, fleet-management, onboarding, support, operations, compliance, finance, and hundreds of internal tools and dashboards.

Then come the integrations. Companies running at Uber's scale genemrally have hundreds of tjese - mapping providers, payment processors, banks, identity verification, tax systems, telecoms, customer support platforms, fraud detection, analytics, ERP, CRM, and more.

... And then there are even more...

Real-time routing and dispatch optimization

Dynamic pricing and marketplace balancing

Fraud detection and account security

Driver/rider safety systems

ML models for ETA, demand forecasting, incentives, and churn prevention

Experimentation infrastructure for thousands of A/B tests

Reliability engineering across globally distributed systems

Data centers / cloud optimization at massive scale

Localization across languages, currencies, addresses, and cultural norms

Customer support automation at global scale

Autonomous vehicle research, mapping, and computer vision

... to be fair, this is all what I could thing of based on my own work experience in related fields... there is definitely as many more systems in reality as mentioned abpve.


i assume this also includes their self driving vehicle research and trucking, not just their consumer mobile app dev

Uber cancelled their self-driving research years ago.

Patches / PR

> It’s probably the core reason developers choose GitHub as their main git forge. I get it. It does have it’s advantages of giving a better experience for reviewing a set of changes. Initially. But what if I told you there was a time when submitting email-based patches was the standard for version control?

The author explains well how you can bear with patches, but not why patches were chosen in the first place. What advantages do they have over PR? I see none, and I won't lose my precious time working-around an inferior process to Github's already subpar PR one.


Here is what email patches are all about:

https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kerne...

I tried email patches with another person myself. The only reason GH won here, is because the git people made one fatal mistake: They forgot to include the tree hash and only show the commit hash in the email patch. But the commit hash is useless. When you email patch, then commits people want to treat as "the same" and talk about have different hashes. The commit times differ and there is not only the commit author, but also the committer.

We stopped doing email patches, because commit hashes became useless for communicating with each other.

GitHub made commit hashes "constant" in a way people care about.

For our purposes, tree hashes would have been much better in practice.

The git user interface is literally "git porcelain". It cuts you for no reason.


That's not the only problem with git send-email by a long way. Even the setup process is extremely painful.

I believe I've read something by Drew DeVault about it, but I can't find it.

The closest I found is this - https://drewdevault.com/blog/Code-review-with-aerc/ - although it has broken links.


You did not explain why the patch based process is "inferior", neither did you explain why you'd have to "work around" the process!

Learning git format-patch, send-email, configuring SMTP, setting up wrapping, mailing list etiquette, versioned patch sets...

I think there is a strong argument that Gerrit is the current evolution of the patches workflow, many prefer it, and there are a lot of good blog posts explaining why.

I don't know what the justification for emailing patches around is though, that seems needlessly painful in the face of alternatives


Patches allow people to contribute without having an account on the forge.


use tmux.

This should really what LLM ought to bring in terms of security. Be able to break things faster considering it is now easier for the maintainers to fix them.

This has downsides of course, moving further into the "everything rot so fast these days" trope, but we will in a adversarial world where the threat is constantly evolving.

Tomorrow (today) the servers and repo won't be scanned by scripts anymore but by increasingly capable models with knowledge about more security issues than many searchers.


You missed the tongue-in-cheek.

And the migrations. Or rather all the half-started migrations that never get through meaning you have to deal with api v1,2,3 all the times.

Those are pervasive in any old and large project but in my experience especially so in compilers.


Management problem more than anything else, I feel.

Compilers should not have so much churn. You decide on a set of language features, stick to it and implement. After that, it should only be bugfixes for the foreseeable future till someone can make a solid case for that shiny new feature.

Scope creep is bane of most projects.


I’ve never understood why insider insight was forbidden, the point of prediction market is betting on the outcome based on information you have.

Is that ‘fair’ for everyone? No! Because no everyone has access to the same level of information. But no one forces you to bet either.


Knower. Thank you. The point of all markets is to aggregate information.

> 99.9% of use cases of EVs can charge at home/work/shop

This is yet again a very US-centric view where you assume people are living in house with a garage.


"home" can be substituted for "place where car resides when owner is at home" without meaningfully changing the point


Well no it does change the point, because the place where the car resides when the owner is at home is less likely to be near a power socket unless its in a garage or the homes driveway. I can't realistically charge my EV from a socket if its on the street.


In NYC that would be the street. The great conundrum of ev's. People that have access to home-charging, worry about range. The one's that mostly sit idling in traffic, don't have access to charging.


> In NYC that would be the street. The great conundrum of ev's. Most streets have street lighting and electricity, easy to add chargers to lamp posts. NYC probably hasn't heard of street lighting yet?

> The one's that mostly sit idling in traffic, don't have access to charging. I think it would be an impressive feat of engineering to charge cars while they are on the move. I like how you think, cars are mostly idling in traffic, we can consider them as stationary, and charge cars while they idle!


Parking is not assigned, sometimes you got to drive around for 20 minutes to find a spot to park over-night and its not guaranteed to be next to a street light. By idling in traffic, I meant that we would love ev's since most of the time we are just wasting gas and fuming up our own neighborhoods.


The ‘burbs truly are the worst of all worlds.

Some of the homes in my neighbourhood have 2 cars in the driveway and another two on the street.

They all move regularly. Walkability is terrible. Public transit is iffy. People have to get places on time.


Zoning changes: can't park inside, in front of the house, and on the street. This will address the problems you raised. Unlikely it will be passed.


Change these rules in hopes there are less cars? Or what?

Where will people put all the cars? The driveways holds 2, and really that’s only if you choose them wisely.

It is already illegal to park your car on the street for an extended period of time. Nobody cares.

Limit the number of vehicles owned by each address?

Fix public transit? Pipe dream. We’ve invested millions and it’s even worse.

The stores and plazas are already built, so walkability is unlikely to improve.

WFH? Actively being abolished.

We really suck at this civil planning thing, don’t we?


In London, I saw lampposts with EV chargers built in, as well as tastefully concealed sidewalk ports. This is not an intractable problem.


In Europe, I live in an apartment with an garage in the basement with EV chargers. Not sure why you you think it's an US-centric view.


because most buildings are too old to have an underground garage, at least in Western Europe.


> This is yet again a very US-centric view where you assume people are living in house with a garage. It is a US-centric view to think that the rest of the world is hunter gatherer tribes. Most people live in some kind of constructed building which has electricity, indoor plumbing, a place to park a car. Before that building is built, the first infrastructure that is ready is electrical, without which most of the tools required for building a home do not work.

A garage is not a sine qua non for EV charging. A place to park is. If a person is buying a car, they would've already figured out a place to park. That place is right next to a building with electricity unless you are sleeping in the woods.

I don't understand why people think that running a cable (a few feet) from the nearest building to a car is impossible.


Even in the US, only 63% of households have a garage or carport.


It's a good news to me considering their open-source nature. If/when they go downhill there will be still the option to fork, and the previous work will still have been funded.

Now for those wondering who would fork and maintain it for free, that is more of a critic of FOSS in general.


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: