Yes, Google is profitable now. Tremendously so. But they're at risk of losing revenue and ceasing to be profitable as people cease using Google search and switch to asking questions of their AIs. So to retain their position as the place people go first for information, they have to stay ahead of the AI race. Well, they could also just sit back and wait to see if their competitors are overwhelmed by the query volume, but that risks losing traffic and then having to win it back. It's much better to keep it. And Google is better-positioned to win this race than its competitors both because of its existing infrastructure and expertise and because it already has the eyeballs.

In addition, you seem to be assuming that doubling serving capacity means doubling cost. Clearly Google is not planning to increase their annual operating expenses by 1000X. As the summary actually says in the third paragraph, Google is also going to have to improve efficiency to achieve the growth rate, with better models and better hardware. This is what the AI chief is challenging the employees to do; he's not challenging them to write bigger OPEX checks, that's his job.

I know a few. I don't know what it may or may not mean. It may be relevant that the ones I know used a community-based approach, where groups of homeschooling families worked together to create something akin to a school, with different parents teaching different subjects. This meant that while the kids socialization groups were small, they did hang out with and learn with other kids, not just their siblings.

It's more than that. Research into the possibility of a link between vaccination and autism has been done, and no correlation found. This is evidence that there is no connection and it's entirely different from a case where no research has been done. One is evidence of absence, the other is absence of evidence. The GP is equating them, but they're not remotely the same thing.

Show me all of the studies that have evaluated the correlation between FSM action and autism. There has been a lot of research on the possibility of a correlation between vaccination and autism, and no evidence of correlation has been found. There is an enormous difference between "We've looked hard and found no connection" (evidence of a negative) and "We haven't looked at all" (lack of evidence).

In addition, there's no need for the CDC to debunk a claims that are not being made, or non-harmful claims. To pick a less-ludicrous example, there's no significant population claiming that eating grapes causes autism, so there's no need for the CDC to address it. Further, if there were an anti-grape lobby touting a connection with autism, the CDC probably still wouldn't need to address it because some people avoiding grapes doesn't create significant health risks to others.

But there is a significant population claiming -- against strong scientific evidence -- that vaccines cause autism, and that claim is causing them to reject vaccines, which does create significant health risks for others. So, the CDC absolutely does need to address it, since public health is their job.

Your analogy is terrible, in every way.

I used to work for Sling TV, and you basically have that backwards. ESPN is the part of Disney's package that people are willing to pay money for. The shutdown and negotiations every year is just Disney forcing the various providers to pay for and carry their other channels. That's why Disney always holds these negotiations during football season, so if they have to shut someone down their customers actually care. Every year viewership on Disney's other channels (and non-sports channels in general) is lower, and the prices that the content producers require goes up. Scripted television is in serious decline, and Hollywood is using sports fans to prop it up.

As an example, If you don't care about sports you can get Disney+ without ads for about $12 a month. Disney will happily throw in Hulu for that same price if you will watch some ads. You can binge watch the shows that you care about and then switch to another channel. Heck, you can buy entire seasons of their shows ala carte. You can't get ESPN however, without paying at least $45/month, and that's with a package with no non-Disney channels and chuck full of ads. For the record, that's basically what the streaming services are paying Disney as well. When I worked at Sling the entirety of the subscription fees went to the content companies (primarily Disney). There is essentially no profit in cable packages. All of the profit has to be made up somewhere else.

People that aren't sports fans, especially if they are entertainment fans, tend to believe that scripted programming is carrying sports, but it is the other way around. That's why AppleTV, which has spent over $20 billion creating content for their channel has about as many subscribers the amount of people that typically watch a single episode of Thursday Night Football, the worst professional football game of the week. Amazon Prime pays $1 billion a year for that franchise, and it is a bargain compared to creating scripted content. Apple makes great television that almost no one pays for. The other content providers are in the same boat. You'll notice, for example, that Netflix's most expensive package is $25/month, and the revenue per user in the U.S. is around $16. That's ad free. The lowest promotional price you can pay for ESPN is basically twice that, and it always comes with ads. What's more, sports fans tend to actually watch the ads.

Sling is selling day and weekend passes to people because it knows that most of its customers only have their service to watch the game. No one is watching linear television anymore, but the content creators have built their entire business around the idea of having a channel that they fill up with content. Even with Sling's ridiculous prices they can typically watch the games they want to watch for less than maintaining a subscription.

I have spent most of my adult life in the sports world, but I don't watch sports. I personally believe that in the long run sports television is probably going to end up uncoupled from scripted television. I think that is going to be very bad news for people that like scripted television.

Compared to what was available before, it is quite impressive.

The negative feedback is prompted by the fact that AI is constantly being shoved into every one of our orifices 24/7 by every vaguely tech-related company as if it was the second coming of Jesus. To justify that amount of social pressure, it would indeed have to be quite a bit better than it actually is, and that's why people aren't impressed.

"The fact that people are unimpressed that we can have a fluent conversation with a super smart AI that can generate any image/video is mindblowing to me,"

Mindblowing is that companies make all the claims about AI that are 100% unfounded. "generate any image/video"... No it can't. "fluent conversation"... Unless I have to constantly remind it about the thing it said two prompts ago that it forgot. And I PAY for AI access.

It's not anywhere near impressive. It's a party trick at best and dangerously misleading at worst.

Bullshit. I live in the western US and have regularly driven through some of the least-populated areas of the country, but I've never seen an area you can go 500 miles without encountering any infrastructure. You might be able to accomplish it if you take careful note of where the truck stops are and go out of your way to avoid them, but on any realistic route you'll encounter truck stops -- if not towns -- at least every 150 miles.

As for charging infrastructure, if you stay on the interstates I don't think there's anywhere in the country you can go more than 100 miles without finding a Tesla Supercharger. Those aren't designed for truck charging, but this demonstrates that building out the infrastructure isn't that hard.

They certainly seem to have completely missed Article I. You know, the part that says that the legislature makes the laws? Even if you think restricting AI regulation to the federal government is a good idea, the right way to do it isn't with an executive order to set up a DOJ task force aimed at litigating state AI regulations out of existence based on complex legal theories about interstate commerce. The right way is for Congress to pass a law barring states from regulating AI. This is simpler, cheaper and should invoke public debate about the issue, which is how things are supposed to be done in constitutional republics.

I don't even think Trump is taking this route because he and his advisors don't believe they have the votes for it. I think they're doing it this way because they don't even consider governing through legislation rather than through executive power. Granted that Congress is fairly dysfunctional, but they actually can and do make laws... and the way to fix the dysfunction is to work the system.

You mean, why does Linus keep agreeing to be interviewed, and then reply to straightforward questions with the obvious answers?

What would you rather he do? Refuse to be interviewed, or maybe make up unexpected answers just to be edgy?

The above was already quite long, but allow me to add a bit :-)

I spent a few minutes looking for the state of the art in C++/Rust interop for contexts that don't have a nice intermediary like binder. It turns out that the situation isn't as bad as I thought. The CXX project enables automatic generation of bi-directional definitions between Rust and C++ and is being used at scale by the Chromium project and that seems to be going pretty well.

There's also a Google-funded Rust Foundation project to define a better solution, though I don't see what, if anything, has happened since it was announced last year. Hopefully that's because there's a small group working too hard to waste a lot of time talking about it.

The reason I went to look is that my new team (I left Google a couple of months ago) might need such a thing. I've been asked to define an API that would benefit from being implemented in Rust and usable from C++ and Rust.

Telling people that vaccines are bad, ensuring that any parent who wishes to refuse to vaccinate their children is fully supported in that decision, and working to make vaccines harder to get, more expensive and more painful (RFK Jr. wants to separate the MMR vaccine into three shots, each of which will still require three injections, so kids will have to get 9 shots to be fully vaccinated instead of three).

This is similar to their plan to fight inflation by imposing tariffs and forcing the Fed to lower interest rates in spite of rising inflation (note that this last part hasn't really happened yet -- the interest rate cuts have been measured, cautious and justified by economic conditions -- but Trump is working on it). Though to be fully fair, by making the tariffs arbitrary and capricious so that business leaders are completely unable to plan, Trump is also causing a contraction in US economic activity that might eventually generate significant unemployment, which actually does reduce inflation. I see no corresponding "silver lining" in the mumps plan, though.

And, ultimately, slavery was a far less efficient and effective economic system. One might think that keeping a big chunk of the populace poor is efficient, since you're not "wasting" a lot of production on providing them with unnecessary goods and services, but it's really not, at least not since the industrial revolution. I think the core reason that it's so inefficient is the same reason that Marxist communism is inefficient: From an economic perspective, both systems value the masses only for their physical labor, and fail to cultivate and take advantage of their brains, which also actually tends to reduce their labor output. Harnessing the distributed ingenuity of your workforce requires giving your workforce some reason to exercise ingenuity and some way to benefit from doing so.

It's going to be interesting (or maybe terrifying, or maybe just sad) to see what happens when we fully automate ingenuity, too, which will mean that the system no longer depends on or benefits from distributed ingenuity because the machines are smarter and think faster, just as the machines are already stronger and indefatigable.

I don't think vibe coding is going to last long as a thing, because it's just a sort of intermediate step to telling the AI to do what you want and having it do that. Right now, people are telling the LLM to write code to accomplish a thing and then running the code to see how it works, then telling the LLM to refine it, but that's a lot of unnecessary extra steps. I'm sure that in the not-too-distant future people will just tell the LLM what they want to do, which may require creating a custom user interface to make user interaction convenient, and may require creating databases or performing network queries or whatever, and the LLM will understand what they want, and do it.

In that future, it's possible that the LLM may generate code to implement the requested functionality, but if it does so that will be a compute-saving shortcut, essentially a way to cache the LLM's work and be able to repeat it with less effort. There won't be any need to show any of the code to the user, or even tell the user that the LLM chose to generate some code.

As an aside, the whole notion of leaning "prompt engineering" is another intermediate step that will die. The whole point of natural language-capable AI is that it will be able to understand what humans want when we express ourselves as we would to other humans. As the LLMs get more capable, it will become less necessary to treat them as something different from an entity that is fully capable of understanding and acting on human communication.

One of the things Android did very right with the Rust transition was to set up a small team of people who were entirely focused on Rust support. It wasn't a large team, only 2-6 people (it varied over time) out of approximately 1500 engineers. Having that core team who either were or became deep Rust language and toolchain experts was critical to smoothing the path for everyone else. It provided a group that had the knowledge and bandwidth to solve the problems that inevitably came up, as well as to offer advice and code review support to the early adopters.

That group no longer provides code reviews and design advice because Rust knowledge is now widespread enough that teams have their own, homegrown, Rust experts (not people designated as Rust experts, just engineers who became enthusiastic and dived deep), but the group still exists to resolve complex technical problems with language integration and to work on improving tooling and performance.

I think any shop adopting Rust (or any new language or complex tool) needs to have some people who become deeply expert in it and are allowed the time and freedom to support others who are picking it up.

So does Android. Google has been a primarily-C++ shop since its inception and although I'm not sure if Android had a lot of C++ in it when Google bought Android in 2005, it definitely became a C++-based system as soon as that happened.

The highly-segmented architecture of Android really helped facilitate the transition. Most of Android is structured as a web of collaborating services that communicate through a common language-independent [*] IPC mechanism (binder). Implementing Rust binder IDL generation and support libraries was a moderately big job, but once that was done it was easy to begin writing new system components (or replacing existing system components) in pure Rust, generally without any unsafe blocks at all.

If your code runs as a monolithic process, or has a lot of different IPC mechanisms, or uses a lot of existing libraries, it will be a lot harder, and the benefits will come slower. You'll have to wrap a lot of C interfaces in Rust -- and they will have to be C, not C++, since there isn't a good way for Rust to interoperate directly with C++. People are working on that, but it's a very hard problem and at present the best option is to layer a C interface on top of your C++ code, then wrap a Rust interface around the C interface. Yuck. Or, in the alternative, insert some other language-agnostic boundary between them.

So in a lot of ways Android got lucky because of its modular architecture and single, language-agnostic IPC mechanism. OTOH, that wasn't really "luck", it was a lot of work, done for good reasons, one of which was cross-language compatibility, notably between Java and C++.

[*] Language independent-ish, maybe I should say. The binder IDL is definitively Java-based, but this maps fairly nicely onto OO languages that support common primitive types (int, char, enum), basic composite types (array, vector, class/struct, string (which is just a vector, but used enough to be worth treating as a first-class thing)) and Java-like methods (fixed argument list, single return value). Further, it's based on "old" Java, before Java acquired functional extensions, when doing things like passing method references as argument was uncommon, and therefore not supported. So it's moderately-expressive but avoids things that get weird and complicated. My one big complaint about it is that I wish it supported unsigned integer types. That's my biggest gripe with Java, too.