It was very exiting and promising at first, but it became bogged down due to its sheer run-away complexity and over-academic approach to programming....
To an outsider, or iOS new comer, Swift looks much better than Objective-c, (due to Objective-c weird syntax), but to many insiders, Swift seems like a huge missed opportunity...
The use of Swift, outside Apple's ecosystem is going to be limited.
I wouldn't go quite that far. I agree that Swift's cross-platform story is lacking, but as someone who follows the language closely, the story is improving all the time.
I see it as largely a chicken-and-egg problem: i.e. there's not enough activity outside the Apple ecosystem to improve the situation quickly, but I don't think it's impossible for it to get there.
For instance, it's already possible to use Swift in AWS Lambda, and some support for Azure's alternative offering, as well as Google's work on Swift for Tensorflow. All of these cases involve running Swift code in a very controlled environment, like a container, and this is very tenable even in Swift's current state. So even if it might be a bit of a pain to get Swift up and running on whatever exotic linux distro you run on your workstation, there are already starting to be some "easy" use-cases for Swift outside of Apple platforms. As the scope of these one-off use-cases grows, I think it's likely there will be increased demand to improve the cross-platform story in general.
Personally this is appealing to me, because while I agree that Rust is miles ahead in terms of cross-platform support, I find Swift so much more productive and pleasant to work with that I welcome more opportunities to use it.
Because I just started playing with SwiftUI/Combine without ever using ObjC/UIKit, I don't know what parts of ObjC shined.
I have a Cookbook here:
http://www.h4labs.com/dev/ios/swift_cookbook.html
I’m in the process of putting it on Github.
https://github.com/melling/SwiftCookBook
SwiftUI probably means that millions of apps will eventually move to Swift, making Swift a top 10 language.
Red Monk seems much closer to reality: https://redmonk.com/sogrady/2019/07/18/language-rankings-6-1...
Yet I haven’t know anybody who primarily or even occasionally used C in their work for over a decade. I know they exist but the majority of C programmers moved on to C++ a long time ago.
There are areas like kernel and driver development where C is still in widespread use but these jobs represent a tiny fraction of developers.
Any language popularity metric that ranks C as the second most popular language is massively flawed.
Linux is pretty popular.
From their site (https://www.tiobe.com/tiobe-index/):
“The TIOBE Programming Community index is an indicator of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. Popular search engines such as Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube and Baidu are used to calculate the ratings. It is important to note that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.”
My world runs on top of C++.
C is only relevant on constrained embedded hardware and FOSS UNIX clones.
I am sorry to say, you live in a bubble.
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.
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.
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?
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.
If there is some tradeoff between safety, performance, and usability, Rust has prioritized safety and performance, where swift has chosen safety and usability. And that's perfectly fine. I am glad that Rust exists for those use-cases where the performance is important, but there are also cases where it's more important to be able to write a lot of code quickly with less friction.
It doesn't devalue Rust to admit that there are places where it is not the optimal choice.
Perhaps you haven't programmed in Java. Or even C++, for that matter (modern "Core C++" programming can be quite tedious at times).
I'd say the jury is still out when it comes to Rust vs. "higher level languages", yes, even Swift. The point of my comment is that the "friction" you're pointing to need not be an inherent property of something like Rust, any more than it is in C++. It remains to be seen if the 'tradeoff' you mention is a binding one.
I never said Rust was the most tedious language, and I would hope it has learned something from those decades old languages.
I agree that Rust has some usability issues which can be improved upon without sacrificing safety and performance, but I think that trade off will always be there at some level.
For example, Swift’s copy-on-write makes it very easy to reason about value types, but comes at the cost of performance since there will be a lot of copies which aren’t strictly necessary. You can get essentially the same behavior in Rust by cloning everything, but it takes a lot more typing and adds visual noise to your code, because Rust has made the default to be more parsimonious with memory usage.
At some level trade offs have to be made. No one language can be all thing a to all people.
It all boils down to, does it deliver what the customer of an application written in Swift is asking for?
Of course, Rust won’t start taking that path, but if I were to start a new language today, that’s what it would look like.
It really makes me think there must be something like the first law of thermodynamics for logical complexity.
Kotlin?
When I tried Kotlin a couple years ago, it seemed to be marginally behind Swift in terms of the power of the type system and some of the cool things you can do in Swift, and I'm not wild about targeting JVM, but I understand that situation has been evolving so maybe I should give it a second look at some point.
Apple has the best engineering talent of all tech companies.