Cities are by definition economical logistical hubs. It's where the jobs and opportunities are. Most people aren't saying "gee I better pack up and move to suburbia before having a child" it's more like "having a child could cost me my high-paying job so I better not". And that issue is exacerbated in the U.S. with the worst parental-leave policy among developed nations. Regardless though, the trend will still exist in countries with generous parental-leave policies because having a child is an opportunity cost in an urban environment. That doesn't mean the environment itself isn't conductive to raising the child. Completely different stories.

Most of my American friends I know turn to the suburbs as a default for "family" style living once they have kids. Imagine their bemusement when they go to a place like Amsterdam or Tokyo and see plenty of families with small children walking around. Heck, you don't even have to go far to see how a city can be a great place for a family, just look at Boston.

Cities, when done correctly, are a better place to raise a family than the suburbs. And yet, when done incorrectly, are terrible.

> This is a pretty simple type, which is a vector that you can push into, but cannot modify the elements of. The data structure never moves an element once allocated, so you can push to the vec even while holding references to elements that have already been pushed.

This is the left-pad of rust. Reconsider your life decisions if you need to pull in an external dependency replicable with 30 lines of code:

    use std::vec::Vec;

    #[derive(Debug)]
    pub struct AppendOnlyVec {
        inner: Vec,
    }

    impl AppendOnlyVec {
        pub fn new() -> Self {
            Self {
                inner: vec![],
            }
        }

        pub fn push(&mut self, element: T) {
            self.inner.push(element);
        }

        pub fn clear(&mut self) {
            self.inner.clear();
        }
    }

Rust is one of the better languages when it comes to batteries included in it's stdlib. Even then, it's impossible to have a 100% coverage batteries included language because nearly everyone on planet earth has some different/unique use case for their code that doesn't fit a stdlib.

Engineering to these folks is a one-and-done endeavour. You just prompt and fire it off and ride off into the sunset, leaving the mess for someone else to clean up. They never see the work that goes on after the launch party. The midnight debugging sessions, the database migrations, the DNS failures, debates over which auth provider to use, the list goes on. Until the "citizen developer" is willing to engage in the less "sexy" part of software engineering, the world will move on without them as well.

It's the actions. The compute to run them isn't cheap at scale nor is the amount of auditing you need to do for security and compliance if you want enterprise/government customers.

Good thing I can just fork the editor. This is how you lose the trust and goodwill of your users.

Now that the calculus has changed, I think we should start asking ourselves whether anyone has the right to unlimited free public repositories.

We can all agree that trying to attribute any single metric to repo quality is subject to Goodhart's Law[1] (e.g. what happened to GitHub stars) yet we can also agree that the Linux Project is a much more vital repository to keep public infrastructure availble for than say, someone's vibe-coded to-do app. Is it impossible then to make any quantitative distinction between these two? We can't have both an uncontrollable firehose of AI slop and unlimited free public storage/compute at the ready for it. I say we actually need to decide what software is worthy of using up these resources for free. We already have companies like JetBrains[2] using dynamic pricing for their products. It's time Github do the same. If you want a hosted VCS for vibe coded projects that aren't being used or depended upon widely, then host the repo yourself.

[1]: https://en.wikipedia.org/wiki/Goodhart%27s_law

[2]: https://www.jetbrains.com/community/opensource/

https://github.com/zed-industries/zed/discussions/53403#disc...

Not once instance of these datacenters has proven to be beneficial for the communities and economies they're located in.

It wasn't mentioned in the article but half if not more of swiftui's issues also stem from XCode being the worst IDE to work with. It's incredibly bloated, tries to drive you towards GUI-driven interactions instead of using CLI, and takes ages to explore and understand all the different features/settings. I've never had any other IDE or editor refuse to compile my code because of a memory overflow during the compilation step, yet for some reason, even when compiling swift on an M2 MAX with 64GB of ram in 2026, I regularly get these kinds of cryptic errors that tell me it can't compile. Likely due to misuse of some code expansion feature, but then it rarely tells me where the source of misuse is.

https://embassy.dev/

Test code doesn't need to live on the device itself. You can call no_std code from std code and tell the compiler "hey, this code is only ran on hosts that have access to std" without trying to bundle the std library into your no_core code. You're not going to able to test I/O (does this function actually set Pin0 to HIGH or LOW) but you can test logic.

If you're making a sales pitch the $3500 is an investment in raising sales.