I keep hearing about this concept of "progressive disclosure", but I can't say I've seen it in Swift. Even the simplest functions I want to write, I tug on a little thread of an idea that I have, and pretty soon I'm pulling out this giant tangle that's got 3/4 of the Swift type system dangling off of it.

What you're saying may be technically true. My issue is with the "if you need it" part. Unfortunately, I don't get to choose what I think I need. The compiler does.

For example, every beginning Swift programmer runs into "Protocol can only be used as a generic constraint because it has Self or associatedType requirements" [1]. You start by thinking, I'm going to write a simple little type!, and then 30 seconds later you're digging through the least-documented parts of the Swift manual trying to figure out if there's a simple fix for this. (There isn't.) It's not like Objective-C where you write an -isEqualTo:(id) method and call it a day.

This happens all over the place. Swift lambdas are weirder than Objective-C blocks. Swift errors are weirder than Objective-C exceptions. Swift strings are weirder than Objective-C strings. Ultimately, there is always a reason for the complexity (often: performance), but the upshot is that for any Swift feature I've wanted to use, I always had to learn a lot of extra details before I was able to use it.

I feel there are a lot of other languages which are both easier to read and write, and do a much better job at progressive disclosure.

[1]: https://www.youtube.com/watch?v=XWoNjiSPqI8&t=53s

Interesting. I guess in my opinion, there is a difference between "swift has some pain points" and "swift is inherently over-complex". I have run into the associated types issue (which is improved a bit by the addition of existential by the way) but my reaction was more that this is a particular design pattern to avoid, rather than that the language is null and void.

Given that you've made the comparison to Objective-C, are you sure you're not just running up against the learning curve of a new language? There are cases where Swift is a bit stricter, and therefore it's harder to type code which will compile on the first try, but in many of those cases it's because the strictness is allowing you to avoid entire categories of runtime bugs, which would give a non-specific error in Objective-C given the dynamic nature of the language.

Has Swift improved their text handling? Last time I looked, it took way too many lines of code and temporary variables just to extract a substring range from a string. Their convoluted idea that a string can't be directly sliced with integer indexes–by bytes, let alone by Unicode code points or graphemes–was so frustrating I swore I would never look in Swift's general direction again. It was such a joke just to try to extract x UTF-8 characters starting from position y. I liked the overall feel of the language, but the fact I ran into such a horrible wall trying to perform the most basic of string manipulations was unforgivable.

Swift came out at a time where UTF-8 was already the standard. They talked a lot of talk about grapheme clusters being the most accurate representation, and then failed to deliver a coherent API to back it up. Any chance that has changed?

It's gotten a bit better, but Swift is still probably not the tool you want to use if you need to do a lot of string manipulation. Swift's string implementation has some interesting properties in terms of memory efficiency and performance, but it still requires fairly the verbose use of string indexes when working with strings rather than simple int offsets. There are good reasons for this, but it's not terribly ergonomic to work with.

FWIW it would probably be fairly easy to implement some String extensions which would give you the kind of API it sounds like you are looking for.