What, of course Apple uses Swift on the server, that's the only reason they're investing in any of this. Many of the foundational Swift on the server libraries were written at Apple and later opened, like SwiftNIO.

> Even Apple does not use Swift

Exactly true - they've created all these "working groups" of open source / volunteers to care for Android / Server / Wasm / ... all while being constraint "as an Apple product". Of course the end result is crappy

funnily enough, I talked recently to someone working on the swift compiler (not an Apple employee) to make Swift functions differentiable. So its not all dead yet

Being to aggressive in breaking stuff gets you a shitshow like Node.js or Ruby. Long-term source code compatibility is a very useful feature for open source and a sign of a mature eco system. Feel free to add stuff, but once it's part of a stable release it has to be maintained long after a "better" way to do it comes along.

I think it's not about that but about dogfooding Swift on the server. Apple uses Go, Java etc for a lot of its server components and refused to invest in hiring people that would extend the ecosystem for server Swift.

Thats the problem.

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]

That is because Clojure is done, there is hardly anything being done other than probably what matters to NuBank and Datomic mostly.

Also its market share adoption kind of shows it.

C# is the other direction, IMO.

I've been using C# since the first release in 2003/4 timeline?

Aside from a few high profile language features like LINQ, generics, `async/await`, the syntax has grown, but the key additions have made the language simpler to use and more terse. Tuples and destructuring for example. Spread operators for collections. Switch expressions and pattern matching. These are mostly syntactic affordances.

You don't have to use any of them; you can write C# exactly as you wrote it in 2003...if you want to. But I'm not sure why one would forgo the improved terseness of modern C#.

Next big language addition will be discriminated unions and even that is really "opt-in" if you want to use it.

I would remove result builders and all other uses of @attributes that change the semantics of the code (e.g property wrappers).

I would remove the distinction between value types and reference types at the type level. This has caused so many bugs in my code. This distinction should be made where the types are used not where they are defined.

I would remove everything related to concurrency from the language itself. The idea to let code execute on random threads without any explicit hint at the call site is ridiculous. It's far too complicated and error prone, which is why Swift designers had to radically change the defaults between Swift 6.0 and 6.2 and it's still a mess.

I would remove properties that are really functions (and of course property wrappers). I want to see at the call site whether I'm calling a function or accessing a variable.

I would probably remove async/await as well, but this is a broader debate beyond Swift.

And yes you absolutely do have to know and use all features that a language has, especially if it's a corporate language where features are introduced in order to support platform APIs.

I'm not a Swift user, but I can tell you from C++ experience that this logic doesn't mitigate a complex programming language.

* If you're in a team (or reading code in a third-party repo) then you need to know whatever features are used in that code, even if they're not in "your" subset of the language.

* Different codebases using different subsets of the language can feel quite different, which is annoying even if you know all the features used in them.

* Even if you're writing code entirely on your own, you still end up needing to learn about more language features than you need to for your code in order that you can make an informed decision about what goes in "your" subset.

But you have to know all of them to read other people's code.

To answer your question: I would immediately get rid of guard.

Also, I think the complexity and interplay of structs, classes, enums, protocols and now actors is staggering.

i would get rid of associatedtype, borrowing, consuming, deinit, extension, fileprivate, init, inout, internal, nonisolated, open, operator, precedencegroup, protocol, rethrows, subscript, typealias, #available, #colorLiteral, #else, #elseif, #endif, #fileLiteral, #if, #imageLiteral, #keyPath, #selector, #sourceLocation, #unavailable, associativity, convenience, didSet, dynamic, indirect, infix, lazy, left, mutating, nonmutating, postfix, precedence, prefix, right, unowned, weak, and willSet

You can take this approach in personal projects - with teams you need to decide on this and then on-board people into your use of the language. This does not work.

1. You don't have to use it all, but someone will. And there are over 200 keywords in the language: https://x.com/jacobtechtavern/status/1841251621004538183

2. On top of that many of the features in the language exist not because they were carefully designed, but because they were rushed: https://news.ycombinator.com/item?id=47529006

Go is garbage collected, though. Rust and Swift still occupy a niche Go doesn't.

Until you start using frameworks like Spring and then everything is so painfully magic that no one knows how the program actually runs.

Magical language how? And you should see what reflection based Java monstrosities do in the background.

I wouldn't change that in any way. I'd might make it an Arguments class, but I wound't make what parser returns merely a dict.