It's mostly that I believe in Mojo having a strong future and I wanted to try it a bit. And after a while it felt like I was committed.

Code at: https://github.com/boxed/turbokod

I've used Claude a TON to build this, I freely admit. It started out as an experiment on how good Claude was at porting the C++ codebase for TurboVision to Mojo (fairly good), and then if I could build a simple editor, then I sort of got carried away and wondered if I could replace my daily driver PyCharm.

I'm now on ~4 days of using this as my daily driver, so it's going well. For Django development I did have to make my own LSP with Django special features too: https://github.com/boxed/iommi_lsp

I do like the pastiche software advertisement page, the coupon cutout is a nice touch. Did you do that with Claude too, or was that hand-rolled?

Claude code, second attempt, plus some editing of course.

Oh yes. We've seen so many US invasions for the purpose of regime change end up with prosperity for the citizens of those countries.

South Korea, Japan, Germany, France, Belgium, Afghanistan (although Biden fucked up and pulled out), and Iraq. That's a pretty impressive list.

Should the Cubans that will inevitably be killed along the way be thankful as well? Or the Cubans currently suffering due to the blockade?

Even for clearly despotic regimes, overthrowing them is not the obviously right thing.

And yet, it's up NOW.

It's obviously hard to say how accurate these numbers[1] are, but it looks like Twitter has doubled their workforce from its lowest following their mass layoffs. It might be stable again now because they hired the workforce required to actually keep it running.

[1] https://www.demandsage.com/twitter-employees/

Ok? But it's still like 1/3.

Yes, which would allude to sentences 2 and 3 in my original comment.

Seconded. Coming from MySQL this is a huge regression that makes Postgres look like something from the 80s. I still wonder why this isn't seen as the absolutely highest priority.

I have not ran MySQL for some years but it at least used to have exactly the same issue. Upgrading a database with MySQL can take a long time if you have many tables. The main difference is only really that PostgreSQL does it with a separate tool, pg_upgrade, while MySQL does it as part of the main binary.

For both MySQL and PostgreSQL you will need to use some kind of logical upgrades if you want no downtime.

No, the main difference is that MySQL bundles the code needed to interact with the old db version in the newer server binaries (effectively by not changing the on-disk binary format!) while pg_upgrade requires you to have both old and new installs living side-by-side to reuse logic/code from old binaries. It is a more bulletproof method and less susceptible to bugs and (upstream) developer errors, but is (or at least can be) harder for the sysadmin+dbadmin.

(For example, ports under FreeBSD doesn’t let you install multiple Postgres versions as they are marked as conflicting packages so installing one necessarily uninstalls the other. The saving grace here is that most (virtually all) FreeBSD installations have root on ZFS and you can employ ZFS snapshots (via the hidden .zfs folder) to access the old binaries after upgrading to the new postgres version, but not many people know this trick!)

MySQL has advocated for decades spinning up a replica with the upgraded version, waiting for it to catch up to master before promoting it to the new master. You can do the same thing with Postgres.

Exactly, MySQL and PostgreSQL are the same here. Maybe one is a bit faster than the other at doing major version upgrades but the behaviours are quite similar.

They don't change the on-disk structure all the time though...

Mostly because MySQL development is slower.

Even when MySQL development velocity was more rapid, they maintained binary table format compatibility across major version upgrades the vast majority of the time. Literally the only exception I can think of, which necessitated a table rebuild, was the fractional timestamp storage change when going from MySQL 5.5 (2010) to 5.6 (2013).

Probably because it's an open source project and apparently none of its users cared about this feature enough to develop it or fund it.

It is also a bit tricky tradeoff. You do not want to be stuck with the same data format forever. So databases like MySQL and PostgreSQL need a downtime when doing a major version upgrade. They both try to keep it short, usually seconds, but minutes can happen in either database.

> Not because the page is buggy (it is, though, crashed on my iPhone),

Maybe you meant Safari is buggy and crashed? I can easily get Safari to crash by zooming in and out a bit. Reports to Apple go ignored...

I get the sentiment. I don't love that different browsers have different behavior even on standards compliant code. But I've also done enough web development to know that if your page crashes safari in the main user flow (in this case, just hitting 'play'), the dev owns the bug.

Safari didn't crash. The web app did, for abusing the browser history API.

> SecurityError: Attempt to use history.replaceState() more than 100 times per 10 seconds

General models are very cheap to get started with though. So even if they are less than ideal, you can use them to get a company going and then make something more efficient.

If the design was done with Claude Code/Design it would be a lot better than this imo. Bland, but better.

The most Apple-ish thing would be to produce a great platform, enable third parties to do something on top of it, and take a cut.

I REALLY wish they'd do that with voice assistants.

From the comments on the article by the author it looks more like 10% so far and they haven't systematically looked. That means ~10% if a probable floor of how much fraud there is.

Not according to the complete comment:

     More like 10%, but my search has not been systematic. I am mostly looking where I know I will find image issues based on image filenames and “Find Similar Images” searches.

They are clearly saying they think this is likely above average.