Aiming to reduce the number of billionaires is not sound economic policy. You are taking away the incentives that have generated so much progress and job creation in America. Mostly when people complain about billionaires it’s either sour grapes, or a certain type of billionaire they disagree with politically.
The way all these billionaires have built up their wealth is by retaining a certain percentage of stock in the companies they built, and then the market cap of these company got into the billions and sometimes trillions.
Let’s assume a founder has 10%. There are two options to prevent them from becoming a billionaire. Either that company cannot grow past a 10 billion market cap. That would destroy retirement for most normal Americans. The other option is to force the founder to liquidate to pay taxes. If so, then yes, they would stop further building out these companies at a certain market cap once they have no real stake or say in them anymore. Why would they work for free once they are at the limit. I wouldn’t and I think almost nobody would.
I imagine this works just like with electricity. You have generation capacity, with commercial entities buying or owning generation capacity and selling the resource to consumers through community owned last mile infrastructure. The sellers need to tally up and reconcile/settle their generated capacity at some frequency (not sure if daily, monthly, yearly).
In a few years, Claude Mythos will be remembered as the moment C++ died. I am serious, very senior people are really scared of LLM found vulnerabilities and are pushing strongly for Rust.
In a few years probably no one will be thinking or talking of Mythos any longer, as it is just the next marketing item in the never ending chain of items to be released as the next scary thing.
There is no credible path towards stopping progress on AI. Nobody knows exactly how this will play out. But whichever way it turns out, being an skilled AI practitioner will give you strictly more options than not being one.
> It's asking an author to suddenly become an editor.
I think that’s right, and what is needed. It still gives a significant speed up for coding, while still keeping the output human maintainable.
There is the idea that the agent will just produce binary code directly at some point. I don’t know if it ever comes to that but for now I’m in the ‘I’ve become an editor’ camp.
The time it takes you to review the code the LLM produces is the same amount of time it would take to just write the code yourself. There's no speedup to be had using these things, despite what many claim.
Strongly disagree. I know my codebase well, I know what I'm expecting before I ask Claude to do it, and I tell it what I'm expecting. I might tell it roughly what I want, have it make a plan, review the plan and ask for changes if necessary, then execute.
This way I don't need to scrutinize every detail, I just look over the big picture. I also care a lot more about the big picture - architecture and data flow etc. Basically if you view your codebase as a tree I care much more about the trunk and the big branches than I do about the smaller branches and particularly the leaves. So the details of some little leaf function somewhere are fairly insignificant, it's trivial to change at any time. As long as it works and isn't unreasonably slow it's fine.
Working this way I can get things done in minutes or hours that would previously take days or even weeks.
I'll bet you know it because you wrote and/or worked on it manually, likely over a period of years. The odds of you knowing a slop codebase that well, or even particularly at all, are much lower.
Let me share a hot take. I am deliberately taking this somewhat to the extreme, so please attack the idea not the person. Looking for thoughtful replies and good counterpoints, rather than language zeal.
Let's assume that you need to write a program with a given set of requirements, and that you have a magic wand that can instantiate a high quality implementation of the program in any programming language instantaneously and for free. My hot take is that you would not want to choose Go, and you would likely want to choose Rust.
The Go implementation will have higher memory and CPU consumption due to garbage collection, while still being subject to memory bugs. The Rust implementation would be as efficient as possible on the given hardware with minimum memory/CPU, and it would be immune to memory bugs.
In my view, the biggest challenge with Rust, and where Go wins, is the relative difficulty of writing in Rust as the language is significantly more complex. With LLMs this is becoming a non-issue, and we are getting ever closer to having this magic wand (I'd argue that for smaller programs the wand already exists today). The article advocates that Go has excellent readability. I agree that Go has trivial syntax, but given that it's so verbose, I actually find it easier to read Rust code. Its higher expressivity allows you to see the higher level intention of a piece of code more easily.
Many of the other benefits the article mentions for Go are equally applicable to Rust: compiler error messages are super detailed and a great help to coding agents, auto-formatting, a great language server, and a package ecosystem.
I guess from a pure language POV, one might argue that rust leaves humans with more opportunity to add abstractions that are too clever and too hard to wrap your head around. That doesn't feel like a strong argument, though.
Then there is of course the ecosystem, where go maybe has better libraries for some stuff (while rust may have better ones for other things).
Pretty much all of the AI weather prediction models are trained on ECMWF ERA5, which is kinda like a numerical weather prediction model run to forecast at t=0. ERA5 is historical weather data, but it’s a “reanalysis” of it.
Indeed, you can imagine this as some sort of advanced physics-based interpolation of various measurements (land stations, satellite data, ...) to fill in every cell in a latitude-longitude grid. This is not only used for ERA5 (training data for the models), but also to determine the initial conditions for every grid cell which are used to roll out the forecast. So AI weather models depend greatly on the NWP/physics used in for reanalysis and initial conditions. That being said, there is also research being conducted in training models straight from the raw data (weather stations, satellite, ...), thus bypassing the "interpolation" step.
Yeah. I can’t remember names off the top of my head, but there are a few companies, and I think many researchers, working on AI “data assimilation” for this.
ECMWF has an experimental AIFS direct observational prediction model (AIFS-DOP) that has become competitive with their physics based IFS model on certain metrics just in the past year.
I'm interested in understanding wheater prediction models because accurate wind forecasts make a big difference to my personal life (sports).
Is there a good overview to learn about the current models, which all just seem like cryptic acronyms to me? in apps like Windy etc.
WRF, TRRM, IK-HRRR-3km, ECMWF-9km,...
I understand by now that small grid cells are better for local prediction and that thermic winds are mostly missing from them all.
Ask your favorite AI to give you a crash course, but to start the main models you need to know are the GFS and the ECMWF. In the US where available in high res, the HRRR is excellent, but doesn’t forecast very far out. The PWG/PWE 1km PredictWind models are also very good at picking up land based features and other more precise patterns. If you are in the US everything else is probably not super relevant.
Any advice will really depend on where you live and the dominant source of local error. These are all good options for the US and if the one main source of error is near surface winds around complex terrain then you can also look into WindNinja from the National Forrest Service.
Historical weather data is discrete. You need continuous state for weather modelling which is currently achieved through conventional reforecasts using those historical observations.
> But it’s tough to engineer much these days. Instead I find I’m PM’ing the bots more than solving problems.
I’m genuinely curious about your perspective as I have almost the diametrically opposite view. I love chatting with the bots as they can build the thing I want, how I want it, much faster than I could. The output still feels mine. Maybe not line by line, but definitely architecturally. The speed makes me feel, sometimes, almost superhuman.
Do you take emotional ownership in the shape output artifact itself, or merely that it works?
>I love chatting with the bots as they can build the thing I want, how I want it, much faster than I could. The output still feels mine. Maybe not line by line, but definitely architecturally.
The output, in my case, feels just as mine as the toppings I tell my local pizza store to add to whatever they're about to cook for me. It's tasty, and fills my stomach, but I didn't make it. I ordered it.
Ok. I had pizza last night. It was delicious. Most meals are packaged protein workout food. But I have a griddle and I love to make brunch, burgers, sliders whatever.
A lot of my job is really pizzas. Massive scale pizzas but still pizzas. God I hate making pizzas. Now I don’t really have to. That means I can focus more on a perfect burger. Or cooking a massive brunch for a crowd of friends. (Think: refactoring some giant hole that 5 years of pizza dug us, or rearchitecting an application rather than just porting it).
I’m definitely in the vocation not job position. I would do this even if we got post-scarcity utopia tomorrow.
I just remembered I used to make pizzas in college if they were short and I drew the short straw. Fuck me that was soul destroying. Much better to be working the bar.
reply