Hacker News Reader

Comment by prng2021 | Hacker News Reader

prng2021

Yes let's have engineers that work on an in-car OS and a website that could be created on WordPress assess another company's product that is globally distributed and one of the most highly trafficked sites in the world.

Edit: Didn't mean to downplay the tremendous effort that goes into Tesla's driver assistance features. Just that the architecture, codebases, and problems addressed are so wildly different between the companies.

View on HN

I had a similar thought as whilst the technology might be similar in some ways the context, the history, the use cases and the driving principles are different. Anyone who has started a development job working on an established architecture and codebase should know that it takes months to begin to understand to a good level what's going on and why.

Opinions can be given but should not be taken as gospel over the opinions of the existing developers. But a lot of the time a new owner will take the opinions of their trusted sources (whose paycheck depends upon validating their boss' opinion) versus established experts. Good solutions come from discussion between these two opinions.

Not to interrupt your rant but, Tesla might just also have a distributed backend for their cars to communicate with, that might even be globally distributed. And I would even say that it probably processes more data/sec than the Twitter “product”.

are you aware that all vehicles from Telsa, are permanently "tweeting" huge telemetry data to an amazon cloud infrastructure managing those petabyte of data to for analysis, training AI, and whatever a fucked brain could imagine.

So basically, there is not difference between "hi im having a pizza with friends at this new restaurant at the corner of my street" and "hi im item #12314 and i just turn left at 50mph speed on a busy road"

Telsa and Twitter are both very mainstream business at acquiring huge amount of data, So intuitively they would share the same similar issue and challenge...

You missed the whole storing and showing and appending to time lines part along with inserting a relevant ad into it.

This groups under the banner “fucked brain can imagine”

I'm not sure how much telemetry Teslas actually send (do buyers really tolerate their absurdly expensive car reporting their every move back?), but in any case I would assume it all gets stored for bulk processing. Twitter's pretty different; when [insert celeb with 100m followers here] tweets, that tweet should show up for anyone who's looking at their profile, immediately. And the like and retweet counts should update for everyone looking at the tweet that just went out to 100m people (actually, it would be possible for Twitter to fudge this bit, but they don't seem to).

These might seem on the face of it similar problems, but really they're not at all. Ingesting lots of data is ~trivial; dealing with lots of data in realtime somewhat less so.

similar workload is live update trafic monitoring. collect data from all agents, and redistribute aggregated/processed data to all agent, and update route to optimise time or length or both of travel. collecting data, ingesting data, redistributing ingested/processed data.

I remember back on 2015, there was an AMA on reddit from a former engineer from Telsa.

I remember clearly how he explained how Telsa struggled to update thousand of car's firmware with legacy RH5 vm running on amazon and openssl 0.98 incompatibility with upper version.

I found it very amusing, cause at the same time, i was working at one of the leader of payment industry and POS maker. And we where exactly struggling with the same issue updating firmware of hundred thousand POS terminal in the wild (except that our servers where on premise and not at aws)and dealing with this openssl issue.

And i didnt claim workload are identicals, but i just claims that workload are very similar, leading to the fact that 90% of the solution might be common.

Twitter at scale is far more complex. With Tesla's telemetry it's just writing to a datastore, with less fuss around latencies, data duplication or consistency. There's no need for millions of clients to then get updated, as there is on twitter. Musk tweets and 110M+ users (+thousands of API clients) need to receive that almost immediately. Twitter has figured out how to do this in a very scalable fashion. Once you know how it's done it's not all that impressive on its own but when you take into account the littany of other features twitter has to maintain at scale you start to realize how many unique problem domains there are within the org.

You realize that the car stuff is only a small part of the entire infra and stack right?

My point was just that neither company's engineers has the necessary knowledge to make any meaningful assessment of the other company's architecture and codebases. Both sides are the result of years of iterations to address very unique problems.

Bullshit. That's like saying one company's financial team cant assess another's finances and structure. Happens all the time.

Agreed. If someone has a deep enough understanding of engineering fundamentals, moving bits is moving bits. It doesn't matter what use case is sitting on top of it.

Also - Let's not act like Twitter is absurdly complex. Handling that amount of traffic was hard in 2008, yes. It's not hard in 2022. The app itself is what? CRUD with stream processing? Some complexity with scaling that, but it's not self-driving... that's for damn sure. Even if they haven't reached L5 yet, L4 AV is an infinitely harder problem than storing arbitrary text/images and serving ads.

> L4 AV is an infinitely harder problem than storing arbitrary text/images and serving ads.

It is but it's a different problem. Solving Fermat's last theorem is an infinitely harder problem than, say, speedrunning Minecraft in under 13 minutes but you won't see Sir Andrew Wiles doing the latter - because they are different skillsets.

edit: No idea why I typed Simon Wiles, I know full well his name is Sir Andrew!

> Agreed. If someone has a deep enough understanding of engineering fundamentals, moving bits is moving bits. It doesn't matter what use case is sitting on top of it.

VERY few developers are at this level, though. Most (>99%) are stuck in some paradigm associated with their typical tasks.

You don't just get a CS degree and just magically understand everything there is to know about software engineering. There are specializations just like in the medical field and many others.

Tesla engineers working on AI have their own domain specific knowledge they likely spent many years to get a PhD for. The same goes for Twitter engineers working on natural language understanding AI to detect certain types of posts. By your logic there is just one broad category of AI researcher and they're all the same and have the same expertise. Scratch that.. there's just one broad category of computer engineer and they're all the same and have the same expertise. Twitter or Tesla engineers could easily do a code review of Space X's code base right?

You might not know how to make a sophisticated ai for censorship, but looking at the code and infrastructure, you are likely to figure out where is the blackbox/political censorship is. And since it seems that Musk is going to get rid of most of censorship(or rebuild it in his favor) that's most likely what he's asked trusted engineers to look at.

Are you serious? do you know how software development is done? do you know what a repository is? Do you know how to look through repository to find code changes? Any computer scientist can do that there’s nothing special about Twitter I don’t know why you think that. Twitter could be created by an undergraduate CS major.

There is a reason the best practice is not to do huge PRs because it's very difficult to review. Now imagine one person has to review all the code generated by a company such as Twitter with 3k+ Engineers across multiple years. Is that even possible given the cognitive load? If so how long would it take to produce anything meaningful?

It sounds like you have at least an undergraduate CS degree. Go ahead and recreate Twitter and share your GitHub repo for us to review. No need to rush. I'm happy to wait several decades for you to complete the project.

I mean how hard could really be since nobody really has access to the fire hose and only gets showing a little bit at a time which is really horizontally scalable. I mean let’s do the math when NVME Drive can write at 4gbps so scale that to match the influx of data rate with room to spare. The point is Tesla engineers are going to look for nefarious action, not to worry about corner cases. what a non sequitur argument that is

And the code is not the hard part it’s the scaling in the architecture to handle the rate at which the data will flow.

> Twitter could be created by an undergraduate CS major.

All the codebases will look like they were created by an undergrad CS major and then have accumulated 16 years of edge conditions. And if you pull it all down and try to rewrite it because it is all overly complicated and everyone who built it was wrong: https://fs.blog/chestertons-fence/

Oh, please there’s not that many edge conditions to Twitter for God sakes. It’s not Google.

https://xkcd.com/793/

He has to start somewhere.

Design principles are all the same, no matter what product you are building. Besides that you just bought a "cat in a bag" with very ambitious goals of redesigning it, don't you want your smartest engineers to look at it first? Or what would be your plan if you were in the Musk's shoes right now?

Are you for real bro? they’re gonna go look through that git log and find every instance where Twitter did something shady. I’m betting the farm that they did.

I'm also reasonably sure they're making sure that they're backing up all git repos, to make sure no such commits are tampered with.

Even if your tamper with one repo, you have to basically kill all clones of the repo to get rid of all the evidence

Reply on news.ycombinator.com