> It’s a contender for a "best idea and worst execution" award for programming languages in the last 20 years.

I’m not sure of the “worst execution” part. Is it even possible to make a Swift compiler that doesn’t occasionally hit those “humans immediately see what this code does, but it takes ages to compile this” moments?

I think there’s something about Swift’s type system that makes those moments unavoidable. If so, Swift is more “good idea, but too flexible to build a compiler for”, and they should have killed some of their darlings to get a better language.

The swift language is absolutely fantastic. But the constraints (such as objective-c compatibility) made it a juggernaut.

It's actually very surprising they managed to get that language work at all given the size of it. In that regard, i wouldn't say execution was bad. It was just unrealistic, and too much was asked from it.

Give it another shot—it is an ideal language for server-side code. The team has been working on error messages and compile times a lot over the past few years. At this point, it's extremely productive.

If you run into trouble, you can usually improve the dev experience by declaring types. This is usually only an issue if you're using a lot of generics or overloaded methods.

  let x = y.fruit(ripeness: 0.9)         // <- instead of this
  let x: Banana = y.fruit(ripeness: 0.9) // <- do this

Related to the above, generics are powerful, but I strongly feel they should only be used if they clarify the code. Often they obfuscate and complicate what's going on, especially if you have the interaction of two generic types.

And Swift compiler crashes aren’t even rare. You get used to it and learn how to track down the code that caused it.

I think I’ve seen a C compiler crash once or maybe twice, ever.

I especially ran into it when doing last year's Advent of Code. I restricted myself to not using mutable state or custom data types, i.e. structs or classes, writing in a functional style. That style involved a lot of method chaining (i.e. x.map(...).reduce(...)...) and, of course, of closures.

I had to introduce a lot of helper variables to break up my longer transformation pipelines to make the compiler happy.

I hope Swift is not going the way of Scala any further, which I enjoyed a lot when I adopted it early on, but eventually turned into a monster of a language.

Btw., for recreational coding, I moved on to Elixir in the meanwhile.