this is a bad faith take. i think the website is really cool and doesn't reek of slop at all. what makes you think differently?

I would not be surprised at all if it's vibe coded. I have seen exactly the same thing myself.

I gave instruction to Claude to add a toggle button to a website where the value needs to be stored in local storage.

It is a very straightforward change. Just follow exactly how it is done for a different boolean setting and you are set. An intern can do that on the first day of their job.

Everything is done properly except that on page load, the stored setting is not read.

Which can be easily discovered if the author, with or without AI tools, has a test or manually goes through the entire workflow just once. I discovered the problem myself and fixed it.

Setting all of that aside -- even if this is not AI coded, at the least it shows the site owner doesn't have the basic care for its visitors to go through this important workflow to check if everything works properly.

Same.

And who cares if it's vibe-coded or not. Since when do we care more on the how than on the what? Are people looking at how a tool was coded before using it, as if it would accelerate confidence?

It’s a heuristic to approach a program a bit warily as the length of the documentation likely outpaces how thoroughly it was designed and tested.

they seem to be adding more and more keywords

if they really want me to use this lang for everything, they'd have to 1. massively improve compilation speed, 2. get the ecosystem going (what's the correct way to spin up an http server like with express?) and 3. get rid of roughly 150 of the 200 keywords there are

especially w.r.t. the last one, of course everyone frets at huge breaking changes like this, so it won't happen, so people won't use it

> 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.

besides it being almost impossible to understand what "the right way of doing stuff" is with Swift (or any bloated language), i absolutely _do_ have to use the keywords.

reading someone else's code is part of working with the language (as is understanding LLM output nowadays). i can't just make others not use the keywords i don't know/beed/like. especially if working within teams, or using OSS.

Fair point, I had not considered needing to read and understand code you didn't write yourself.

Especially in a corporate setting, not understanding a keyword you see in a PR could lead to bad code being checked in.

i would get rid of associatedtype, borrowing, consuming, deinit, extension, fileprivate, init, inout, internal, nonisolated, open, operator, precedencegroup, protocol, rethrows, subscript, typealias, #available, #colorLiteral, #else, #elseif, #endif, #fileLiteral, #if, #imageLiteral, #keyPath, #selector, #sourceLocation, #unavailable, associativity, convenience, didSet, dynamic, indirect, infix, lazy, left, mutating, nonmutating, postfix, precedence, prefix, right, unowned, weak, and willSet

It's true that internal is pointless.

Focusing on the keywords rather than the macros, I think the rest of them have legitimate use cases, though they're often misused, especially fileprivate.

this is gonna sound ranty, but it's straight from the heart:

i think most of them are pointless. not every feature needs to be a new keyword. stuff could be expressed within the language. if the language is so inflexible in that regard that it's impossible to express stuff without a keyword, use macros for gods sake.

why is there a need to have a "convenience func" declaration?

why is "didSet" a keyword?

what about "actor"? most other languages don't have nearly as many keywords and manage to express the idea of actors just fine!

That file is the compiler's list of reserved keywords, so some of them may not have been added to docs, or they're experimental/internal/...

I'm not 100% sure but I think the swift doc you linked is missing at least a dozen keywords so the truth probably lies in the middle

Ah makes sense, personally I wouldn't consider reserved but unused words as keywords in the sense that you don't need to know them to read the language (even though they're keywords in some other technical sense). I was curious because I just tried counting number of keywords by language and it seemed surprisingly ambiguous/subjective/up to the language to say what's a "keyword" vs some type of core module. So my attempt (https://correctarity.com/keywords) probably has mistakes...

Notarised apps are still handled differently and made harder to run than apps from the AppStore

Just like Windows SmartScreen and now the new requirements for Android.

yeah they're moving into the wrong direction as well. not to mention that notarisation is for after-the-fact anyways. malware still slips through (historically true!). it's just supposed to shrink the blast radius AFTER apple knows a binary is malware.

what does the scare modal of "are you really sure you wanna run this? could be bad dude..." do?

the only purpose i can see it serving is to push devs to use the AppStore on mac, which is highly restricted in what you can do, and of course, takes 30% of your revenue

macOS copying Windows and Android is not a consolation in 2026.

GitHub has always been incredibly outage riddled no? This is not a MSFT thing

I don't remember that happening so much (if ever) in, say, 2016. But the frequency of noticeable incidents seemingly has been rising steadily since around 2023. The Azure migration apparently only exacerbated it.

Circa 2019, my office had a bell that we would ring whenever GitHub had an outage, and it was rung several times per week.

I remember seeing unicorn daily and "webhook delivery delayed" weekly. I think it got better, but also they got more traffic, now millions of agents read files separately over and over again.

IMO it's much better now.

I remember it going down semi-regularly in the 2013+ era, and seeing HN posts about it. Especially if you were using a package manager reliant on GitHub like Cocoapods. It seems to me it is more "impactful" on the dev community now that they have gone past just being a centralized Git server for the team, to being the thing that does deploys and all sorts of other things.

I think having a single 9 of uptime is a relatively new thing even for GH

It was not nearly as bad... I remember our company migrating to github.com, and believe it or not, it was significant performance/uptime benefit over our self-hosted instance.

(And the first thing to go was occasional 500's on github-hosted files.. the core service itself - git, PR, actions - were pretty stable until recently)

I recently found a project called sem[1] that does git diffs but is aware of the language itself, giving feedback like "function validateToken added", "variable xyzzy removed", ...

i think that's where version control is going. especially useful with agents and CI

[1] https://ataraxy-labs.github.io/sem/

it doesn't eat into AppStore sales to support it on mac because most use non appstore apps anyways. on iOS, PWAs are the one alternative to apps that Apple can take a sales cut from, which makes them a threat to their services revenue

I like Cursor's AI projects a lot. Cursor Tab is truly impressive. But you couldn't be more right.

I just downloaded VSCode again today after Cursor's latest update dropped my editor to 5 FPS or so (legitimately unusable. not hyperbole.) and holy shit it feels snappy. Completely forgot what it's like.

There's no shot they're doing that. Would be suicide as soon as anyone notices, and by the looks of it, they didn't even clean up the URL here to "hide" the fact that this is Kimi K2.5 so i doubt there's any grand conspiracy here.

What's way more likely is that Opus has been quantized by anthropic or something similar. Or that Opus was updated and didn't work well with Cursor's harness after. Or a token caching issue. Etc.

Well, I noticed. Though I am too busy to make a fuss about it.