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.