If I could write that well in my first language I could probably triple my income. To do it in a second one is just incredible.
Any language that makes programming easier is good. Modern C++ is also quite good, but I feel like there are more "nice to haves" in other languages. Reflection is one, for serializing things without boilerplate and his uncle. And just reflecting on types in general can be nice.
I looked into Vapor but it seems much slower than it should be for a compiled language.
Vapor is a very small project, and thus is slower then other larger more mature projects.
And up against C#, Go and C++, Vapor could not make the top 70.
Even just compare Swift vs PHP and its a really poor showing for vapor: https://www.techempower.com/benchmarks/#section=data-r23&l=v...
I think you’re just going on vibes here but it’s kind of bullshit when you think about it for more than a moment.
It’s also only been relatively recently that Google has decided it’s ok to be opinionated and provide happy paths for devs to follow in their UI library with Compose. Android Framework was/is notorious for having 5 ways to accomplish any given task and none being “right” or the only one capable of doing what you need being deprecated.
And then there’s Kotlin, which is so close to being a great language but dies on weird hills ideologically (e.g. please just give me “if let” syntax, “.let {}” is ugly and automatic unwrapping fails just enough to not be useful).
Freedom of editor is nice but doesn’t make up for the rest, at least for me.
> it’s dragged down by the unmitigated messes that are Gradle and ProGuard
> “if let” syntax, “.let {}”
From the horribly slow typecheck that gets exponentially worse every time anyone adds a protocol extension to <very common type>, the debatable choices made with concurrency/async/actors/swift6, the only-very-recently-stable ABI, the regular titanic undertakings needed for bumping any major version that are almost unheard of in most other languages, etc.
Swift is an alright language today. Good even. But for a 10 year old language ? It aged horribly, going through senseless breaking changes just to fit Apple's needs. It's fine if you're locked in on Apple's platforms, but any other language doing that would have been set on fire already. Look at how painful the python2/python3 split was: Swift did worse than that, _four_ times.
You mean 6 years ago? https://www.swift.org/blog/swift-5-released/
Seems to hit a sweet spot of a fast/compiled (compared to Javascript), memory safe (compared to C++), object orientated (compared to Go) and easy to write (compared to Rust).
Doesn't seem like there's any maintained bindings for Qt though, although there are some interesting ones for GTK (e.g. https://git.aparoksha.dev/aparoksha/adwaita-swift)
AppCode was abandoned because Apple is impossible to work with and never provided up to date semantics and language definitions for Swift, keeping everything under wraps and making every single Swift release a race to suddenly implement whatever new keyword they made up this week.
Fleet is more of a VSCode. Probably using the LSP these days, and it's good enough if a simple text editor is what you need.
A simple rule of thumb is that if anything has a parent/child relationship, the child should use the weak keyword (or even “unowned” if you’re certain about object lifetimes) when referring back to the parent. That and things like hand-rolled doubly linked lists, but the standard library already has that so who cares.
In C#, these aren't the exact same as a reference cycle, but the end result is the same, a memory leak: https://learn.microsoft.com/en-us/dotnet/desktop/wpf/events/...
First in the sense of hand crafted interop solutions that modern languages provide.
Take Dart for example as something that has a (by comparison) very small package ecosystem.
However it has support for interop across: JavaScript, Java, Objective C, C, C++, Rust, Swift, Kotlin and Go I believe off the top of my head.
Then you also have efforts like WebAssembly and specifically the in-development component model which seeks to totally break down that language specific package ecosystem and make importing and working with another language as easy as it is when importing a package from your own language ecosystem.
So with those things in mind, however true that might be today, I don’t think it’s a strong argument moving forward.
Dart is used probably and exclusively in one context (= library): Flutter. Nobody would dream of writing anything else with it and put it in production.
Why? Because despite the interop, all the libs are still in the original language and they shine in the language they were written with. And Dart has no ecosystem comparable to the top 5-10 most used languages.
Try to build bindings for QT in Dart. That alone would require a company just to make that happen. You'd have to pay developers just to make that interop work - that's what Riverbank did with pyqt. No other companies did that, as far as I know (until Nokia developed pySide). And what for?
So I somehow agree with the previous comment, unless someone writes really good bindings. That's rare, though, and from my experience it's mostly to put something in legacy mode.
Would you build a product with either of these things and sell it and put your name on it? I wouldn't.
I agree strongly on that it is good to make software architectural decisions, involving business, based on if you have a bunch of other people with the same problem shape as you.
And on specifically the idea that Darts not exactly hosting multiple UI frameworks, even though it theoretically could. (I don't know enough about Qt to know who uses it and why, my understanding vaguely is Linux UI. Canonical is all-in on Flutter, for whatever reason, so I discount the probability that Dart would naturally gain Qt bindings, if it was non-small)
Being a YXZ Developer trying to fit YXZ into every domain, means that for many scenarios one ends up yak shaving until the foundations are in place for the actuall work one is supposed to do.
And even then, the tooling (IDE, debugging, build, libraries) will fail short from the platform native experience.
My motto is to always be curious and learn what is out there just in case, however in what concerns production work, only what is directly supported out of the box by the platform matters.
Typescript is maybe the exception, then again it is really a JavaScript linter in practice, the team has learned not to add additional language features.
Bevy and Servo wouldn't exist without Rust. Unreal probably wouldn't succeed without C++.
Languages may also matter for other reasons than just their feature set. Node.js got traction specifically because it was JavaScript.
Even though Fortran had state-of-the-art numeric libraries, Python enabled numpy to have the sweet spot of usability with good enough speed.
The killer libraries need years of effort to build them. That won't happen if users don't want to use the language, or the language isn't good enough for the task.
For Swift to have killer libraries, users must first choose Swift to build them. Catch22.
Re: easy to write, I'm not sure, Swift's recent explosion in complexity makes it a hard sell vs Rust, even if the learning curve might be slightly less steep. At the end of the day, Rust's DX wins in almost every dimension, people are willing to learn slightly more complex semantics if it saves times everywhere else: tooling, libraries, build tool and package manager, ... I believe even compilation speeds don't compare favorably.
Unlike Swift, there was never a period of time where LLVM only worked exclusively on Apples own OS's or hardware. From the get go, you could run early versions of LLVM on Windows. In Swift's case, Linux support came in 2016, 1.5 years after Swift's initial release in 2014, then Windows support came 6 years later in v5 (2020).
If Apple didn't want to let Swift suffer the reputation of being an Apple-only language they should've invested more into cross platform support much earlier on. Yes, today Apple and everyone else can say, 'Swift is cross-platform', but dig deeper into the history of Swift and its clear that from the get go, Apple treated non-Apple OS support as an afterthought.
It works well on Windows, macOS, iOS, Android and I suspect Linux as well (but I never use Linux, hence I can't be sure). And if you want a multiplatform UI there's some decent options like Avalonia UI [0].
---
If you're developing Windows apps or Windows games, C# is a fine choice; much as Swift is a fine choice for Apple apps. But no one worried about Apple's control of Swift should be pointing people to C# with a straight face.
This routinely pulls the carpet under the .NET team effort to widespread .NET adoption.
That being said. Microsoft does not want a cross-platform C# that works on Linux. This is why their .NET MAUI does not support Linux and a 3rd party framework will be needed.
Only reason I would choose C# for non-Windows is because of existing / legacy code base. Any new application would use language and libraries that fit the problem versus trying to fit C# as the solution to all.
Mono actually is the primary project that greatly improved the C# world and evolved the latest .NET infrastructure, not Microsoft. Mono developers actually cleaner APIs. Even Microsoft Visual Studio for Mac is just Mono Developer with the Linux supporting bits removed.
Swift solves a problem that is still there. It was also released before the final release of Rust.
It’s just that people seem to think that because it’s from Apple, it’s only meant for iOS/macOS.
I love swift, it combines so many things, and Apple is really good get pushing the language forward with its compilers/warnings.
I’m also using it for shell scripts and small utils, and it’s really great. I made https://github.com/jrz/container-shell to improve the experience of scripting cli tools in Swift.
When Android was first released it was basically Android devices only, too. Still is.
So; what exactly are Apple's big, selfless contributions? XNU is Source Availible but unusable without buying proprietary Apple hardware. iBoot is mysterious and has to be reverse-engineered to use it like UEFI. Open standards like Vulkan are ignored for political reasons, CUPS is basically derelict, WebKit killed KHTML because sharing was too hard, and APFS and Metal are still both undocumented despite promised transparency. CoreML is proprietary but can't compete with CUDA, iPads can't use QEMU despite supporting it in-hardware, all the Apple Silicon DeviceTree code is private, competing runtimes like Corellium get sued and security researchers get ignored. Swift, as an offering to the Open Source community, is a punch line at the end of a 20 year long gag.
Apple does genuinely nothing to advance the wellbeing of common computing for mankind. Apple leaves behind no charitable contributions to anything that does not ensure their absolute preservation as a business. Combined with the proven anticompetitive damages that the App Store incurs on the burgeoning mobile market, they are unequivocally a net-negative force and aren't hated enough for their parasitic influence on global software production.
I think I can handle their stance on software,
Or empowered by its association with Apple. That's a pretty big pond.
I like Swift, and I write software for Apple devices. I don't really care, whether or not it supports other platforms. For my backend work, I tend to use PHP, because there's a very broad base of servers that support it, it's good enough, fast enough, and, doggone it, people like it...
Another comment mentions that languages aren't really the issue, platforms are, and enumerates a number of application contexts, and the languages that are used to develop in those contexts.
If you want to write native Apple software, then you need to either use ObjC, or Swift. You can use C or C++, and JavaScript, if you don't mind gluing them on, but native is Swift/ObjC, and Apple doesn't really do much to support ObjC (but they have to, anyway, because I guarantee that some of the biggest apps out there, still run with ObjC -including some Apple ones).
I use Swift. I write both UIKit and SwiftUI, but find that UIKit is what I use to deliver a great user experience. I have to use SwiftUI, for a few applications (like Watch apps), and am constantly slamming into its limitations.
It's really fun, knowing that some folks hate me, just because I write software for Apple platforms.
I don't hate them back. That kind of hatred isn't very good for you. It's Commissioner Dreyfus-level obsession.
But this also shows what a tiny, tiny minority of people are represented here. Apple's a three-trillion-dollar company, because most folks aren't like us.
The thread was about "Swift would be a good language, but all the attention and focus is on the Apple ecosystem and everybody using it for something else is an outlier and if you don't want to deal with apple it's a hard game"
It was designed by Apple, for Apple. They only care about non-Apple support, if it results in Apple software for Apple hardware. I suspect they will be using it for some of their new custom server farms (or Python).
Mercenary as hell, but it’s not an uncommon stance; especially with hardware companies. I had to work with that attitude all the time, at my last job.
The comment was basically "nobody gives a shit about apple stuff".
This comes off as very "I am a main character post" on your part.
I have had decades of experience with people saying “I hate you” because I write software for Apple systems, so I’m not imagining it. I also know that I’m not alone. It’s not exactly a “cutting edge” mindset.
Personally, I’m offended. I think that it’s shallow. I have plenty of other fine qualities to hate.
I’m always tempted to project motivation and intention onto others, but I’m not very good at it, so I keep it to myself.
ObjC is one of the greatest "glue languages" to have existed IMO.
If your response to "Swift is being limited by Apple" is "well at least Apple hasn't killed it yet" then yeah, you're proving their point. Assuming you're right, and Swift is being empowered by Apple, then what is the language without Apple's support? Another .Net situation. They control the vision, the pitfalls of Swift as a language are the result of Apple's discretion. You can't blame the community for refusing to do Apple's dirty work pro-bono.
And honestly, Apple shouldn't be unhappy with where Swift is at right now either. They got exactly what they wanted from it, having third-party language stakeholders was never part of the equation for supporting Swift. A best-case scenario like Mono for Dotnet wouldn't be worth it, and Apple devrel is already in the toilet to boot. Might as well just go mask-off and run the whole thing like any other iOS library, but that's just my $0.02.
In addition to the Adwaita bindings listed, there’s also autogenerated plain GTK bindings (https://github.com/rhx/SwiftGtk).
Afaik someone on this site shared a repo url that has the early bindings using Swift C++ interop.
What you've enumerated are also applicable to Dlang with potential of even faster compile and execution time than C++ or even the venerable Fortran [1].
[1] Numeric age for D: Mir GLAS is faster than OpenBLAS and Eigen:
http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...
If many people think the same way, then yeah, there's no good reason to reach for Swift unless you're writing an iOS or Mac app and don't want it to be cross platform for some reason that I almost can't imagine in 2025.
>Seems to hit a sweet spot of a fast/compiled (compared to Javascript), memory safe (compared to C++), object orientated (compared to Go) and easy to write (compared to Rust).
Replace Apple with MS and Swift with C# and all of this is still true but makes my heart ache even more.
Swift at one point could've been Golang with better C++ interop. A better Rust since it's memory safe without the gymnastics.
https://extensions.panic.com/extensions/pixelfoundry/pixelfo...
https://extensions.panic.com/extensions/panic/panic.Icarus/
The one you linked to looks like it's just syntax highlighting; Icarus has that, but also has LSP, building, and debugging support.
Caveat: I'm using Swift for command-line software.
It’s a fresh change from your typical modern website.
The big hopes for me this year of WWDC would be a Swift port of the Foundation DB record layer, from Java, along with a decent http server package. It's underappreciated just how useful it is in golang having a production capable http server in the standard library.
The fewer dependencies I need, the better. It’s one of the reasons why I’m still a big fan of developing for Apple platforms despite the recent drama: it’s a very batteries-included experience, which means it’s not just feasible but pleasant to develop top-class apps with a dependency list that can be counted on one hand. That’s amazing for not just the dev process itself but also for long term maintenance.
https://forums.swift.org/t/redesigned-swift-org-is-now-live/...
Working on a dozen architectures with only 10 000 units sold each would be a better proof of it being a valid option for embedded development, but I guess the industry standards are whatever we make up today.
It does work, but I don’t find it ready for production without a lot of conf and extensions first.
The last few days, I've been wondering if our commitment to building our mobile app in Swift was a mistake as the only member of our team that wrote swift is no longer with us.
Has anyone got experience with Android apps written in Swift? Thoughts?
I can't tell from experience myself but talked with people who do this and they're happy with this way of working.
Most people would disagree with this line…
It feels more like Apple(-esque) marketing than anything.
I find Swift fascinating, but the software I want to write is not software locked into Apple platforms. The low level stuff looks particularly interesting, as the common low level languages all have their peculiarities.
- “Tools for Linux, macOS, and Windows”
- “Run performant services on Linux and deploy to the cloud”
- “Develop efficient, reliable firmware for devices like microcontrollers”
- “Reuse existing C/C++ drivers and SDKs with zero wrappers or runtime glue, integrating in minutes.”
The site has examples for running Swift code on a Raspberry Pi Pico W, an ESP32 microcontroller and a PlayDate.
That doesn’t mean Swift is the best tool for doing these things, but “really hard to imagine a use case for Swift outside of Apple platforms”?
AndriyKunitsyn•1d ago
fckgw•1d ago