mdasen

I find that I don't use a ton of output tokens. I'm usually around 95% cached input, 4% input, and 1% output.

For me, the big thing with MiMo-V2.5-Pro and DeepSeek V4-Pro is that cached inputs are practically free. Kimi K2.7 Code is 53x more expensive for cached inputs which is 95% of my costs.

If I use 95M cached input tokens, 4M input tokens, and 1M output tokens, that'd be: $18 for cached input on Kimi K2.7 Code vs $0.34 with MiMo/DS; $3.80 for inputs on Kimi vs $1.74 with MiMo/DS; and $4 for output on Kimi vs $0.87 with MiMo/DS.

Of all the places where I'm accumulating costs by using Kimi, it's the cached inputs. The real savings with MiMo/DS's price cut is the cached inputs.

Yes, it's a "smaller" (137B) model that competes with Haiku, but it's basically the performance of Qwen3.6-35B-A3B which is 75% smaller and 98% smaller in terms of active parameters (since it's a mixture of experts model). Microsoft should be comparing its model to good smaller models, not Haiku 4.5.

Qwen-3.6-27b is closer to Claude Opus 4.7 than it is to Haiku 4.5 in a lot of benchmarks - and it's way smaller than Microsoft's new model.

Sure, it competes with Haiku, but it shows how far Microsoft is behind lots of other small models that are available.

.

The point of the article isn't "Malawi is poor compared to Europe," but rather comparing Malawi to other countries that were similarly colonized and how other colonized countries have done a lot better than Malawi - despite often having more adversity in their post-colonial existence.

Yes, being exploited will leave you in a bad state, but it's also important to learn why other similarly colonized countries have done a lot better over the past 30 years - what are the conditions and policies that improve things

I too don't want to write OS-specific stuff, but here's some counter arguments.

With egui, it's an immediate mode GUI rather than retained mode and that has trade-offs: https://github.com/emilk/egui#why-immediate-mode. It's going to use more CPU (and battery power), there can be jitter and things shifting after the initial rendering, and other stuff. I think egui is very different from most cross-platform and platform-specific libraries.

With .NET MAUI, you're getting native controls, but you're now using a layer that's trying to use native controls on the underlying systems that don't always align completely. A lot of things act mostly the same across systems, but some things don't totally.

With Flutter, your app is going to be larger in part because you're shipping a rendering engine, runtime, widgets, etc. Does it have the look and feel you want? Maybe. That's a bit subjective. Does it handle all the little things correctly? When I'm using an app, I want it to scroll like how I'm used to scrolling working on my system. If you have differently styled buttons, I don't care, but if the scrolling feels wrong, it's going to annoy me. And there's so many little things.

Frankly, one of the reasons why Electron often does well is that a lot of the little things "feel right" because the UI is essentially a Chromium-rendered web page which users are used to interacting with. But that has downsides too - shipping a web browser with your app and the memory usage.

Heck, Qt apps in Gnome or GTK+ apps in KDE can look/feel "off".

And it'll all depend on your ecosystem. Often cross-platform solutions are lacking in accessibility - sometimes completely missing, sometimes half-baked and it works in some parts and not in others or just is janky. Memory usage is often higher. Many little things that make an app feel right might not be there. Many have slower startup times since they're loading a bunch of stuff that native apps don't need to. And it really depends on what approach the cross-platform library is taking to determine what is going to cause pain.

So you kinda have to pick your poison and what's acceptable to you will vary depending on your goals and tastes. Maybe React Native is the way to go for you with lots of native controls available and the feel that provides and the performance and size is acceptable.

If you create a Flutter or Kotlin Compose Multiplatform or AvaloniaUI app and put it on the web, it's not going to feel right as something like HN does. Right-click, text selection, etc. are all going to be different or missing. If you're creating a solitaire game, maybe that doesn't matter - you get desktop and web in one go and it's not a big deal.

But you have to know what you're building to know if the trade-offs being made are good ones. This isn't meant to sound anti-cross-platform, but as someone who has suffered some pain in this area, I guess I just wanted to impart that it isn't all sunshine and rainbows. Some times it can still be worth it, but just go in with your eyes open.

> electric-drivetrain with onboard gasoline generator

Generally speaking, it's more efficient to power a car using a series-parallel hybrid system than an electric drivetrain with generator (series hybrid) while not really being any more complicated.

In a series hybrid (electric with generator), you're losing energy converting the rotational energy into electric energy. It's better to use the engine's output to power the wheels while it's in an efficient range. It's why Toyota's series-parallel hybrid design offered better mileage than vehicles that (primarily or fully) operated as series hybrids like the Chevy Volt.

> No screens

You can't really sell a car without a screen due to government regulations which require backup cameras (since 2018 in North America, since 2022 in the EU and Japan).

> no assists

Automatic Emergency Braking is going to be required in the US in 2029 (detecting frontal crashes about to happen and automatically braking, including pedestrian detection).

The EU requires even more including blind spot detection and lane-keeping assist.

I certainly agree that cars need knobs and buttons for controls like AC/heat, music, etc. However, it'd be hard to make a car where you aren't putting in a screen and assistive technology. I think a better argument would be to make a car where the screen was simply Apple CarPlay/Android Auto and a backup camera - rather than shoving a lot of garbage UX into it.

> It was about x64 being unable to keep up - independent of Intel’s Fab capabilities which have improved lately.

But the big reason x64 couldn't keep up was that Intel's fab capabilities were horrible. Intel got stuck and couldn't get smaller nodes out and competing fabs caught up and left Intel in the dust.

Apple was able to ship 22nm Intel processors in Summer 2012 while their iPhone processors were 32nm that Fall and 28nm in Fall 2013. Spring 2015, Apple shipped 14nm Intel laptops and later that Fall 14/16nm iPhones. Competitors had caught up and soon TSMC started surpassing Intel.

Yes, Intel's fab capabilities have improved lately, but Intel's fab failures were causing x64 to fall behind. If Intel had retained fab supremacy, x64 wouldn't have fallen behind. I think Apple still likes the idea of being able to build exactly the parts they want (so they can optimize for power, thermals, etc), but Intel fell behind because their fabs stopped being competitive.

It's really interesting how much the AI harness seems to matter. Going from 48% via Google's official results to 65% is a huge jump. I feel like I'm constantly seeing results that compare models and rarely seeing results that compare harnesses.

Is there a leaderboard out there comparing harness results using the same models?

Sure. Dirac is just a fork of the Cline harness and obviously OpenCode could take the same techniques and implement them. I don't know how difficult it would be to implement them in OpenCode, but given that Dirac and OpenCode are both open source, a future version of OpenCode could always be a re-branded Dirac (I'm sure there are ways to implement Dirac's techniques without having to completely replace OpenCode's underlying code base, but this illustrates that at the extreme, they could clearly just take Dirac in its entirety to get the same results).

> Bad actors can strip sources out

I think the issue is that it's not just bad actors. It's every social platform that strips out metadata. If I post an image on Instagram, Facebook, or anywhere else, they're going to strip the metadata for my privacy. Sometimes the exif data has geo coordinates. Other times it's less private data like the file name, file create/access/modification times, and the kind of device it was taken on (like iPhone 16 Pro Max).

Usually, they strip out everything and that's likely to include C2PA unless they start whitelisting that to be kept or even using it to flag images on their site as AI.

But for now, it's not just bad actors stripping out metadata. It's most sites that images are posted on.

In the early days, Netflix benefited from other media companies not recognizing streaming for what it was: their replacement. They licensed content to Netflix cheaply without thinking about how it would impact DVD sales or cable tv subscriptions.

It's kinda like how IBM didn't see the value in software and that let Microsoft become Microsoft.

If this does bypass their own (and others') anti-AI crawl measures, it'd basically mean that the only people who can't crawl are those without money.

We're creating an internet that is becoming self-reinforcing for those who already have power and harder for anyone else. As crawling becomes difficult and expensive, only those with previously collected datasets get to play. I certainly understand individual sites wanting to limit access, but it seems unlikely that they're limiting access to the big players - and maybe even helping them since others won't be able to compete as well.

As someone clumsy, I'm so grateful that my MacBook Air can take a beating. It has one slight dent of about 1mm in the 4 years I've had it and I definitely drop it or knock it off a desk or something a few times a year.

I'll take the extra weight of aluminum (0.3lb, 130g). Yes, someone might say the ThinkPad X1 Carbon is 14", but the 13" MacBook Air actually has a 13.6" screen.

If I were in the market for a PC laptop, I'd definitely take a look at the ThinkPad X1 Carbon, but I'm also not worried about the weight of my MacBook Air. The X1 Carbon Intel ones are on sale right now since Panther Lake will be a huge upgrade coming soon, but even on clearance they aren't cheap. An X1 Carbon with 32GB RAM and 1TB storage (Ultra 7 268V, the cheapest one due to the sale) will cost $1,679 while a similar MacBook Air will cost $1,699 - and the M5 has 48% better single-core performance and 56% better multi-core performance (Geekbench). A 16GB/512GB (Ultra 5 225U) X1 Carbon is $1,538 compared to $1,099 for a MacBook Air - and the M5 has a 74% single and multi core advantage there.

Panther Lake might narrow the performance gap, but early indicators don't seem like that's the case. Even the top of the line Ultra X9 388H sees the M5 with a 36% single-core advantage while the Ultra X9 388H gets 3% faster multi-core. And I'm not sure the higher wattage "H" processors work for something like an X1 Carbon.

The highest non-H Panther Lake processor (Ultra 7 365) sees the M5 get 51% better single-core and 58% better multi-core. Maybe we'll see better, but it looks like Intel isn't closing the gap in 2026.

For fascism, it's not always about getting something you think is a lot. It's about a power relationship. Trump has demonstrated that Nvidia will bow to his will.

It's also potentially an implementation of the foot-in-the-door technique (https://www.simplypsychology.org/compliance.html). It's a common manipulative strategy where you get someone to do a small favor for you which makes them much more likely to do a large favor for you later.

No. When you go into a Costco, Costco is a retailer who bought merchandise to sell to you. When you go to Amazon, a large amount of the products are being sold by third party vendors while Amazon is taking a large cut.

That doesn't seem to be the case across Europe based on current sales.

Looking at marketshare in the EU+EFTA+UK 2025 to 2026:

VW Group went from 26.8% to 26.7%. Stellantis went from 15.5% to 17.1%. Renault Group went from 9.8% to 8.7%. Hyundai Group 8.4% to 7.6%. BMW Group 7.0% to 6.9%. Toyota Group 8.0% to 7.2%. SAIC Motor was flat at 2.0%. BYD 0.7% to 1.9%. Tesla 1.0% to 0.8%.

So it doesn't really seem like BYD is eating into the sales of European manufacturers yet. VW + Stellantis + Renault + BMW + Mercedes + Volvo + Jaguar Land Rover was 66.9% in 2025 and it's 67.1% in 2026, an increase of 0.2 percentage points (looking at just VW + Stellantis + Renault, it was an increase of 0.4pp).

We'll see what happens going forward, but Chinese cars aren't killing it yet. SAIC Motor is flat. BYD is doing very well, but it's a lot easier to grow when you're small. I think that Chinese cars will present challenges, but I'm less sure that it's over for European automakers. Right now, European automakers are marginally increasing their marketshare (probably more noise than anything, but not evidence of decline).

I think BYD is a strong company and I think they'll continue to gain marketshare, but will others? SAIC has seen modest European growth since 2024, but nothing really threatening and they're sitting at 2% marketshare and their modest growth seems to becoming no growth. Chery is really small. Geely is ultra small without Volvo.

So it feels like it's really the BYD story. BYD is the company actually making inroads and growing at a significant rate. And I don't think that a single company can destroy the European auto industry. It's possible BYD could become 10-20% of the European market and that would be a major win for them and make a significant dent in competitors. But do you see them becoming more? Are there other companies that seem promising?

I think the big thing keeping Blazor back is that C# doesn't work well with WASM. It was built at a time when JIT-optimized languages with a larger runtime were in-vogue. That's fine in a lot of cases, but it means that C# isn't well suited for shipping a small amount of code over the wire to browsers. A Blazor payload is going to end up being over 4MB. If you use ahead of time compilation, that can balloon to 3x more. The fact that C# offers internal pointers makes it incompatible with the current WASM GC implementation.

Blazor performance is around 3x slower than React, it'll use 15-20x more RAM, and it's 20x larger over the wire. I think if Blazor could match React performance, it'd be quite popular. As it stands, it's hard to seriously consider it for something where users have other options.

Microsoft has been working to make C#/.NET better for AOT compilation, but it's tough. Java has been going through this too. I don't really know what state it's at, but (for example) when you have a lot of libraries doing runtime code generation, that's fine when you have a JIT compiler running the program. Any new code generated at runtime can be run and optimized like any other code that it's running.

People do underappreciate the JS/TS ecosystem, but I think there are other reasons holding back stuff running on WASM. With Blazor, performance, memory usage, and payload size are big issues. With Flutter and Compose Multiplatform, neither is giving you a normal HTML page and instead just renders onto a canvas. With Rust, projects like Dioxus are small and relatively new. And before WASM GC and the shared heap, there was always more overhead for anything doing DOM stuff. WASM GC is also pretty new - it's only been a little over a year since all the major browsers supported it. We're really in the infancy of other languages in the browser.

I definitely agree with the first point - it's not meant to be the best.

On the second part, I think the big thing was that they needed something that would interop with Objective-C well and that's not something that any language was going to do if Apple didn't make it. Swift gave Apple something that software engineers would like a ton more than Objective-C.

I think it's also important to remember that in 2010/2014 (when swift started and when it was released), the ecosystem was a lot different. Oracle v Google was still going on and wasn't finished until 2021. So Java really wasn't on the table. Kotlin hit 1.0 in 2016 and really wasn't at a stage to be used when Apple was creating Swift. Rust was still undergoing massive changes.

And a big part of it was simply that they wanted something that would be an easy transition from Objective-C without requiring a lot of bridging or wrappers. Swift accomplished that, but it also meant that a lot of decisions around Swift were made to accommodate Apple, not things that might be generally useful to the lager community.

All languages have this to an extent. For example, Go uses a non-copying GC because Google wanted it to work with their existing C++ code more easily. Copying GCs are hard to get 100% correct when you're dealing with an outside runtime that doesn't expect things to be moved around in memory. This decision probably isn't what would be the best for most of the non-Google community, but it's also something that could be reconsidered in the future since it's an implementation detail rather than a language detail.

I'm not sure any non-Apple language would have bent over backwards to accommodate Objective-C. But also, what would Apple have chosen circa-2010 when work on Swift started? Go was (and to an extent still is) "we only do things these three Googlers think is a good idea", Go was basically brand-new at the time, and even today Go doesn't really have a UI framework. Kotlin hadn't been released when work started on Swift. C# was still closed source. Rust hadn't appeared yet and was still undergoing a lot of big changes through Swift's release. Python and other dynamic languages weren't going to fit the bill. There really wasn't anything that existed then which could have been used instead of Swift. Maybe D could have been used.

But also, is Swift bad? I think that some of the type inference stuff that makes compiles slow is genuinely a bad choice and I think the language could have used a little more editing, but it's pretty good. What's better that doesn't come with a garbage collector? I think Rust's borrow checker would have pissed off way too many people. I think Apple needed a language without a garbage collector for their desktop OS and it's also meant better battery life and lower RAM usage on mobile.

If you're looking for a language that doesn't have a garbage collector, what's better? Heck, what's even available? Zig is nice, but you're kinda doing manual memory management. I like Rust, but it's a much steeper learning curve than most languages. There's Nim, but its ARC-style system came 5+ years after Swift's introduction.

So even today and even without Objective-C, it's hard to see a language that would fit what Apple wants: a safe, non-GC language that doesn't require Rust-style stuff.

Is there a congruent DGGS that you would recommend?

> Working outside of did:plc is a choice

What you're saying is: working outside of centralization is a choice. did:plc is a centralized database controlled by Bluesky.

Bluesky talks a big game about decentralization when it's extremely centralized. Everyone uses the centralized did:plc because it's the one way to really make it function. Until very recently, everyone used the centralized Bluesky AppView - and even now, well over 99% do. Bluesky will say things like "the protocol is locked open", but Bluesky could decide to shut off their firehose at anytime (leaving third parties cut off) and could decide to stop taking incoming data from third parties (leaving anyone on non-Bluesky servers cut off from basically everyone).

In a lot of ways, Bluesky is more like Twitter a decade or so ago. It offers APIs that third parties can use to build off of - but at any time, Bluesky could shut down those APIs. Back then, you could read the Twitter firehose and store the tweets and create your own app view with your own front-end if you wanted. Tweets would need to be sent to the Twitter APIs, but that's not really different than your third-party PDS server sending them to Bluesky if you want anyone else to read them.

You aren't open if someone controls the vast majority of a system because at any time they can decide "why are we doing this open thing? we could probably force the <1% of people elsewhere to migrate to our service if we cut off interoperability." Google Talk (GChat) offered XMPP federation and a lot of people bought into the platform because it was open. At some point, Google realized that the promise of openness had served its purpose and closed it off.

And it's important to think about the long-run here. Twitter was that benevolent dictator for a long time. Bluesky is still early and looking to grow - when they want people building off their system, giving them engagement, ideas, and designs they can copy. We're around year-5 of Bluesky. A decade from now after Bluesky builds its popularity on the back of "we're open and decentralized" while making decentralization extremely difficult, will that change? If Bluesky gets to a few hundred million users and then a third party starts looking like a potential threat, maybe they'll cut that off before they have genuine competition.

Maybe that won't happen with Bluesky. Maybe their investors won't care about the potential for a pay day. But if they have control (either through centralization like did:plc or by controlling the vast majority of the network), there will always be the potential for them to break interoperability. If they start monetizing Bluesky, why should they keep hosting, processing, and serving all that data for third party clients they can't monetize? Why shouldn't they stop federating with third parties before a third party becomes competition?

The license file linked provides an exception for 4d and 4e:

As a special exception to the GNU Lesser General Public License version 3 ("LGPL3"), the copyright holders of this Library give you permission to convey to a third party a Combined Work that links statically or dynamically to this Library without providing any Minimal Corresponding Source or Minimal Application Code as set out in 4d or providing the installation information set out in section 4e, provided that you comply with the other provisions of LGPL3 and provided that you meet, for the Application the terms and conditions of the license(s) which apply to the Application.

It's not simply that developers expect to get their tools for free.

So many developers have seen the rug-pulls and exploitation of non-free tools. Build on Oracle and your company will need to hire more lawyers than developers. Even in less-exploitive situations, we've seen a lot of situations where things become many times more expensive. Google AppEngine moved from charging based on usage to charging based on instance hours and some people saw their bills go up 10x. We saw the Unity price increase which proposed a runtime-install fee. We don't want to build off an ecosystem where we have no idea what the pricing will be going forward. We don't live in a world where we can just remain on an old version via a perpetual license. Security vulnerabilities will require upgrading at whatever price a vendor sets for the new version. Incompatibilities with changing environments (like iOS/Android upgrades) will mean having to pay for upgrades at whatever the new price is.

We've seen so many proprietary dead-ends where we invest a lot of time and money into a platform and then poof it's gone. You don't want to have 10 devs spend a couple years building with a tool that just disappears on you. Something small like Skip could easily run out of funding. This gives you a chicken-and-egg problem: you can't be proprietary unless you're huge, but you basically can't get huge at this point unless you're open source because no one will choose you. Skip was ejectable. It was generating Kotlin so you could just start developing two separate codebases in the future, but if you want a cross-platform toolkit and you're worried about a dead-end, you're just going to choose Flutter or React Native or something.

We also don't want a situation where devs are waiting on a vendor. With open source, I can go in and fix something at my company and put in a PR. Even if the PR doesn't get accepted for a while, we aren't stuck.

And it's not just developers. If I'm working at a company and I want to use a paid tool, I'm going to need to get approval for that which can just be a pain. Higher ups are going to want to know that we aren't going to get a rug-pull in the future. Skip was $1,000/year per developer, but that could change in the following year. Companies have gotten rich by offering you a good deal, locking you into their ecosystem, and then raising prices. Higher ups are going to want answers that don't really exist.

Finally, it's hard to know whether something is any good without putting a decent amount of time into it. We often learn things because they're free toys we can play with. I make something fun in my spare time with a free tool and I've learned something new. But I don't want to do that with something proprietary where I might have to deal with licensing. Yes, sometimes there's exceptions for non-commercial use, but sometimes the line is blurry on that - what if I have a tip jar. We don't want to deal with that.

A development kit like Skip isn't a hammer. A hammer will continue to be a hammer even if the company goes out of business. When we're choosing tools, we're not just making a bet on what it is, but also what it will be in the future. If it's going to become abandoned in the future, it'll be a lot less useful. When you're comparing tools at a hardware store, you might not make the best choice, but you aren't going to find out 18 months later that your hammer is incompatible with all nails going forward. You're also generally only out the price of the hammer, not out the price of the hammer plus 18 months worth of work that you need to redo.

Weird, doesn't work in Brave (macOS) for me. Did you enable a setting? Brave says it's up to date when I check.

> I assume the dearth of other options was because macOS doesn't do fractional scaling

Except it does? I have a 14" MBP with a 3024x1964 display. By default, it uses a doubling for an effective 1512x982, but I can also select 1800x1169, 1352x878, 1147x745, or 1024x665. So it certainly does have fractional scaling options.

If you connect a 4k 2160p monitor, you can go down or up from the default 1080p doubling (https://www.howtogeek.com/why-your-mac-shows-the-wrong-resol...). If you select 2560x1440 for a 4k 2160p screen, that's 150% scaling rather than 2x (https://appleinsider.com/inside/macos/tips/what-is-display-s..., see the image where it compares "native 2x scaling" to "appears like 2560x1440").

This is what basically everyone else has done over the past decade. Google used to put a different background behind ads in its search (https://www.fsedigital.com/wp-content/uploads/2023/11/Google...). It made it really easy to tell what was an ad and skip over it quickly. Now it's a lot harder to quickly notice what's an ad and what isn't.

Sites used to have banner ads. Now they show posts that look exactly like the organic posts in your feed, just with a small "sponsored", "promoted", or "ad" mark somewhere. Half the time the post is large enough that it takes up my entire screen and the "sponsored" mark is below and off-screen.

If you go on Amazon, the "sponsored" text is much smaller and light gray rgb(87,89,89) while the product text is near-black rgb(15,17,17). They want to make the sponsored text less visible. Sometimes it's even unclear if the sponsored tag applies to a single product or a group of products.

It's shocking that Apple hasn't done this trick yet when everyone else started doing it years ago.

I think that's the thing: Apple is good at very little, but they seem like they're good at "everything else" because they don't do much else. Lots of companies spread themselves really thin trying to get into lots of unrelated competencies and tons of products. Apple doesn't.

Why does a MacBook seem better than PC laptops? Because Apple makes so few designs. When you make so few things, you can spend more time refining the design. When you're churning out a dozen designs a year, can you optimize the fan as well for each one? You hit a certain point where you say "eh, good enough." Apple's aluminum unibody MacBook Pro was largely the same design 2008-2021. They certainly iterated on it, but it wasn't "look at my flashy new case" every year. PC laptop makers come out with new designs with new materials so frequently.

With iPhones, Apple often keeps a design for 3 years. It looks like Samsung has churned out over 25 phone models over the past year while Apple has 5 (iPhone, iPhone Plus, iPhone Pro, iPhone Pro Max, iPhone 16e).

It's easy to look so good at things when you do fewer things. I think this is one of Apple's great strengths - knowing where to concentrate its effort.

Where does it say that it won't be white-labeled?

Yes, Apple is acknowledging that Google's Gemini will be powering Siri and that is a big deal, but are they going to be acknowledging it in the product or is this just an acknowledgment to investors?

Apple doesn't hide where many of their components come from, but that doesn't mean that those brands are credited in the product. There's no "fab by TSMC" or "camera sensors by Sony" or "display by Samsung" on an iPhone box.

It's possible that Apple will credit Gemini within the UI, but that isn't contained in the article or video. If Apple uses a Gemini-based model anonymously, it would be easy to switch away from it in the future - just as Apple had used both Samsung and TSMC fabs, or how Apple has used both Samsung and Japan Display. Heck, we know that Apple has bought cloud services from AWS and Google, but we don't have "iCloud by AWS and GCP."

Yes, this is a more public announcement than Apple's display and camera part suppliers, but those aren't really hidden. Apple's dealings with Qualcomm have been extremely public. Apple's use of TSMC is extremely public. To me, this is Apple saying "hey CNBC/investors, we've settled on using Gemini to get next-gen Siri happening so you all can feel safe that we aren't rudderless on next-gen Siri."

This is good, but it doesn't necessarily mean that Tailwind is out of the financial difficulty that we talked about yesterday. You can sponsor Tailwind for as little as $6,000/year. 29 companies were already sponsoring Tailwind including 16 companies at the $60,000/year level. Maybe Google AI Studio has decided to shell out a lot more, but it could also be a relatively small sponsorship compared to the $1.1M in sponsorships that Tailwind is already getting. Google has deep pockets and could easily just say "f-it, we're betting on AI coding and this tool helps us make UIs and $2M/year is nothing compared to what we're spending on AI." It's also possible that the AI Studio team has a small discretionary budget and is giving Tailwind $6,000/year.

It's good, but it's important to read this as "they're offering some money" and not "Tailwind CSS now doesn't have financial issues because they have a major sponsor." This could just be a 1-5% change in Tailwind's budget. We don't know.

And that's not to take away from their sponsorship, but on the heels of the discussion yesterday it's important to note that Tailwind was already being sponsored by many companies and still struggling. This is a good thing, but it's hard to know if this moves the needle a bunch on Tailwind's problems. Maybe it'll be the start of more companies offering Tailwind money and that'd be great.

It's part of a larger move by GS to exit consumer banking.

Popularity can mean multiple things. Are we talking about how frequently a database is used or how frequently a database is chosen for new projects? MySQL will always be very popular because some very popular things use it like WordPress.

It does feel like a lot of the momentum has shifted to PostgreSQL recently. You even see it in terms of what companies are choosing for compatibility. Google has a lot more MySQL work historically, but when they created a compatibility interface for Cloud Spanner, they went with PostgreSQL. ClickHouse went with PostgreSQL. More that I'm forgetting at the moment. It used to be that everyone tried for MySQL wire compatibility, but that doesn't feel like what's happening now.

If MySQL is making you happy, great. But there has certainly been a shift toward PostgreSQL. MySQL will continue to be one of the most used databases just as PHP will remain one of the most used programming languages. There's a lot of stuff already built with those things. I think most metrics would say that PHP is more widely deployed than NodeJS, but I think it'd be hard to argue that PHP is what the developer community is excited about.

Even search here on HN. In the past year, 4 MySQL stories with over 100 point compared to 28 PostgreSQL stories with over 100 points (and zero MariaDB stories above 100 points and 42 SQLite). What are we talking about here on HN? Not nearly as frequently MySQL - we're talking about SQLite and PostgreSQL. That's not to say that MySQL doesn't work great for you or that it doesn't have a large installed base, but it isn't where our mindshare is about the future.