uvdn7

Concept products are not real products. Their purpose is often to make a point, to prove something is possible, to make a brand look cooler, or just to have fun. I don't think I would ever see this car flying on the road myself. But part of me likes the fact that there are people out there making crazy things like this. It is more fun.

> Large Scale Codebase Migrations and Optimizations: Argon agents are working on migrating C/C++ codebases to Rust across Google—scaling from tens of thousands of lines in core libraries like re2, libgav1 up to 800K+ lines for the Fuchsia OS Zircon kernel.

To me this is way more significant than other random c++-to-rust-AI-rewrite. If they can pull it off on core C++ libraries en masse, I don't know if C++ will still be relevant in a few years.

I look forward to a post from google on this effort.

> But solving problems is only a tool and proxy for achieving the primary goal of conceptual understanding and insight. Forgetting this in the world of AI may turn the tool against the primary goal.

I will quote Richard Feynman - “the prize is in the pleasure of finding the thing out, the kick in the discovery”.

I am not saying that should be the case for everyone in every discipline. But if there is one subject that is mostly pure curiosity driven (instead of worldly impact), it is math. Robbing them the primary motivation is brutal.

If all problems are solved by a machine, what do we have left to satisfy our curiosity, our desire to explore, and where can we find the pleasure of “figuring the thing out”.

This is something AI would never take away from us.

It reminds me of Clay Christensen’s book How to Measure Your Life. In one of his talks, he talked about how companies get killed because they optimized for the wrong/short-term metrics. What we are seeing with AI could be a supercharged flavor of Innovator’s Dilemma, where organizations optimize a pre-existing set of success metrics while missing the bigger picture because some previous assumptions no longer hold.

I really like the article. It’s not trying to sell fear (which does sell); it doesn’t paint the leaderships as clueless. Nobody knows what is going to happen in the future. The article might be wrong on a few things. But it doesn’t matter. It points out a few assumptions that people might be missing and that is great.

Is the non-trivial amount of time significantly less than you trying to ramp up yourself?

I am still hesitant using AI for solving problems for me. Either it hallucinates and misleads me. Or it does a great job and I worry that my ability of reasoning through complex problems with rigor will degenerate. When my ability of solving complex problems degenerated, patience diminished, attention span destroyed, I will become so reliant on a service that other entities own to perform in my daily life. Genuine question - are people comfortable with this?

You are also not locked down in C++. There are already a handful of coroutine and async runtime implementations out there.

> I’m not totally sure if this is a GOOD idea to add to the c++ standard

What are the downsides? Naively, it seems like a good idea to both provide a coroutine spec (for power users) and a default task type & default executor.

I am not a native speaker and I joke about my typos and grammar mistakes being the evidence that none of my code or post is AI generated. Sorry about the typos. I just fixed all the ones I can find. Hope it's better now.

Neat. It certainly makes oncall and maintenance easier! It is likely more resource efficient by e.g. minimizing idle compute, maximizing cache hit rate, etc.

Love it! I wonder if the team knew this explicitly or intuitively when they deployed the strategy.

> We created a rule in our central monitoring and alerting system to randomly kill a few instances every 15 minutes. Every killed instance would be replaced with a healthy, fresh one.

It doesn't look like they worked out the numbers ahead of the time.

I was thinking the same. There are many mutexes out there, some are better at certain workloads than the rest. DistributedMutex and SharedMutex come to mind (https://github.com/facebook/folly/blob/main/folly/synchroniz..., https://github.com/facebook/folly/blob/main/folly/SharedMute...) Just like hashmaps, it's rarely the case that a single hashmap is better under _all_ possible workloads.

Math, sure - doesn't the understanding of physics also go through changes? Do we really understand the reality of the world; or how do we know our current understanding of it won't change?

The same happens in work place as well, when multiple people have similar ideas and it is unclear or impossible to credit who came up with the idea first. It is often the case that people with shared context had similar ideas independently when facing the same set of problems.

I have the impression that it is controversial about who invented the hybrid logical clock first as well. Although most people cite the Kulkani paper from 2015 I think?

Do people know who else claims to invent HLC first?

The biggest difference between automatically keeping an MV up to date vs keeping indices up to date is that the write amplification of the latter is a function of the index count you have, while the former is a function of data and query. It’s easy to come up with cases when users update a single db row, and you end up having to update millions of rows in a MV (eg the every row in the MV has a name “Rob” and Bob changes his name).

I read the timely dataflow which underpins materialize.com. It seems like we don’t necessarily need the support of loops, which timely dataflow allows, for regular SQL, which is a DAG of operators. It appears that as long as the database supports snapshot reads, one can have a push-based query execution to enable incremental MV updates. The problem, I think, is still in the write-amp-as-a-function-of-data, which is unbounded. It is very cool regardless.

The technique can be used for cache invalidation as well, given the data cached needs to be described in SQL, which seems reasonable.

Apple claims that its Weather App has integrated DS’s features. However, for a few times it’s ridiculously wrong. It said it’s cloudy when it’s raining onto the very phone, which I don’t remember happened to DS. Forecast for the next hour feels like as accurate as forecast for next month. I live in New England. I am going to miss DS a lot.

I think it boils down to cost. Digital content is extremely cheap to replicate and distribute; hence the quality of the content is assumed to be lower (and it’s usually the case). One doesn’t have to put in too much effort in producing digital content.

Now with ChatGPT, it’s even more so than ever. It’s practically free to produce digital content.

On the other hand, even by just printing out a doc increases the cost of replication and distribution significantly (compared to pure digital replication); hence the quality of the content is assumed to be higher.

Rust borrows c++’s modern memory model verbatim.

C++ is a language that keeps innovating besides many legit reasons to hate the language. Having more competition is good. I would expect more rust/{your favorite language} concepts to show up in future versions of c++ (once proven to be a good idea in most cases).

By this reasoning, shouldn't Tesla pay users instead to enable FSD and collect data for them?