> 3. get rid of roughly 150 of the 200 keywords there are

I don't understand this point. Could you explain?

The new keywords enable new language features (ex: async/await, any, actor), and these features are opt-in. If you don't want to use them, you don't have to.

What are they keywords you think should be removed?

> these features are opt-in. If you don't want to use them, you don't have to.

Using a language is more than just writing it with a pre-established knowledge of what subset of features you think is worth the tradeoffs. More keywords/features means when you try to figure out how to do something new, there may be 15 different ways and you need to analyze and figure out which is the best one for this scenario, which ones are nonstarters, etc.

That's was more or less the whole design goal of Go. It was made by C++ programmers who were fed up with how many features were in the language, so they kept the feature set limited. Even the formatting is decided by the language. You may not agree with every decision, but what matters is decisions were made and they're standardized, so everyone is on the same page. You can read anyone else's code, and you know exactly what's going on.

What are the languages with similar or better ergonomics?

Everyone will have their different take on what Swift is, and what a proper alternative looks like. Swift started life as a C-family successor, so I'll be looking at languages with similar aims (fine-grain control, scaling to large projects.)

The first two I'd mention are D and Nim. I only wrote ~10k LoC with these languages (so they weren't really for me) but they strike me as similar to Swift. They both optionally support an automatic memory management strategy like GC, (whereas Swift as ARC) and there is great effort put into metaprogramming facilities. Both D and Nim compile much faster than Swift, and offer better error messages than the Swift compiler in the presence of complex generic expressions. In the context of the parent post (games) Nim is especially well equipped with a package ecosystem. D seems a touch less lively, but has a following.

For myself, I prefer the Odin programming language. Full disclosure, I've been donating to Odin for about a year now after happily using it for more than 5. After writing "Orthodox C++" for a while, I stumbled on Odin and feel as if it was made specifically for me. The compiler is fast, and the language has been something like a tutor or mentor for me, as it applies friction in places where I usually waste time. It would take some hand-holding as a first-language though, as some error messages relating to overloading/generics would seem obtuse to a beginner.

EDIT: I've recently been exposed to the Raku language, and it strikes me as sort of a ... dynamic version of Swift? It's jammed full of functionality, with an emphasis on being able to design syntax a-la DSL.

Also I'd add that Swift is sort of part of this new litter of "no-paradigm languages" like Kotlin and C#. I don't think Kotlin can actually dip as low-level as C# and Swift can, though. At least I think only C# and Swift have some kind of safety-wrapped user-level pointer "thing."

> It's not fast.

Not disagreeing with you, but here’s an article from Akamai about how using WASM can minimize cold startup time for serverless functions.

https://www.akamai.com/blog/developers/build-serverless-func...

Yes. This page has several ways to get older macOS versions: https://support.apple.com/en-us/102662, but the earliest macOS version you can use on Apple Silicon is macOS 11.

If you move your home directory to a different disk partition, you can even share it between two different macOS versions!

these Macs can't go below Tahoe. People on Mac Rumours were complaining about M5 MacBooks unable to install Sequoia, so it's safe to assume Pro/Max chips will be the same.

This. You can’t downgrade below the version the device ships with (a forked build of the current version at time of mass production)

Holy shit, it’s still being actively developed and maintained https://github.com/cappuccino/cappuccino

More amazingly the guy doing the most recent maintaining[1] is a medical Professor at Freiburg Uni.

[1]: https://github.com/daboe01

And wow, it's basically a web version of Cocoa! Check this out: https://ansb.uniklinik-freiburg.de/ThemeKitchenSinkA3/

My suggestion is no - first have them do it the hard way. This will help them build the skills to do manual memory management where defer is not available.

Once they do learn about defer they will come to appreciate it much more.

Prefer structs over classes != only use structs.

There are plenty of valid reasons to use classes in Swift. For example if you want to have shared state you will need to use a class so that each client has the same reference instead of a copy.

Yes, that's what I said.

With the library you’re able to use stripe without thinking about web hooks. The library is named based on what it enables a user to do, not how it works internally.

Yeah customers are market validation, not merely the existence of competition.

If your competitors have customers, I think that is a sign of market validation. If they do not, then you might not either.

IMO the page is concise and well written. I wouldn’t call it very elaborate.

Maybe the page could have been shorter, but not my much.

It's inline with what I perceive as the more informal tone of the sqlite documentation in general. It's slightly wordier but fun to read, and feels like the people who wrote it had a good time doing so.