Mixing Swift and C++

With exception of Kubernetes, most of Google's software keeps being written in Java, C++, Kotlin, and nowadays Rust.

Its use is much more widespread outside Mountain View walls than inside them.

Swift and Rust both suffer from slower compilation than Go, primarily because LLVM prioritizes optimization over speed.

There are of course other reasons like complexity of language, size of compilation units etc… but optimization tends to be the biggest hit in my experience.

Hence why Rust is adopting/investigating cranelift as a debug compiler to improve speed.

* Language features that make it so that you don't have to write code at all

* Tooling that makes it easier to find bugs in the code you do write

* Expressiveness and portability that allows the code to be used in more places

* Approachability, so that new people can pick up the language quickly

* "Batteries", so that people can rely on your high-quality libraries instead of having to manage their own

* Documentation and community, to handle the hardest parts of programming: people

* Performance, so that the code can use fewer resources

…among many other things.

This is exactly what Go does. Languages like C++ or Rust make it possible to expose and interact with those complex requirements, whereas Go takes it away in the name of “simplification”. Just look at all of the insane hacking tailscale does on Go to make it work for them.

(a) Foundation is portable and available on Windows and Linux.

(b) You are confusing language features and OS features. Async/await is part of the language. GCD is part of the OS.

(c) Banning modern concurrency primitives is not viable forever — you’ll be left behind as the native APIs adopt them.

There’s a layering:

- gcd is the lowest level

- async/await lets you write tasks with suspension points (they wait for events to happen); but an async function is still conceptually executed serially

- the Task API let’s you spin up async functions into various arrangements of parallel tasks and wait for those tasks to complete

- ‘async let’ is sugar for creating a Task to compute a single expression

- for async functions and Tasks to share data there is a Sendable model and various static isolation checks

- actors build on everything else; actors are classes whose state is completely isolated to the actor, and all method calls are posted on the actor’s executor

Memory-safe concurrency is hard. There’s a lot of ground to cover to replace the kind of things people do with shared state concurrency, and just actors alone are not enough.

> Compare that to go, where there's (at most) one satisfying way to design the problem in the typesystem. As a sideeffect people have to think more about the problem they're trying to solve, and how to simplify it to the maximum.

I like the aesthetics of small languages too, but I think Go picked the wrong small subset. It reminds me of Java in the 1.x days, for x <= 4, where the language had fundamental expressiveness constraints that created a huge amount of unavoidable boilerplate and type unsafety in even the most basic programming situations.

Result builders are a case in point. Essentially, they didn't like the bracket and the comma between array items in the special case where a function returns only a single array.

  // So rather than this
  let items = makeUgly {
    [
      Item("One"),
      Item("Two"),
      Item("Three")
    ]
  }

  // It had to look like this
  let items = makePretty {
    Item("One")
    Item("Two")
    Item("Three")
  }

So now there are essentially two separate syntax modes in Swift, and every time you look at some code you have to make up your mind on whether to read it in normal mode or in result builder mode. Sometimes that's easy to know in context. But it's another thing you have to pay attention to at all times.

you are referring to basic languauge features... you consider classes and structs pain points? these are the basic building blocks of the language, if you find them painful this is definitely not the language for you.

I guess you never looked into Kubernetes and their blobs of generated code to work around Go's weaknesses.

Apple just doesn’t like making solid commitments to outsiders, especially for something as mundane as legacy support. They want to mold swift into anything they want/need.