I wish it gains more popularity outside Apple land and is discussed more like Zig or Rust.
I wish it gains more popularity outside Apple land and is discussed more like Zig or Rust.
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.
Umm… Swift was released 9 years ago
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.
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.
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.
I bet very few of these work on Linux, https://swiftpackageindex.com/
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.
And despite all of this, Swift is a toy on Linux compared with .NET ecosystem on Linux.
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.
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.
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.
What if Apple stops development on other platforms, or makes future development proprietary who is going to maintain it for other platforms?
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?
Is there any way to win with you people? ^^
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.
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.
Excited to give Swift a try sometime soon.
> No macros / build-time code generation
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.
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.
Can't complain though my current daily driver is Scala and that's also a fantastic language to work with.