Sorry but this can't be more wrong. I love Swift so much that I can tolerate and forgive its compiler's sluggishness.
Swift is now available on Linux (has been for a while) and there's Apple's server framework called SwiftNIO. It's designed for fast and efficient multithreaded server-side code. I voluntarily picked it for my next backend project and am very happy so far.
I admit that I last worked with it in early 2020, but at the time there were numerous annoying open bugs with the Swift compiler on Linux (such as the installer messing with the Python path), and then there was the issue of divergence between Foundation (which is closed-source) and its Linux replacement. Meanwhile, the stack size for secondary threads was ridiculously low and there was no good story for fault recovery (because you don't want to crash your server if you accidentally access an invalid array index).
Maybe things have improved, but I'm doubtful.
On the Linux front, there's Apple's SwiftNIO which is a generic lower-level framework that itself is not an out-of-the-box web or API framework. You need another extra layer above it, which is for example this community-driven project called Vapor [2]
You can, in principle, build a e.g. JSON API based on barebones SwiftNIO and you will save a lot of 3rd party dependencies in this case, but this path is a bit masochistic, you really need to know what you are doing in this case. Vapor is much easier to jumpstart any kind of server project with.
I would use it in more places if I could, it's a language I feel extremely productive in. Apple however has shown zero interest in helping popularise it anywhere outside of their ecosystem and left it up to the community.
I write Go for work and my all-time favorite language is probably still Rust, but I find that a ton of really thoughtful and smart choices have gone into Swift-the-language as well as how it’s used to build apps.
Happy to expand more on what I like about using Swift if you’re curious.
[1] which you can now write as the same codebase using SwiftUI
I like that. I'm stealing it :)
> Happy to expand more on what I like about using Swift if you’re curious.
Please! I was very excited with it at the beginning, but the few times I dipped my toe it was frustrating and slow.
You led me to finally track down the name of this feature in Bash: "brace expansion"! I often wish my non-techie friends recognized this syntax, along with sed replacement syntax for fixing typos.
> I was very excited with it at the beginning, but the few times I dipped my toe it was frustrating and slow.
Okay, it definitely can be slow to compile, especially with large blocks of type-inferencing ResultBuilder DSLs like SwiftUI or RegexBuilder. I find this mostly occurs when there's a type error within the DSL, and it often takes forever for the compiler to stop trying to do inference and give up with "Type of expression is ambiguous without more context" or simply "The compiler is unable to type-check this expression in reasonable time". But in practice I rarely run into this issue unless I'm creating a massive hierarchy that should be split into smaller components anyway. And I haven't really run into issues with runtime performance yet, though I haven't made anything too performance-critical with it. In any case, Swift makes it decently easy to call out to C/C++/Objective-C if you had a performance-critical routine.
What I like about the language:
It gives me the satisfaction of languages like Rust that let me express types and logic in a way that feels "correct". I rarely feel like I'm hacking stuff in due to deficiencies in the language. Swift encourages a standard approach of record types with polymorphism but still supports legacy NSObject-based stuff in a logical way, so I never feel like I have to jump through too many hoops if I need to touch dusty old frameworks.
I like the type inference, even if it's not perfect category-theoretic Hindley-Milner magic and gets stuck sometimes as mentioned previously.
I like the `guard` statement as someone who's done a lot of Go programming and always instinctively used early returns even when my CS professors told me it was a bad practice ;)
SwiftUI is really nice to use and is the only UI framework that I've ever enjoyed using (and am hoping to write it for my job soon)--it sometimes feels more like a UI prototyping tool to me because it's so straightforward, except that at some point while prototyping, you realize you've already made the finished UI without writing a dreadful mountain of glue code and interface files!
I really like the syntax in general, though I also appreciate Rust's terse symbol-based approach, I think the English-like labels actually work really well despite being a bit verbose. It definitely benefits from an editor with autocompletion, but I wouldn't say it's strictly necessary.
I appreciate the strict Unicode-correctness of the language that makes it harder to do bad stuff with strings.
I think the ARC-based approach to memory management is a good balance between Go's GC and Rust's borrow checker that makes Swift feel like a very pragmatic choice for lots of different problems (though UI was obviously first in mind).
I really like the ArgumentParser and RegexBuilder frameworks, and I think they're the best implementations of each in any language I've used.
In general, Swift just feels good to write and easy to read while being extremely powerful in what you can create with it, and coupled with the ease of use and fast feedback of SwiftUI, feels like a very complete approach to creating many different sorts of software, for my own use or to sell.
They also dedicated some time on the state of the frameworks session, to put it clearly out there that Objective-C is done and it is time to move on.
It took about 20 years for C++ to take over some key areas to C, and even there it wasn't a success in POSIX and embedded, where C still rules.
8 years isn't nothing.
Is that the "Platforms State of the Union" session from the first day of WWDC 2022? I'm looking in the Developer app right now and can't find the "frameworks" one you're talking about.
Around 4 minutes into it.
> But designs evolve, hardware advances, and what was once cutting edge becomes the expected baseline. The Objective-C language, AppKit & UIKit frameworks, and Interface Builder have empowered generations of developers. These technologies were built for each other, and will continue to serve us well for a long time to come, but over time new abstractions become necessary.
https://developer.apple.com/videos/play/wwdc2022/102/
It gets worse from there, for Objective-C. The speaker goes on to basically say that the new triumvirate of "integrated language, frameworks, and tools" is Swift, SwiftUI, and Xcode Previews, and that these will be evolving together, and influencing one another's evolution, as Objective-C, the "kits," and IB once did for one another.
I love coding in Objective-C, and did so for work for almost 5 years. (I've within the last year switched to a front-end developer job.) Swift, to me, whatever its upside, feels like it was written by someone who hates Objective-C. That makes me sad.
But, putting aside my editorializing, I read what Apple is saying as basically this. Objective-C, etc., is all but deprecated. At long last, it's being left behind. You may get away writing CRUD apps for a good while longer, but all the new stuff will be Swift-only, and at some point any UI written in Objective-C is going to start to look dated, once the inevitable innovations come.
Rust has become all that, and for a change, I am happy to observe that we're stuck with a pretty good language.
I sense a lot of Rust envy among Swift people. Just my impression, of course. They have much in common, but I think Rust has more merits on its own, particularly in memory management.
Basically, a timid but interesting step to get Swift to move toward ownership semantics, on top of its current Arc based memory management.
Not true for me, I've used it successfully for server side work. Being able to use the same language is nice since I can pull in the same routines/data structures and not re-implement them.
8 years later, it's safe to say it's not the language of choice for the new kernel or driver code, not the one for the hot new web framework and it's not replacing Python.
The only thing it's got going for it is that it's the only officially supported choice for making iOS apps going forward. Ultimately, no one uses Swift voluntarily, and that's a bad sign.
I write all of this with sorrow, I was cheering with joy when Swift was released.