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

I'd like to think that if things went just a little bit better it would have beed the ideal programming language for anything cloud / backend related.

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