Swift is really an underrated language mainly due to the Apple baggage.
It hits the sweet spot between Rust and C++ due to it's sane design choices like structured concurrency or simple things like tagged enums, Result<T,E> etc.
I wish it gains more popularity outside Apple land and is discussed more like Zig or Rust.
Having written a bit of Swift code on macOS and a bit for iOS, I agree. This language has a very nice flow to it which should appeal to developers. It's hard to explain, but somehow the language is a joy to work in (Xcode also helps with that experience, of course).
If I could use a minimized Swift on embedded, I'd be very happy. Right now I'm just doing C for ESP32 and that sort of thing.
Yeah I was wondering the same! I fondly remember coding swift almost 10 years ago but large part of it was the good integration with Xcode I believe. Seems like they have an OSS LSP so probably that experience translates to other IDEs nowadays
It looks like a nice language but my concern would be Apple might decide not to support it on other platforms at some point. Just too dependant in a single company.
Are you willing? Do you want a certain feature? There's nothing stopping you from making it yourself.
A company literally makes an entire project open-source (and with major contributions from people outside that company) and you still say it's pRoPrIeTaRy??
Have you submitted any concrete requests or proposals? You want other people to magically guess exactly what you want AND spend their time and effort to make it for you, for free?
It scares me how many people don't realize this. A language is only as good as the things it allows you to build. Swift can be a great language from a PLT perspective, but it is pretty much only good at making apple UI's. Anything else and you are making some important compromises you might not be aware of.
What important compromises are being made that aren't "libraries may not exist", which is true of any of the equally niche languages that get a lot more love because they aren't associated with Apple? Even the severely limited ecosystem is mitigated by the language having excellent C and decent-enough C++ interop.
That theory works well in vacum, not when there are languages with similar features and mature ecosystems to chose from.
Microsoft is discovering how hard it is to take .NET outside Windows, the fierce competition of UNIX first programming language ecosystems, and Apple is not doing with Swift half as much as Microsoft is trying to.
The sentiment I was responding to was that Swift is only good for making Apple UIs, which is patently false.
Again, newer languages having less of an ecosystem than older languages is not news or somehow unique to Apple (or Microsoft by that matter). The existence of more mature languages than whichever one you're considering is not news - if it was, then nobody would start any project in anything other than like three languages. And as I mentioned there is a gigantic ecosystem that Swift and several others have access to by design, which for some reason people refuse to acknowledge whenever they shut down newer languages with "but no ecosystem".
> Microsoft is discovering how hard it is to take .NET outside Windows
Ten years ago you would have had a point. However it's 2024 and .NET is solid, stable, and widely deployed on Linux et al - and that's without taking projects like Unity into account. That's far from only working well in a vacuum.
As someone that does polyglot development across Windows and UNIX like systems, I am pretty well aware how well .NET adoption is going on UNIX shops.
It doesn't matter how solid and stable it happens to be, those widely deployed on Linux workloads are mostly from Microsoft enterprise shops cutting down on server costs, not startups filled with macOS, FreeBSD and GNU/Linux desktops deciding that C# would be a great language to use on their startup.
Unity is a special snowflake, they have their own .NET infrastructure, which is also a reason why you can't just use .NET vlatest on Unity.
Going back to Swift, so far it hasn't shown to be any different than open source Objective-C, and Objective-C at least has GNUStep outside NeXT/Apple.
The reasons they don't pick it is because they are just as illiterate as their microsoft shop counterparts.
I have colleagues who worked in a "macOS + Rider and Linux Hosts" style teams for a long time, and had great experience, but when they talk about this to a wider audience they get a similar treatment to what another commenter described when dealing with an architect from Walmart. People only ever listen to what confirms their beliefs and at best ignore when being exposed to something different, or sometimes react in an outright hostile manner.
Microsoft has a lot of baggage they’re dragging around, though.
Getting started on C# and Windows App SDK sucks a lot for example, because everything you google about them returns boatloads of results for myriad incarnations of C#, .NET, and XAML-based UI frameworks which makes figuring it all out somewhat painful.
That’s certainly a valid weakness, but at least getting up and running on Swift’s most native platforms is straightforward. One wouldn’t expect C# and Windows App SDK on Windows to be as much of a struggle as it is.
I don't get why you're so down on WinAppSDK, something that is largely ignored by .NET developers, and is really only used by Windows team or those poor souls that still believe WinRT has a future.
ASP.NET, EF, Avalonia, Uno, Akka.NET, Silk.NET, Unity, Godot and tons of other software packages work just fine on macOS and Linux, with JetBrains Rider and VSCode/C# Dev Kit/Ionide.
I like to develop in platforms’ “preferred” frameworks when possible and am not really interested in solutions trying to be a “silver bullet”. In the case of Windows I find the design language of Win11 actually pretty nice and would like to have that, which involves using WinUI/App SDK. There are alternatives such as writing an app with some other framework using a third party theme, but that can instantly become outdated with a system update or comes with weirdness like how some of the older Windows C#/XAML stuff gets all stuttery on displays running a refresh rates over 60hz.
That has nothing to do with cross platform .NET, and as mentioned only Redmond cares about it, and not everyone, Office team doesn't want anything to do with it, rather shipping Web tech on Windows.
And despite all of this, Swift is a toy on Linux compared with .NET ecosystem on Linux.
The two are completely separate. Getting C# to build and run only needs executing 'winget install dotnet-sdk-8' on windows or 'sudo apt-get install -y dotnet-sdk-8.0' on e.g. Ubuntu.
Couldn't agree more! I find it to be a very elegant language and a real treat to program in. I do mostly Java for work, and wish Swift had the open source ecosystem that Java has. There are so many support libraries and frameworks in the Java world that make it easy to develop complex applications. I wish Swift could say the same.
In my experience it has a solid 90+% of the semantic expressiveness - ADTs, advanced pattern matching, if statements and similar being expressions, traits (split into "protocols" and "extensions" in Swift), automatic reference counting, a well-defined ownership model (albeit not quite as strict as Rust's), constructs to prevent data races, etc. It lacks things like explicit control over lifetimes, and also defaults to copy-on-write rather than to move semantics - that isn't unsafe, but it does lead to beginners writing programs that compile fine but behave in a way that's surprising to them. It also doesn't expose threads directly (similar to Go only having goroutines), but the concurrency model is quite nice to use. The language is obviously opinionated about its async runtime (Grand Central Dispatch, which is also available on Windows and Linux) so you don't have to wrangle with that yourself though of course it loses the power and flexibility of bringing your own.
On the flip side, Swift provides a lot of syntactic sugar that makes it feel faster/smoother to engage with than Rust. For example, enum literals don't have to specify the enum's name wherever their type can be inferred by the compiler. So e.g. when you are pattern matching on an enum value, the match arm `MyEnum::Red => {}` in Rust would just be `case .Red:` in Swift. It isn't much on its own, but each tiny QoL thing like this adds up.
Swift’s syntax I think also makes it more approachable for people coming from other languages. Rust by contrast is rather intimidating looking for anybody without a background in C++.
Thanks for the feedback here -- this definitely make sense. Interested in the copy-on-write vs move semantics... I'm so used to it now that I almost prefer the harder/more manual control/checking that Rust provides, but I definitely see the ergonomics of going another way.
I find Rust a bit easier for me to read, quite preference-driven as I prefer snake_case to camelCase but that's a tiny thing.
And weirdly enough I think I actually prefer `MyEnum::Red => {}`, but maybe that's just stockholm syndrome.
While I do appreciate macros, and use them sparingly I find the best case for them is doing things like generating to/from <protocol> (e.g. JSON) implementations.
In Haskell, there's a fully baked system for derivation where you can set up implementations that walk the type trees, but most other languages don't have that -- I find macros to be a great slightly lower complexity way to do this kind of thing.
What is Swift's answer in production? Does everyone just write extensions for their types? Rust's serde is a joy to use and 99% of the time "just works", despite the macro magic.
> Type system function resolution
I'm not sure this is a real problem for me or most people, but taken with the point about polymorphism (I guess this point is basically about late binding), I see the benefit here.
> Protocols vs Traits as implemented
Generic methods being allowed in Swift is quite nice.
> Sugar
Great points in there -- some of them are style/preference but I can definitely see benefits to a bunch of them.
The string interpolation point you might want to update (Rust does that now!)
Named arguments are also quite amazing.
Again, fantastic list -- saved! I've been meaning to give Swift a proper try lately and this is a great reference.
For the record "No macros", is one of the things that is out-of-date. There is some discussion about it in the comments... maybe I'll be forced to actually update it :)
After having written a few of them at this point at $DAYJOB and on my own... They're actually not so bad at all -- it's quite nice the world that they open up.
I'd venture to say most people are mostly annoyed at the overuse of macros (where a simple function would do).
Rust's attribute system is something it REALLY got right -- stuff like #[cfg(test)] and the conditional compilation stuff is really really impressive. Not sure what cross platform dev looks like in Swift but the bar is quite high in Rust land.
Yeah I played around with it a bit and I really like it, but I've never really had a reason to use it professionally since I'm mostly targetting Linux and as you say it's definitely seen as being a bit exclusive to Apple land.
Can't complain though my current daily driver is Scala and that's also a fantastic language to work with.
I wish it gains more popularity outside Apple land and is discussed more like Zig or Rust.