Most active commenters
  • easeout(4)
  • bluepizza(3)

←back to thread

Apple is open sourcing Swift Build

(www.swift.org)
612 points dayanruben | 15 comments | 01 Feb 25 16:44 UTC | HN request time: 0.001s | source | bottom
Show context
uhura ◴[01 Feb 25 19:07 UTC] No.42901158[source]▶
I believe that this long game of Swift being "good for everything" but "better for Apple platforms" will be detrimental to the language. This does not help the language nor seems to bring more people to the ecosystem.

Competitors seems to have a combination of: - Being more open-source - Have more contributors - Have a narrower scope

Maybe they should consider open sourcing all the tooling (like Xcode) otherwise the gap will only grow over time when compared to other languages.

replies(10): >>42901489 #>>42901515 #>>42901558 #>>42902281 #>>42902484 #>>42903459 #>>42903586 #>>42903797 #>>42905687 #>>42906498 #
jitl ◴[01 Feb 25 23:44 UTC] No.42903797[source]▶
I don't get this reaction.

Apple: here, we're open-sourcing this previously closed-source Apple-specific thing that made Swift better on Apple platforms. We're moving the Apple stuff into a plugin so Windows and Linux can be equal peers to Apple in the new system. We've implemented preliminary support for Windows & Linux and plan to continue work to bring them up to parity.

Hacker News: I believe that this long game of Swift being "good for everything" but "better for Apple platforms" will be detrimental to the language. This does not help the language nor seems to bring more people to the ecosystem.

Like, what more do you want from them? For them to only open-source Swift Build once they've fully implemented complete parity for Windows and Linux? In the years you'd be waiting for full parity, we'd still see this same kind of comment on every story about swift, asking when they're going to open source a production-level build system.

replies(5): >>42903995 #>>42904739 #>>42905069 #>>42906990 #>>42919105 #
1. bluepizza ◴[02 Feb 25 01:41 UTC] No.42904739[source]▶
I don't get this reaction.

Almost every language in the world: here's the spec, the tooling, and everything you need to use, master, and expand this language. Please use it.

Apple: sorry, Mac only.

Like, I want Apple to do the bare minimum that everyone else is doing.

replies(1): >>42905102 #
2. easeout ◴[02 Feb 25 02:33 UTC] No.42905102[source]▶
Swift announced Linux support in 2015 when it went open source. Aspects of parity have taken years, and the Objective-C interop that isn't relevant outside Apple platforms but made adoption take off at all occupied a lot of early effort, but every Swift talk at FOSDEM today was about embedded or Linux server applications, or platform-agnostic C++ and Java interop. What can you possibly mean by "Mac only" or "bare minimum"?
replies(2): >>42905273 #>>42905601 #
3. bluepizza ◴[02 Feb 25 02:57 UTC] No.42905273[source]▶
Core libs and foundation for starters?

https://www.swift.org/blog/future-of-foundation/

replies(1): >>42905394 #
4. easeout ◴[02 Feb 25 03:12 UTC] No.42905394{3}[source]▶
This, right?

https://github.com/swiftlang/swift-foundation

replies(2): >>42905540 #>>42905666 #
5. TheNightman ◴[02 Feb 25 03:35 UTC] No.42905540{4}[source]▶
Yeah I jumped into swift on Linux a while back having mostly used it on apple platforms and I couldn’t even tell anything was different. A few years ago I would’ve had to struggle with SwiftNIO but not nowadays. URLSession, Codable, etc. all there on Linux (not sure about Combine but Combine is stupid in the Swift 6 world IMO. Swift concurrency is better in almost every way).

Swift on Linux (except NixOS) is actually very good nowadays. There’s even a libadwaita library that feels a LOT like writing SwiftUI.

Feels like a lot of folks were turned off early on, found something else, and never bothered to try again (which is fair).

replies(1): >>42907016 #
6. isodev ◴[02 Feb 25 03:43 UTC] No.42905601[source]▶
Side note, I think it was hilarious that Swift was allowed on FOSDEM. Even “free” (as in you probably don’t have to pay for a developer account to use it, *unless you want to ship some binary), Swift remains an Apple product.
replies(3): >>42907121 #>>42907302 #>>42908521 #
7. bluepizza ◴[02 Feb 25 03:57 UTC] No.42905666{4}[source]▶
Which was not open source from the start?
replies(1): >>42906755 #
8. easeout ◴[02 Feb 25 07:14 UTC] No.42906755{5}[source]▶
Foundation wasn't made to be part of the Swift project until recently. 25 years ago it was the "foundation" of Cocoa, the Mac OS X API derived from NEXTSTEP. It was an Apple platform thing explicitly—now it is remade in Swift and is part of the Swift project.
9. DidYaWipe ◴[02 Feb 25 08:04 UTC] No.42907016{5}[source]▶
I also have a dim view of Combine and Swift's shitty observation regime, but what does its concurrency have to do with it?
replies(1): >>42910117 #
10. DeusExMachina ◴[02 Feb 25 08:27 UTC] No.42907121{3}[source]▶
You don't need an Apple developer account for Swift on server, Windows and Linux.

You need one only to ship apps on Apple platforms, but that's unrelated to Swift. It applies also to apps written in Objective-C, C/C++, and multi-platform language/frameworks like Dart/Flutter.

replies(1): >>42909729 #
11. briandear ◴[02 Feb 25 08:59 UTC] No.42907302{3}[source]▶
Is swift not open source?
12. Longhanks ◴[02 Feb 25 13:30 UTC] No.42908521{3}[source]▶
The Swift compiler, LLVM, Swift Standard Library, CoreDispatch, the Swift Package Manager and the Swift LLDB debugger are all FOSS and allow you to compile, debug, deploy, sell, buy and ship any binary you want under the terms of the Apache License 2.0.

Deployment of any software (unrelated to Swift) on Apple's platforms is entirely unrelated (and even then, at least on macOS you and any other user can install, sell, buy (...) any binary as desired).

13. talldayo ◴[02 Feb 25 16:40 UTC] No.42909729{4}[source]▶
I think the bigger insult towards the Open Source community is their refusal to publish Free Software on the App Store.
14. easeout ◴[02 Feb 25 17:31 UTC] No.42910117{6}[source]▶
Swift Concurrency as a feature set includes async/await and async for, which solve a large part of Combine's same problem with better safety and less setup/teardown. These days Combine is still useful, specifically for multiple observers and several cases of adapting to older event publishing sources.
replies(1): >>42929338 #
15. DidYaWipe ◴[04 Feb 25 07:41 UTC] No.42929338{7}[source]▶
Combine is for setting up observers to changes, whereas Concurrency is for async operations. I don't see the relationship.