Comment by troupo

For this language to become default at Apple they had to be doing a massive amount of internal promotion - in other words they knew where it was going.

And then if that's the case, how were they not ready to solve the many problems that a big organization would run into? And all the schedule constraints that come with it?

> Swift has turned into a gigantic super complicated bag of special cases, special syntax, special stuff...

That's true, but only partly true. It already was a gigantic super complicated bag of special cases right from the start.

Rob Rix noted the following 10 years ago:

Swift is a crescendo of special cases stopping just short of the general; the result is complexity in the semantics, complexity in the behaviour (i.e. bugs), and complexity in use (i.e. workarounds).

https://www.quora.com/Which-features-overcomplicate-Swift-Wh...

Me, 2014:

Apple's new Swift language has taken a page from the C++ and Java playbooks and made initialization a special case. Well, lots of special cases actually. The Swift book has 30 pages on initialization, and they aren't just illustration and explanation, they are dense with rules and special cases

https://blog.metaobject.com/2014/06/remove-features-for-grea...

Of course, that doesn't mean that it didn't get worse. It got lot worse. For example (me again, 2020):

I was really surprised to learn that Swift recently adopted Smalltalk keyword syntax ... Of course, Swift wouldn't be Swift if this weren't a special case of a special case, specifically the case of multiple trailing closures, which is a special case of trailing closures, which are weird and special-casey enough by themselves.

https://blog.metaobject.com/2020/06/the-curious-case-of-swif...

Oh, and Function Builders (2020, also me):

A prediction I made was that these rules, despite or more likely because of their complexity, would not be sufficient. And that turned out to be correct, as predicted, people turned to workarounds, just like they did with C++ and Java constructors.

https://blog.metaobject.com/2020/04/swift-initialization-swi...

So it is true that it is now bad and that it has gotten worse. It's just not the case that it was ever simple to start with. And the further explosion of complexity was not some accidental thing that happened to what was otherwise a good beginning. That very explosion was already pretty much predetermined in the language as it existed from inception and in the values that were visible.

From my exchange with Chris regarding initializers:

"Chris Lattner said...

Marcel, I totally agree with your simplicity goal, but this isn't practical unless you are willing to sacrifice non-default initializable types (e.g. non-nullable pointers) or memory safety."

Part of my response:

"Let me turn it around: Chris, I totally agree with your goal of initializable types, but it is just not practical unless you are willing to sacrifice simplicity, parsimony and power (and ignore the fact that it doesn't actually work)."

Simplicity is not the easy option. Simplicity is hard. Swift took the easy route.

[...] when you first attack a problem it seems really simple because you don't understand it. Then when you start to really understand it, you come up with these very complicated solutions because it's really hairy. Most people stop there. But a few people keep burning the midnight oil and finally understand the underlying principles of the problem and come up with an elegantly simple solution for it. But very few people go the distance to get there.

-- Steve Jobs (borrowed and adapted from Heinelein)

https://blog.metaobject.com/2014/04/sophisticated-simplicity...

To be fair, I think such a fate in inevitable for most languages after many years of changes and development.

[dead]