Never had a problem with long compile times -- once you have your initial build, 90% of the time or more the incremental build process is very fast.
The languages I used for about 15 years were ObjC, C, C++, Clojure (and other langs before that). I find Swift to be a thoughtful blend of the key features of these four languages -- each of the things I like most about those langauges are in Swift, but it's the syntax in particular that I like most.
Hmm...not sure how else to interpret "upgrade to OO programming with use of protocols" other than that there was an upgrade to OO, and that upgrade was with the use of protocols. Now it looks like you meant an upgrade of the way protocols are used in OO, but you won't say how they Swift's protocols actually constitute an upgrade.
OK. ¯\_(ツ)_/¯
Typically you would write more protocol-oriented code - rather than using inheritance (which is mostly there for Objective-C compatibility) you define protocols and implement them for types.
This is a lot closer to traits in Rust than interfaces in Java. Among other things, a developer can define how a third party type implements a protocol they control, without subclassing or wrapping, as long as it does not require additional data.
No need for Google, as mentioned, I know both languages.
As for protocols not being encouraged in Objective-C, I migth own the wrong NeXTSTEP manuals.
(as a sibling comment pointed out, swift protocols are typically used for things that in objc you would use inheritance)
The kind of documentation that inspired Java authors.
https://cs.gmu.edu/~sean/stuff/java-objc.html
https://en.wikipedia.org/wiki/Portable_Distributed_Objects
https://en.wikipedia.org/wiki/Distributed_Objects_Everywhere
How exactly are protocols a Swift "upgrade" to OO programming? They were in Objective-C since the mid 90s, adopted by Java as interfaces, copied by C# etc.
Also, protocols in Swift have a huge performance downside, because they decided to have them work across structs and classes: if you use a protocol in a function argument, the compiler doesn't even know the size of the argument at compile time, so copying the arguments has to be dynamically dispatched unless the compiler can figure it out in an extra optimisation pass...that's not possible when doing separate compilation.
> Runs reasonably fast, on par with Go or Java.
A downgrade...particularly considering the epic compile times.
> named parameters
Also there since the 80s, in a less weird way.
https://blog.metaobject.com/2020/06/the-curious-case-of-swif...
> ...professionally used about half a dozen languages ...
What languages were those, if I may ask?