That's my read too.
Swift was feeling pretty exciting around ~v3. It was small and easy to learn, felt modern, and had solid interop with ObjC/C++.
...but then absolutely exploded in complexity. New features and syntax thrown in make it feel like C++. 10 ways of doing the same thing. I wish they'd kept the language simple and lean, and wrapped additional complexity as optional packages. It just feels like such a small amount of what the Swift language does actually needs to be part of the language.
I get this feeling with C#. I have been here since its release. I looked at Swift and then they moved very quickly at the beginning, so the book I had to teach me was out of date moments after it was printed. With all the complexity being thrown in, I stuck with C++ because at least it was only 1 language I had to keep track of (barely)!
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.
> Next big language addition will be discriminated unions and even that is really "opt-in" if you want to use it.
I was excited for DU until I saw the most recent implementation reveal.
https://github.com/dotnet/csharplang/blob/main/proposals/uni...
Compared to the beauty of Swift:
https://docs.swift.org/swift-book/documentation/the-swift-pr...
The C# impl is still early and I think what will end up happening is that a lot of the boilerplate will end up being owned by source generators in the long term. C# team has a habit of "make it work, make it better". Whatever v1 gets released is some base capability that v2+ will end up making more terse. I'm happy and OK with that; I'd rather have ugly unions than no unions (yes, I already use OneOf)
Ah Source Generators, after all these years still badly documented, when searching you most likely will find the original implemenation meanwhile deprecated, have poor tooling with string concatenation, and only have a few great blog posts from .NET MVPs to rely on.
:shrug: we're using them very effectively and there are plenty of resources at this point.
Very useful for reducing boilerplate and we can do some interesting things with it. One use case: we generate strongly typed "LLM command" classes from prompt strings.
There are plenty of resources, outside Microsoft Learn that is, and the content is mostly understandable by those of us that have either watched conference talks, or podcasts on the matter.
Now having someone diving today into incremental code generators, with the best practices not to slow down Visual Studio during editing, that is a different matter.
They are naturally useful, as a user, as a provider, Microsoft could certainly improve the experience.
Which keywords would you get rid of and why? You don't have to use all of them!
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 agree with you about result builders, silly feature that only exists for SwiftUI.
But a lot of what you said, except for the concurrency and property wrapper stuff, largely exists for Obj-C interop. The generated interface is more readable, and swift structs act like const C structs. It’s nice.
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'm surprised, guard is really useful, especially when unwrapping optionals. It's terse, explicit and encourages defensive programming.
internal should definitely go though.
The absence of guard in Kotlin is one of those things that regularly trips me up when bouncing between it and Swift. Rather than Swift losing guard I’d prefer if Kotlin gained it.
I think the ?: operator ends up being a decent alternative, e.g.
Unless there's a use case for guard I'm not thinking ofi 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
It's true that internal is pointless.
Focusing on the keywords rather than the macros, I think the rest of them have legitimate use cases, though they're often misused, especially fileprivate.
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.
Yes exactly, it’s easy to blame a language when really it’s a team problem.
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
That number is unfairly exaggerated. The list includes ~40 internal keywords used only by language developers, plus dozens of tokens that would be called preprocessor directives, attributes, or annotations in other languages (e.g. `canImport` as in `#if canImport(...) #endif`; `available` and `deprecated` as in `@available(*, deprecated) func`).
are there actually 217 keywords? Just wondering what the difference between that file and https://docs.swift.org/swift-book/documentation/the-swift-pr... (a mere 102 keywords)
That file is the compiler's list of reserved keywords, so some of them may not have been added to docs, or they're experimental/internal/...
I'm not 100% sure but I think the swift doc you linked is missing at least a dozen keywords so the truth probably lies in the middle
Ah makes sense, personally I wouldn't consider reserved but unused words as keywords in the sense that you don't need to know them to read the language (even though they're keywords in some other technical sense). I was curious because I just tried counting number of keywords by language and it seemed surprisingly ambiguous/subjective/up to the language to say what's a "keyword" vs some type of core module. So my attempt (https://correctarity.com/keywords) probably has mistakes...
I felt that too many smart people were getting involved in the evolution of the language. There should have been a benevolent dictator to say NO.