Hacker News Reader

Comment by airstrike | Hacker News Reader

Swift is a great language. I just wish I could seriously use it outside of iOS development

Thank you for the compliment!

We're working on improving its support for other use cases, with work to better support embedded[1], server[2], and AI[3] use cases, along with Linux[4] and Windows[5] support.

We're also putting a lot of energy into improving support for these scenarios in Visual Studio Code [6].

Would love to hear more about scenarios folk are looking at, as well as specific gaps that are blocking you adopting Swift for non-Apple platforms. We're building a roadmap now and would love to make sure our work items are comprehensive.

[1] https://github.com/apple/swift-evolution/blob/main/visions/e...

[2] https://www.swift.org/blog/sswg-update-2024/

[3] https://www.swift.org/blog/mlx-swift/

[4] https://www.swift.org/blog/adwaita-swift/

[5] https://www.swift.org/blog/swift-everywhere-windows-interop/

[6] https://marketplace.visualstudio.com/items?itemName=sswg.swi...

That's great and appreciated, and hopefully will have an impact in a couple of years.

Today if I search for Swift jobs, it's a list of exclusively iOS app developer jobs.

Something I'd love to see is being able to use the VSCode extension for iOS / macOS development. I wouldn't expect all the bells and whistles of Xcode obviously (e.g. previews, run integration). However I'd love to use VSCode because I prefer their tradeoffs to Xcodes.

The advantage for Swift would be that potentially more developers use the VSCode extension which would hopefully improve the quality and incentivise more of them to maybe contribute to it.

If it's already possible then maybe a section in the readme on how to achieve this? (e.g. how to open an iOS project folder and get completions for Apple's frameworks).

What works quite well for iOS/macOS apps is breaking the project into a barebones Xcode project plus a Swift package that contains all of the code. SPM projects work well with VSCode and you get full auto-complete support with the official Swift plugin.

Thanks for the suggestion, I'll give that a try. Obviously this will not work with large existing codebases; but for new projects I'll try how well it works.

We already have a NeoVim plugin [0] that makes replacing Xcode somewhat possible. It's not perfect and requires that you have Xcode around for certain scenarios but I have been using it as my daily driver for the last month.

I think you would only need xcode-build-server [1] in order to get autocompletion in VSCode.

[0] https://github.com/wojciech-kulik/xcodebuild.nvim

[1] https://github.com/SolaWing/xcode-build-server

Thank you! Personally I actually prefer Neovim over vscode, so this is awesome. will try it out.

It was pretty great to see an official swift support for playdate

Overall it should provide a better experience than Objective-C even with GNUStep, never managed to offer without the NeXT or Apple's frameworks and IDE tooling.

So far, every time I play a bit with it, the experience doesn't seem much better, as naturally most packages assume Apple platforms, and VSCode isn't XCode.

Has the issue with manually reaching out for OS APIs instead of Foundation already been fully sorted out? Having samples directly referring to Glib and similar, instead of standard Swift, wasn't that interesting.

Also the lldb issue with Python bindings not being found seems to still exist, even on the container images.

However, I also acknowledge that many things seem to have improved, so there are also quite a few positives.

I’d love if Swift supported easy cross compilation in the same way that Zig does. The fact that I can just download Zig and everything will just work without tinkering is nice

I think if you could honestly use Swift outside of Xcode it would already be a massive improvement. I know you "can", but you really can't. It's painful. The experience would have to be at least 1-to-1 in terms of developer experience. When I use cargo/rust-analyzer in vscode, I feel at home and empowered. When I try to write Swift in vscode, I feel handicapped

SwiftUI is an incredibly powerful paradigm. It feels like the future compared to most GUI programming today. It is also possibly the most easily seen and best-known value of Swift today. Enabling and empowering the community to create similar abstractions outside of Mac OS/iOS would go a long way to making the language more commonly used, but I understand that's a responsibility that doesn't fall squarely on the Swift team. Case in point, the adwaita-swift and the swift-everywhere-windows-interop projects. The first looks fine (although it is just a "Counter" sample project) but the latter looks DOA/unviable. As a dev, I wouldn't even consider the latter and adwaita has the disadvantage of not being cross platform

Look at the sheer number of tools, languages and frameworks trying to solve the modern day "write once, run anywhere" of declarative guis. Tauri/Dioxus, React Native, Flutter, iced-rs (my personal favorite)... the list goes on. There's a real need here that Swift could help solve without forcing people into JavaScript or Rust. The former being too browser-focused (for better or worse, but I argue worse) and the latter having too steep a learning curve

I feel like a lot of the Swift-outside-of-Apple effort has been on server/embedded work, but in those domains, why wouldn't I choose Python/Node+JS or C/C++/Rust which already have a strong foothold, respectively? That's a much harder battle to fight from an adoption perspective IMHO

It actually has pretty decent support on Linux. It’s in Fedora’s official repos and Apple provides official builds for several other popular distros. The biggest issue seems to be that much of the larger ecosystem assumes Apple platforms.

I do all my swift CI/CD for non UI code in girthub actions on the Debian image for some time now due to lower cost and faster run times.

I even use Swift on a ARM raspberry Pi docker cluster.

Windows is officially supported for some time with networking and nearly all of foundation ported if that’s not complete yet.

The only real issue you have is at the UI level. There are some web and even ncurses libraries using SwiftUI like DSLs

Now with the new macro features you can get a lot more flexibility for cross platform builds.

C++ interoperability is also possible with latest versions. It was a hidden flag for a couple years. I’ve wrapped many C++ emulators in Swift over the last year with Cmake to Xcode projects.

Yes, sometimes the languages are great and versatile, but when it comes to the job market, your options are much more limited.

Do you like Swift? Good, you better also like iOS development.

Dart? You better be happy with UI with Flutter.

Even with Rust to a degree... If I'm looking for jobs where I could exclusively work with Rust, it's crypto blockchain. Web listings might include Rust but usually come with Python, JavaScript or Go.

Even if you are lucky and you'll find one job that offers what you like, yourself painting into a corner and tie yourself to one employer.

This is what's put me off getting deeper into Rust. I love the language but won't work on cryptocurrency stuff.

This is the reason why on the employers I have worked for, usually the language choice goes on the opposite direction most language geeks would like.

"Product/Platform we are targeting" => set of allowed languages as per their SDKs, official support documents.

The approach "pick language" => "select problem" tends to only work at startup levels, or being very lucky with the IT department policies.

It's popping up more and more because it's so flexible and great to work in. I've spent my weekend working on a Swift project for the Playdate (https://play.date)!

C# would probably be the closest thing feature-wise (and, often, syntax-wise) if you need first-class Linux support, and a lot of knowledge is directly transferable. Not a Java copy people claim it to be but something more low-level :)

With that said, Swift enjoys better FFI by virtue of using LLVM and lower base memory footprint since it does not need to maintain data structures used by GC. Performance however will vary case by case, ARC generally has way higher upfront cost than GC, especially in multi-threaded scenarios but lends itself to an overall more deterministic memory usage, which is important on memory-constrained systems.

Reply on news.ycombinator.com