back
283 comments
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.

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.

This has been my experience for a long time. Swift is nice but why would I waste my time working on a language that is too tied to the Apple platform even if it's open-source when we have more universal scripting languages like Python, or languages like Kotlin that are compiled but have more support (because I trust JetBrains way more than Apple at the moment), or languages that are most strict like Rust but have more momentum and safety?

They painted themselves in a corner. Apple being the best computing platform while trying to please everyone can never be a serious proposition. Either they are the best and everyone uses macOS, or we have to be so careful that any alternative is more interesting that what they propose.

This feels similar to C# and Microsoft's other CLR/.NET languages. Sure, they've broken away a bit and aren't exclusively used to run things on MS platforms, but still.

And Swift is even more tied to Apple, at least to my inexperienced eye. I'm not really an Apple person (Linux, Android), even though I once really enjoyed their hardware... Swift is so far down on my list of languages to look at that I probably will never get to it.

I doubt Apple really cares much about competing with other languages, tooling, or platforms when it comes to Swift or Xcode. They have a completely captured audience and ecosystem, and anything beyond that isn’t even a "best effort" — it's more like, "You're welcome to see if it works for you, but don’t bother us if it doesn't."
Whatever Apple's goal is being, the result is written on the wall: Swift's brand is strongly associated to Apple ecosystem for most programmers. They won't adopt it unless they're already targeting Apple's platforms.

See C#/.Net Core. It runs on Linux for so many years. But people still treat it as "Microsoft's thing".

The goal is probably rather to allow CI on the cloud. Many companies are ok with open source licenses.
Simply open sourcing major frameworks like SwiftUI would go a long way to making it usable
For folks who want opensource there is always Gnustep and Gorm/ProjectCenter.app.
> I believe that this long game of Swift being "good for everything" but "better for Apple platforms" will be detrimental to the language. T

uh, wasn't .NET open-sourced under exactly the same pro/con, except towards Windows hegemony?

Frankly, it makes me feel bad for Chris Lattner. This guy's been worked his ass off to create a genuinely new language with all the bells and whistles he can fit, and his employer is the one that held him back the most. It took years for Foundation framework to get serious multiplatform commitment, and unless something changes drastically I think that's going to be the sour taste that developers have in their mouths.

Apple in general seems to only understand software development through the lens of oppressive control. Maybe that's a security imperative for consumer products, but in Open Source it is an outright suicide pact. You have to treat every major platform as a first-class target, otherwise the major platforms will all switch to something better.

Swift is a really cool language.

But one thing that blows my mind is that if you ever encounter an "index out of range" error, the (massive) error message that you get doesn't tell you anything about where this error occurred... no line number... no nothing...

    let a = [1]
    print(a[1])
Is all you have to do to reproduce the error.

The error looks something like that https://pastebin.com/MQV82SaR

And gives you no useful information as to how it happened or how to fix it.

compare that with Golang which tells you, it happened in main.go at line 4.

    panic: runtime error: index out of range [1] with length 1
    
    goroutine 1 [running]:
    main.main()
     /Users/username/main.go:4 +0x15
    exit status 2
EDIT: with the LLVM_SYMBOLIZER_PATH set https://pastebin.com/8M9Dbrgj this doesn't provide anything useful either.
You have a stack dump, which means you will get all the information if you symbolicate your crash report. Xcode can do it for you automatically, but some manual methods also exist.
I am getting proper error feedback,

``` swift_hello_main + 322 in swift-hello at /home/fermi/Documents/temp/swift-hello/Sources/main.swift:64:8

    62│
    63│ let a = [1]
    64│ print(a[1])
      │        ▲
    65│
```
What if you follow the advice here

>Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):

?

The Swift REPL sucks for this. I would suggest you compile to a binary and use your normal debugging tools.
Swift outside of Xcode is a bit rough around the edges, I think because more attention goes into making Xcode friendly. I opened Xcode, made a new playground, and hit run, the code crashes and highlights the line where the error occurred in red. Not to excuse Swift's jankyness, just saying that the kind of default experience is more an IDE-first design compared to Go's very good unix-first design.

https://monosnap.com/file/qhlwD6aXUW5bcl3TV5lPmKFDgjWDtD

Thanks for reminding me of why I shy away from Swift and dove into the arms of Kotlin Multiplatform.
Verbosity. That's..... yap-ple!
Swift itself is a great piece of tech.

But it is doomed to fail as a general widely adopted language unless apple makes few critical moves including open sourcing everything including XCode, providing support for 3d party IDE developers (because xcode is terrible), creating decent package manager, adopting testing as first class citizen etc.

There is just no economical sense for anyone to invest in swift until all the above (and some more) is done.

For what it's worth, they ship a solid VS Code extension and LSP. Their swift-testing package is the new open source and cross-platform successor to XCTest. The same can be said of swift-foundation as compared to Foundation.

The path they've chosen is not to open source Xcode, but to move the things Swift needs on all platforms to the Swift language project and common implementations.

Personally I think the main problem with the language, besides Apple's earned poor reputation in FOSS circles, is the compile times. In the source-stable era of the language I'm not sure how they can really be fixed to the degree I'd be happy with.

Your wishlist seems midly contradictory. Why does Apple need to open-source XCode if they also provide support for 3rd party IDEs (which they already do, btw)? Also what do you not like about cocoapods for package management?

Plenty of people make an incredible amount of money building apps in Swift, so your last sentence is just wrong.

And make it possible to run binaries on macOS/iOS etc without a mandatory subscription and US export controls. Without notarisation, anything made with Swift is practically unusable on Apple OSs
It’s written Xcode.
The discussion here reminds me so much of early C# days. It was being touted as open source and cross platform back then, and Microsoft even hired a top GNOME developer to port it to Linux and GNOME was going to be rewritten in C#. It was going to be amazing. Never quite panned out.
The goal for Swift should (and seems) to be to gradually separate itself from XCode, which is holding it back from its ambitions.

XCode has been compared to many things, but at 3.1 stars on the App store, one must find that it is still slightly overrated.

from the article:

> With this release, SwiftPM now has the opportunity to offer a unified build execution engine across all platforms.

this is what the big deal is. it might not achieve much on its own immediately, but this is the key to build a truly multiplatform ecosystem of libraries, tools and applications in Swift. we should expect to see more of that soon.

Apple’s software decisions over the last 15 years have created significant friction for developers trying to build on their platforms. Apple’s approach to software development has felt like it’s prioritizing business interests over the ease and flexibility that developers need to build high-quality, useful software.
Swift is a nice language. I'm glad to see it being released from the clutches of Apple. I can only imagine how large of a task this is. I hope some day to be able to use it. The last time I tried a cross-platform project with it I switched languages due to `URLSession.shared.data` (a network request) being unable to compile on Linux.
Is Swift actually serious about embedded?
This is great, if for no other reason that it will give people the ability to debug build issues on their own and get access to fixes without having to wait for the next Xcode release.
> a foundational step in this new chapter of Swift build technologies

The corporate language throughout that post is pretty cringe. It seems so unnecessary.

Reading this it’s not clear - how well integrated is swift build with swift’s tooling and language server? I know the language server has been open source for a while now. Having them be separate seems like it would create issues with duplicate code.
Does this open a path to Swift development without Xcode?

Recent discussion of Xcode, https://news.ycombinator.com/item?id=42803290

The article doesn't mention the differences with current swift package manager build system. The repository doesn't mention it either, just saying that swiftpm can use the new build system by adding an argument. Anybody does what does this actually changes? Does it improve something for non-Apple platforms?
It’s too late
i'd love to be able to build web servers in Swift. the language is such a joy to use
I wish swift was built against normal LLVM instead of against Apple's fork of it.
I wish they would stop adding anything to the language and document what they have. I constantly need to reverse engineer how things work. For example, I just had to integrate AccessorySetupKit and the docs are laughable.
Does the world need yet another build system? (not sure, just thinking out loud)
Can I cut and paste a Core Data Model that my LLM generated?