News for hackers. Stuff that matters.
Re:The Next Chapter in Swift Build Technologies by thih9 on Saturday February 01, 2025 @03:11PM (#42901756)
> why would I waste my time working on a language that is too tied to the Apple platform

This might work the other way round: starting from people familiar with macos or ios development who want to write for other platforms.

Then the question becomes: why would a developer learn a different open source language when they can use what they already know. And sure, depending on the context they might still go with Python/Kotlin/Rust/etc.

Re:The Next Chapter in Swift Build Technologies by hu3 on Saturday February 01, 2025 @05:27PM (#42903096)
> people familiar with macos or ios development who want to write for other platforms.

This is a rather small userbase when it comes to enterprise.

Especially because Swift will never be as versatile as Python or as efficient as Rust.

And then there's also Go, C# and Kotlin with much better tooling.

Re:The Next Chapter in Swift Build Technologies by privacyis1mp on Saturday February 01, 2025 @06:13PM (#42903527)
Xcode gives me such a hard time that I started considering writing in Kotlin for macOS, just to have a normal IDE. We used to have AppCode (from JetBrains) and it was great. I wonder why Apple didn't support JetBrains, after all, it would have been to Apple's benefit.
Re:The Next Chapter in Swift Build Technologies by ChrisMarshallNY on Saturday February 01, 2025 @09:45PM (#42905182)
Personally, I never liked AppCode. It was too much like Eclipse (which I also never liked).

Me not liking something, does not make it bad. It’s just not my choice. I’m glad it existed, because it probably prompted Apple to do better with Xcode. Lots of people that I respect, used it.

These days, Xcode is Big Bug Ranch. When “Delete the DerivedData folder” is S. O. P. for developers, and Apple tweaked Xcode to reduce its impact on the project, you know that they have waved a white flag to bugs.

Re:The Next Chapter in Swift Build Technologies by joseda-hg on Saturday February 01, 2025 @10:08PM (#42905358)
There's even history of it working before, with Google / Kotlin
Re:The Next Chapter in Swift Build Technologies by pjmlp on Sunday February 02, 2025 @01:58AM (#42906666)
Since Apple has moved themselves out of the server market, folks need to at least be able to target BSD/Linux server workloads, and naturally using Swift as well instead of another language is a desired option.
Re:The Next Chapter in Swift Build Technologies by makeitdouble on Saturday February 01, 2025 @06:53PM (#42903873)
That crowd has the disadvantage of not being primarily interested in the other platforms, so they won't be much invested in optimizing or better matching the target capabilities.

That's the same dynamic as web devs writing React Native apps: you won't expect them to contribute extensions that manipulate local apfs metadata for instance.

So while it's nice to have them use the tools, you still need people who primarily care for non Apple platform and embrance swift for their purpose to have it expand.

Re:The Next Chapter in Swift Build Technologies by qaq on Saturday February 01, 2025 @07:50PM (#42904311)
Hmm Snowflake and Apple are rewriting FoundationDB in Swift. Swift has pretty good dev. ergonomics and good interop with C/C++ so it might find it's niche outside of Apple.
Re:The Next Chapter in Swift Build Technologies by pjmlp on Sunday February 02, 2025 @01:56AM (#42906657)
That crowd needs other platforms when using servers, as Apple has moved itself out of the server market, so at very least BSD/Linux workloads.