Apple is open sourcing Swift Build(swift.org)
swift.org
Apple is open sourcing Swift Build
https://www.swift.org/blog/the-next-chapter-in-swift-build-technologies/
299 comments
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.
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.
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.
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.
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"?
Core libs and foundation for starters?
https://www.swift.org/blog/future-of-foundation/
https://www.swift.org/blog/future-of-foundation/
This, right?
https://github.com/swiftlang/swift-foundation
https://github.com/swiftlang/swift-foundation
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).
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).
I also have a dim view of Combine and Swift's shitty observation regime, but what does its concurrency have to do with it?
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.
Combine is for setting up observers to changes, whereas Concurrency is for async operations. I don't see the relationship.
Which was not open source from the start?
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.
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.
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.
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.
I think the bigger insult towards the Open Source community is their refusal to publish Free Software on the App Store.
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).
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).
Is swift not open source?
They should have been fully open source with full linux support and parity since day one.
That would actually help the language get traction. At this point it's a dying language.
That would actually help the language get traction. At this point it's a dying language.
> At this point it's a dying language.
I disagree.
Source: Someone who has been programming Apple since 1986, and has heard last rites being administered to Apple, many times.
I disagree.
Source: Someone who has been programming Apple since 1986, and has heard last rites being administered to Apple, many times.
Is it dying? I think it's still pretty popular for app development isn't it?
I was pretty excited to hear that Ladybird is doing a lot of stuff in Swift, because I think it's a pretty decent and fast language and I think it'd be pretty neat to see a browser written in it.
I was pretty excited to hear that Ladybird is doing a lot of stuff in Swift, because I think it's a pretty decent and fast language and I think it'd be pretty neat to see a browser written in it.
It's essentially "Big in Japan" (eg on Apple platforms but nowhere else). Even on Apple platforms I winder if ObjC is actually still more popular ;)
Well if you wonder you should conduct some simple research, but be prepared to have your opinion challenged. Swift ist doing very fine and much more popular than ObjC (again, if you don't believe it, invest 5 minutes into research).
Lol, as long as it’s the preferred programming language for the most lucrative consumer devices ever, it cannot die.
Impossible to argue otherwise.
Impossible to argue otherwise.
What language are you using to develop native apps for macOS and iOS and visionOS and watchOS, since Swift is dying?
C#, Unity.
Which rely on a mix of Objective-C and Swift APIs to actually interact with the platform.
What's your point? That's what Apple makes available. I'd use the C# API if that's how they provided it.
If not dominating the games on those plarforms, Unity and C# have a strong footing to say the least. Swift doesn't seem to be making very much headway on platforms where APIs are available in anything else.
Maybe that can chance. It seems like a neat language but "it's popular because apple forces you to use it" is more damning than reassuring.
If not dominating the games on those plarforms, Unity and C# have a strong footing to say the least. Swift doesn't seem to be making very much headway on platforms where APIs are available in anything else.
Maybe that can chance. It seems like a neat language but "it's popular because apple forces you to use it" is more damning than reassuring.
The point is that they are guest languages on Apple ecosystem and need Apple tooling and languages as means being available.
I may also add that I dislike Microsoft doesn't give to the .NET ecosystem the same care for games developers as Apple does for Swift and existing OS SDKs.
As far as DirectX team is concerned, only C++ exists, and .NET team lets third party folks do the needful.
Had it not been for MonoGame, Unity would never picked C# in first place, gone were the days of Managed DirectX and XNA, when the decision came to be as Unity did their cross-platform rewrite out of OS X.
I may also add that I dislike Microsoft doesn't give to the .NET ecosystem the same care for games developers as Apple does for Swift and existing OS SDKs.
As far as DirectX team is concerned, only C++ exists, and .NET team lets third party folks do the needful.
Had it not been for MonoGame, Unity would never picked C# in first place, gone were the days of Managed DirectX and XNA, when the decision came to be as Unity did their cross-platform rewrite out of OS X.
The specifics of C# are fairly irrelevant. Point is that even if swift is forced, middleware can and will just plaster over that. Even if Metal is forced, tools can plaster over that.
Apple forcing an API is not enough to sustain a language's popularity.
Apple forcing an API is not enough to sustain a language's popularity.
When the language is required for one of two mobile ecosystems, and second major desktop ecosystem, popularity is relative.
For decades C# was only relevant on Windows, outside Unity never got wide adoption among AAA studios after Unreal became free, and after their license debacle less so, Godot favors C++ and GDScript even with C# support it isn't what most folks reach for, and Microsoft keeps having an adoption (popularity) problem on UNIX culture oriented startups.
While just like Swift on Apple's ecosystem, C# is doing just fine on Microsoft culture environments.
Popularity is relative.
For decades C# was only relevant on Windows, outside Unity never got wide adoption among AAA studios after Unreal became free, and after their license debacle less so, Godot favors C++ and GDScript even with C# support it isn't what most folks reach for, and Microsoft keeps having an adoption (popularity) problem on UNIX culture oriented startups.
While just like Swift on Apple's ecosystem, C# is doing just fine on Microsoft culture environments.
Popularity is relative.
There's a lot more buzz and activity around Swift than many other languages. It's literally up there with Rust, in terms of excitement (perhaps not quite as high). But I think if they get excitement outside of the Apple ecosystem, things should start to get super interesting.
Some are already adopting it like Ladybird browser.
Some are already adopting it like Ladybird browser.
If we're trading anecdotes, I'll share mine as someone's who's completely outside of Apple ecosystem and is not interested in it in the slightest: I only ever hear about Swift on HN, nowhere else. Most of my colleagues, friends and acquaintances (who is in IT, but none of whom are Apple users) don't even know it exist, while everyone has at least heard about Rust. We all live in bubbles, admit it.
Sorry to be mood killer, but I think that might be your bubble. That's a first news about Swift I've seen in a long time and I don't see a reason to try it, given alternatives. Nowhere near Rust level of presence in discussion.
trolling for reactions is trite and predictable
Come on now, iOS development is my livelihood.
No one uses Apple platforms
- sent from my iPhone
Amen. Just knee-jerk negativity with no specific objections.
> Like, what more do you want from them?
You know what we want from them. If Apple wants to be accepted by the Open Source community, they can't reprise the Microsoft playbook with a smug "Think Different" twist. This is basically a beat-for-beat rerun of the C#/Dotnet situation with a different font and Corinthian leather.
The internet at-large is sick and tired of tending to Apple's scraps at their obscure whims. If you are a developer that isn't already implicated to use Swift for iOS development, you'd be wasting your time doing Cupertino's work bringing up their language for them. They do not care, and only want to exploit your time and productivity like they do with the App Store. Much like C#, this is a scenario where everyone but the main benefactor will be thrown under the bus.
You know what we want from them. If Apple wants to be accepted by the Open Source community, they can't reprise the Microsoft playbook with a smug "Think Different" twist. This is basically a beat-for-beat rerun of the C#/Dotnet situation with a different font and Corinthian leather.
The internet at-large is sick and tired of tending to Apple's scraps at their obscure whims. If you are a developer that isn't already implicated to use Swift for iOS development, you'd be wasting your time doing Cupertino's work bringing up their language for them. They do not care, and only want to exploit your time and productivity like they do with the App Store. Much like C#, this is a scenario where everyone but the main benefactor will be thrown under the bus.
Damned if you do, damned if you don’t. The perfect way to draw companies to embrace open source.
They don't embrace Open Source, that's the problem. I don't even have to invoke the Halloween Documents to erode faith in FAANG as an Open Source steward, half this thread retched at the idea of using Swift out of principle.
Apple is welcome to head down the same road they're going if they think it's working out for Swift. Developers aren't going to magically warm to it any more than they trusted C# unless Apple makes some unprecedented change in their attitude towards Open Source. The world doesn't owe them shit.
Apple is welcome to head down the same road they're going if they think it's working out for Swift. Developers aren't going to magically warm to it any more than they trusted C# unless Apple makes some unprecedented change in their attitude towards Open Source. The world doesn't owe them shit.
Just like any other big corps, for every big corp you might think of, I can provide an anti-Open Source example from one of their business units.
Lets play this game?
Lets play this game?
Go ahead. Free Software has no obligation to satisfy the criteria of FAANG's business units, I'd actually find it quite funny to hear the litany of complaints you've compiled for a group of people that barely knows you exist.
I'm a bit confused about the "don't trust Apple" sentiment here.
Swift has been working seamlessly with Linux and Visual Studio Code for years now. You might be surprised to learn this, just like this guy was https://www.youtube.com/watch?v=LTP5c4NqA8k&t=5484s
Swift is compatible with WASM and embedded systems. It has a well-defined concurrency standard, and as a compiler, it's been tested with massive codebases worldwide.
The community is incredibly supportive (Ted Kremenek's team is super active, attending community conferences and supporting the Server Side Workgroup). They also have an open swift-evolution process that mostly works.
Xcode not being open-sourced? Not a big deal. It's an older codebase optimized for different use cases. Their approach is to break Swift down into smaller, focused components (Package Manager, LSP server, a formatter, etc.)
JetBrains didn't open-source their IDEs either, and people don't complain about it. So, it's the same story, but it's better since you don't have any historical issues like "Oracle JVM" lurking around, causing trouble for the community.
Swift has been working seamlessly with Linux and Visual Studio Code for years now. You might be surprised to learn this, just like this guy was https://www.youtube.com/watch?v=LTP5c4NqA8k&t=5484s
Swift is compatible with WASM and embedded systems. It has a well-defined concurrency standard, and as a compiler, it's been tested with massive codebases worldwide.
The community is incredibly supportive (Ted Kremenek's team is super active, attending community conferences and supporting the Server Side Workgroup). They also have an open swift-evolution process that mostly works.
Xcode not being open-sourced? Not a big deal. It's an older codebase optimized for different use cases. Their approach is to break Swift down into smaller, focused components (Package Manager, LSP server, a formatter, etc.)
JetBrains didn't open-source their IDEs either, and people don't complain about it. So, it's the same story, but it's better since you don't have any historical issues like "Oracle JVM" lurking around, causing trouble for the community.
> I'm a bit confused about the "don't trust Apple" sentiment here.
Let me help you out; replace "Apple" with "Microsoft" and it will make a lot of sense suddenly.
The Open Source community has heard all this before. We've seen Sun Microsystems "generously" publish their Java spec to the public, we've seen Microsoft "give" their community C#. In the end, it's always more trouble than it's worth to cooperate with these language stewards and someone (either the business or community) ends up getting burned. I don't think many developers look at Swift with optimism that it won't end in the same Dotnet/Mono nightmare we've seen in the past.
You can lead a horse to water, but you can't make them drink. Apple has invested heavily in a language that, like C#, has a bunch of incredible features. Unfortunately they have yet to invest in the developer relations requisite for making such a language popular. Lord only knows that I'm not wasting my time to do Apple's work for them just to get a cross-platform app to compile with upstream LLVM and Clang. I could use any other language - nobody is going to commit to an ecosystem that treats them as a second-class citizen.
Let me help you out; replace "Apple" with "Microsoft" and it will make a lot of sense suddenly.
The Open Source community has heard all this before. We've seen Sun Microsystems "generously" publish their Java spec to the public, we've seen Microsoft "give" their community C#. In the end, it's always more trouble than it's worth to cooperate with these language stewards and someone (either the business or community) ends up getting burned. I don't think many developers look at Swift with optimism that it won't end in the same Dotnet/Mono nightmare we've seen in the past.
You can lead a horse to water, but you can't make them drink. Apple has invested heavily in a language that, like C#, has a bunch of incredible features. Unfortunately they have yet to invest in the developer relations requisite for making such a language popular. Lord only knows that I'm not wasting my time to do Apple's work for them just to get a cross-platform app to compile with upstream LLVM and Clang. I could use any other language - nobody is going to commit to an ecosystem that treats them as a second-class citizen.
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.
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.
> 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.
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.
> 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.
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.
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.
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.
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.
There's even history of it working before, with Google / Kotlin
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.
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.
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.
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.
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.
Can only speak for myself, but I’d love to be able to use Swift elsewhere so I don’t need to drag around a JVM and all the things that come with it (Kotlin) or have to wrestle with Rust’s sematics and disinclination towards old style imperative desktop UI development. Swift isn't perfect of course, but it’s the closest I’ve come to a language feeling “comfy”.
You mean like the huge ecosystem of libraries for almost anything one can thing of, and IDE tooling, with 30 years of experience in production?
I was using Swift before. Currently learning Rust. Want to use it for cross-platform UI, and I'm stuggling with exactly what you describe there.
So you haven't heard of Kotlin Multiplatform.
What are your experiences of using Kotlin for modern macOS/iOS development? How's the support looking when Apple releases new XCode?
Kotlin Multiplatform (KMP) is neat for android devs that want to be able to code for both platforms using a toolset/language they are familiar with, but for iOS development KMP is a hassle (personal opinion). I’d rather just write the code twice. Also, I actually like Xcode. As for Android Studio, up until the more recent versions the GUI felt really clunky to me (which made working in it a bit of a slog).
Have heard of it, haven’t investigated it deeply. Looks to still have some of the less-great points of the Java ecosystem on the build side of things (gradle) which is a detractor for me.
Kotlin’s syntax is also weird/quirky in some ways.
Kotlin’s syntax is also weird/quirky in some ways.
> Kotlin’s syntax is also weird/quirky in some ways.
I'm curious to learn what you mean by this! :)
I'm curious to learn what you mean by this! :)
No terenary if and the elvis operator, for one. Stuff like that trips me up frequently when jumping between Kotlin and Swift/other C-likes.
Ah, I see. Tbh, I actually like the lack of ternary and elvis, they are nicely handled by if expression (as the other comment notes)
Or Dart
> languages that are most strict like Rust but have more momentum and safety?
Like Rust, Swift is a compiled language that offers memory safety by default.
The creator of Clang and LLVM also created Swift, and interoperability with C was an explicit design goal.
So Swift offers the memory safety and data race safety of Rust, in a compiled language, without giving up tight integration with C.
(To be fair, better C integration is something the Rust community is looking to add.)
Like Rust, Swift is a compiled language that offers memory safety by default.
The creator of Clang and LLVM also created Swift, and interoperability with C was an explicit design goal.
So Swift offers the memory safety and data race safety of Rust, in a compiled language, without giving up tight integration with C.
(To be fair, better C integration is something the Rust community is looking to add.)
fwiw Swift still doesn't support mixed-language targets so the interop is somewhat less useful to me than I'd like: https://forums.swift.org/t/se-0403-package-manager-mixed-lan...
The creator of Rust also briefly worked on Swift
> Either they are the best and everyone uses macOS
"Best" obviously means different things to different people, but at least by market share, macOS has never been the best. Modern Apple doesn't seem to care about market share outside of the iPhone (and even then, they are still more interested in the iPhone being a premium product than winning on market share).
I used to like macOS, 15-20 years ago, but now it's just power-user-hostile and considerably more locked down and buggy. That's not the way to be "best", by any metric I can think of.
"Best" obviously means different things to different people, but at least by market share, macOS has never been the best. Modern Apple doesn't seem to care about market share outside of the iPhone (and even then, they are still more interested in the iPhone being a premium product than winning on market share).
I used to like macOS, 15-20 years ago, but now it's just power-user-hostile and considerably more locked down and buggy. That's not the way to be "best", by any metric I can think of.
> but now it's just power-user-hostile and considerably more locked down and buggy.
Sure, macOS has continued to secure more and more elements of the OS. They have taken a different approach than Windows and Linux, which both keep large swaths of the OS woefully insecure from third-party apps for legacy reasons. But for each and every new lock, there is a key. An incredibly secure OS that gives you the power to control what third-party apps access on your computer is the best power-user feature.
Sure, macOS has continued to secure more and more elements of the OS. They have taken a different approach than Windows and Linux, which both keep large swaths of the OS woefully insecure from third-party apps for legacy reasons. But for each and every new lock, there is a key. An incredibly secure OS that gives you the power to control what third-party apps access on your computer is the best power-user feature.
Mac OS does some amazing things for security. An immutable root OS, sandboxing, very user friendly disk encryption.
But there are certainly decisions that hold back the platform.
Their business decisions have driven most developers away from the App Store.
There is a notarization process, but it imposes a burden that many small open source projects can not bear.
They don't have an easy way to run untrusted software in a containerized way (compare Fedora toolbox). Installing things globally via homebrew or a random install script is still the way to go.
> Their business decisions have driven most developers away from the App Store.
> They don't have an easy way to run untrusted software in a containerized way (compare Fedora toolbox).
The App Store is the way to run untrusted apps in a containerized way.
> They don't have an easy way to run untrusted software in a containerized way (compare Fedora toolbox).
The App Store is the way to run untrusted apps in a containerized way.
I think if your app is on the App Store, it's kind of trusted by definition, isn't it?
It's "the way" that apple wanted it to be, but it's not the way that humans have chosen.
Typically not a great idea to be against humans, especially the ones that give you money.
Typically not a great idea to be against humans, especially the ones that give you money.
> especially the ones that give you money
Last time I checked, their market cap was North of $3T, so someone is giving them money…
Last time I checked, their market cap was North of $3T, so someone is giving them money…
They're also hitting the classic "strategy tax"
When Apple secured the OS from third party, they also purposefully closed the door on deeper third party integration to privilege their ecosystem.
macOS only being half as useful for Android users makes it harder to be the "best" for that swath of users. iPadOS being the only tablet form in the ecosystem will also distance other users etc. They just can't please everyone while locking them in a limited ecosystem.
When Apple secured the OS from third party, they also purposefully closed the door on deeper third party integration to privilege their ecosystem.
macOS only being half as useful for Android users makes it harder to be the "best" for that swath of users. iPadOS being the only tablet form in the ecosystem will also distance other users etc. They just can't please everyone while locking them in a limited ecosystem.
> now it's just power-user-hostile and considerably more locked down and buggy
Hm, I've been using macOS (alongside others) for the past 20 years straight. In what ways is it hostile and buggy?
Hm, I've been using macOS (alongside others) for the past 20 years straight. In what ways is it hostile and buggy?
Secure Enclave, having to use only signed apps and kernel extensions, stuff like that I imagine.
See https://skip.tools for a new entrant
The Python ecosystem is a sad mess.
Python is not compiled, it is interpreted, and it has many warts.
Kotlin depends on the JVM and is also not compiled.
Rust? Now you're talking. Except that it has warts, too.
Kotlin depends on the JVM and is also not compiled.
Rust? Now you're talking. Except that it has warts, too.
Kotlin is compiled in the sense that it compiles down to bytecode read by the JVM. It's not machine code level but it is still compiled to a certain degree.
And Kotlin can compile natively for multiple targets including macOS and iOS without need for the JVM. There's also WASM support too.
Did not know about non-JVM compilation. Does it include the JVM as part of the binary then? Links?
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.
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.
.net core is one of the best ways to write linux backend applications.
this, because msft spent years and many $$$ to build an open-source ecosystem. apple hasn't done that yet, so I'm not sure why anyone would trust them
Amazing that you comment that on an announcement that is one large effort of many that Apple have been doing to build an open-source ecosystem over many years...
> 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.
A wrong and quite outdated statement. You can develop and run C# on Linux only using open source tooling perfectly fine. I'm using Ubuntu, LazyVim with Omnisharp, dotnet CLI for scaffolding and package management. It's in the same ballpark as Go and Rust in terms of dev experience. I don't have numbers, but I guess a large fraction of new deployments is on Linux.
A wrong and quite outdated statement. You can develop and run C# on Linux only using open source tooling perfectly fine. I'm using Ubuntu, LazyVim with Omnisharp, dotnet CLI for scaffolding and package management. It's in the same ballpark as Go and Rust in terms of dev experience. I don't have numbers, but I guess a large fraction of new deployments is on Linux.
I don't understand what "broken away a bit" means. We use C#/.Net pretty much exclusively to build the backend of our web apps).
Most of the devs use Mac, with some Linux. Everything is run in Kubernetes (OpenShift). we use JetBrains Rider as our IDE.
C# is a very nice, very performant (faster than Go) language, the platform is mature and robust. the tooling is excellent. It gives you good garbage collection, strong type safety, etc. All the things you need to build out the logic of business applications. And it's fully open source.
I have looked at Swift. By comparison, the tooling is 10 years behind and the performance is not even close. I struggle to see what Swift brings to the table over C#.
Most of the devs use Mac, with some Linux. Everything is run in Kubernetes (OpenShift). we use JetBrains Rider as our IDE.
C# is a very nice, very performant (faster than Go) language, the platform is mature and robust. the tooling is excellent. It gives you good garbage collection, strong type safety, etc. All the things you need to build out the logic of business applications. And it's fully open source.
I have looked at Swift. By comparison, the tooling is 10 years behind and the performance is not even close. I struggle to see what Swift brings to the table over C#.
If you want to use Visual Studio Code the 'DevKit' extension which provides essential features (language server) is proprietary and requires a Visual Studio licence regardless of platform.
Also I find since C# is an 'enterprise' language developers take the p--s in what they want to charge for, as enterprise will pay as a 'cost of doing business'. Recently FluentAssertions, a freakin test assertion library decided they wanted to charge for newer versions. You don't get that in other languages like Python/Ruby etc.
https://youtu.be/ZFc6jcaM6Ms
Don't get me wrong, C# is my dayjob and I love the language but for personal projects where I don't have the money I'd be hesitant to touch it.
Also I find since C# is an 'enterprise' language developers take the p--s in what they want to charge for, as enterprise will pay as a 'cost of doing business'. Recently FluentAssertions, a freakin test assertion library decided they wanted to charge for newer versions. You don't get that in other languages like Python/Ruby etc.
https://youtu.be/ZFc6jcaM6Ms
Don't get me wrong, C# is my dayjob and I love the language but for personal projects where I don't have the money I'd be hesitant to touch it.
DevKit is completely optional.
The language server is part of the SDK itself. The language server integration, debugger and all the features that make VS Code a good tool to write C# in are a part of base C# extension which is MIT-licensed and has no commercial restrictions whatsoever.
The only "wart" is that "vsdbg" - debugger it ships with is closed-source because it is essentially the same debugger as in Visual Studio but extracted into a standalone cross-platform component. There is an open alternative "NetCoreDbg" used by the extension fork for VSCodium (and various DAP bridges to Neovim, Emacs, etc.).
The language server is part of the SDK itself. The language server integration, debugger and all the features that make VS Code a good tool to write C# in are a part of base C# extension which is MIT-licensed and has no commercial restrictions whatsoever.
The only "wart" is that "vsdbg" - debugger it ships with is closed-source because it is essentially the same debugger as in Visual Studio but extracted into a standalone cross-platform component. There is an open alternative "NetCoreDbg" used by the extension fork for VSCodium (and various DAP bridges to Neovim, Emacs, etc.).
Go to definition still broken on neovim for me :/. I should be seeing SourceLinked stuff but nothing happens
I used C# on .NET framework (the old .NET running only on Windows) 10 years ago at work. Then I had to use it 2 years ago again, and man, did it change! ASP.NET Minimal API is absolutely awesome, as the Generic Host integrating config, logging and DI is a great too. A very mature and complete framework.
It brings everything to the table a great modern language and ecosystem needs. Even null safety.
Regarding error handling, I don't have a strong opinion yet. I think Rust has nailed it, but C# (with unchecked exceptions) didn't create any issues in the projects I worked on.
It brings everything to the table a great modern language and ecosystem needs. Even null safety.
Regarding error handling, I don't have a strong opinion yet. I think Rust has nailed it, but C# (with unchecked exceptions) didn't create any issues in the projects I worked on.
Sorry to hear that, I wouldn't bet anything on Apple but the core language contains a lot of good ideas imho.
Seems lovely but headed in a Scala-like bloated direction. The "too complex" type issues were really bad last I tried.
And one of my biggest gripes is the way you can extend things from anywhere else, easy to cause a mess.
And one of my biggest gripes is the way you can extend things from anywhere else, easy to cause a mess.
Swift is getting out of hand after Chris left and Swift UI was introduced. The language has over 210 keywords… thats crazy
Keywords are a bad way to judge a language.
Not saying you are wrong but tell me why it would be a good idea to have hundreds of keywords for a programming language.
Because not having hundreds of keywords means that either you have some parts of the language that are "this has a special meaning please don't touch" (double underscores are good enough, right guys?) or "we reassigned 10 different things to the same keyword to keep the number low" (ahem, static).
Hm, I have to admit I have the same feeling.
But it is a shame, because many of the ideas are good imho.
But it is a shame, because many of the ideas are good imho.
I’ve spent some time looking into swift as well and was quite pleased with the overall language, it really contained some really good ideas. This makes it a bit of a shame that it is tied so closely to Apple
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."
I don't know about Xcode, but Swift is open source with an active community so if it doesn't work for you then you can definitely bother the Swift Open-Source project with a pull request or a proposal for a language or tooling improvement. You can also have a discussion on the forums or in the bug tracker with fellow contributors.
You can also make the change in your own fork and use that.
This is exactly how for example the Rust or Python open source projects work. And like those projects you can look at the Swift proposals and code to see _numerous_ cases where people did bother to bother the team with change requests or directly contributed to those improvements.
It is all open source. Check it out.
You can also make the change in your own fork and use that.
This is exactly how for example the Rust or Python open source projects work. And like those projects you can look at the Swift proposals and code to see _numerous_ cases where people did bother to bother the team with change requests or directly contributed to those improvements.
It is all open source. Check it out.
Scooby doo meme
<Open source contributor> “let’s see who you really are”. <pulls off mask>. Apple employee.
<Open source contributor> “let’s see who you really are”. <pulls off mask>. Apple employee.
Does it matter? Most commits to OpenJdk are Oracle employees and most committees to C# or typescript are Microsoft employees.
All 1100+ contributors are Apple employees?…
Are 1100+ contributors active contributors and/or actually making non-trivial changes?
a) If Apple didn't care about competition they wouldn't have created Swift.
b) They don't have a captured ecosystem at all. You can write iOS/macOS apps using Flutter, React Native etc. All of which are detrimental to Apple because they force apps to adopt a lowest common denominator approach and not use the latest Apple technologies.
b) They don't have a captured ecosystem at all. You can write iOS/macOS apps using Flutter, React Native etc. All of which are detrimental to Apple because they force apps to adopt a lowest common denominator approach and not use the latest Apple technologies.
> All of which are detrimental to Apple because they force apps to adopt a lowest common denominator approach and not use the latest Apple technologies.
I think you might have this backwards. What you say used to be true back in the days of phonegap, where the hardware was abstracted far away, but all of the frameworks you mention provide pretty easy paths to access new APIs and hardware features. But companies that are drawn to cross-platform tooling already want a uniform experience across devices - and that's why you get the lowest common denominator being used with tools like react native.
I think you might have this backwards. What you say used to be true back in the days of phonegap, where the hardware was abstracted far away, but all of the frameworks you mention provide pretty easy paths to access new APIs and hardware features. But companies that are drawn to cross-platform tooling already want a uniform experience across devices - and that's why you get the lowest common denominator being used with tools like react native.
> anything beyond that isn’t even a "best effort"
Ehhh, I don't know, whoever's designing and implementing Swift and Xcode etc clearly genuinely care on a personal level about quality. I get that there's going to be taste involved but the amount of thought and effort that's gone into the ecosystem is very high.
Ehhh, I don't know, whoever's designing and implementing Swift and Xcode etc clearly genuinely care on a personal level about quality. I get that there's going to be taste involved but the amount of thought and effort that's gone into the ecosystem is very high.
Xcode as an example of quality? It's atrocious from my experience.
Updates tied to OS and crashes more than it should.
Updates tied to OS and crashes more than it should.
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".
See C#/.Net Core. It runs on Linux for so many years. But people still treat it as "Microsoft's thing".
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?
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.
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.
Lattner hasn't been working at Apple since 2017.
Lattner left Apple a long while ago. He's been working on Mojo, a different (Pythonic) language and runtime: https://www.modular.com
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...
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.
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])
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
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.
Indeed the error report being complained about explains this and tells you how to fix it.
Maybe the friendly default would be to have the symbolicated reports on, but perhaps this has performance impact so it’s off.
Maybe the friendly default would be to have the symbolicated reports on, but perhaps this has performance impact so it’s off.
> Maybe the friendly default would be to have the symbolicated reports on
As a comment just below says, the solution is quite simple:
> ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it
As a comment just below says, the solution is quite simple:
> ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it
Here is the output with the environment variable set.
https://pastebin.com/8M9Dbrgj
This doesn't provide anything useful either.
https://pastebin.com/8M9Dbrgj
This doesn't provide anything useful either.
Seems like there's an architecture error or something, the last line indicates you might have an error with the flag:
> zsh: illegal hardware instruction LLVM_SYMBOLIZER_PATH=/usr/local/opt/llvm/bin/llvm-symbolizer swift main.swift
> zsh: illegal hardware instruction LLVM_SYMBOLIZER_PATH=/usr/local/opt/llvm/bin/llvm-symbolizer swift main.swift
that's not related to the symbolizer thing. It seems to just be part of the "index out of range" crash. I get the same thing without using the symbolizer.
zsh: illegal hardware instruction swift main.swiftOuch, and yuk. I stand corrected!
[deleted]
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
``` 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):
?
>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):
?
What if the error was more descriptive out of the box? Unless of course the goal is to just compete with C++ error reporting.
The goal is to probably avoid duplicating efforts when llvm-symbolize already exists.
There’s obviously a snarky comment to make here about Go developers and duplicating efforts.
There’s obviously a snarky comment to make here about Go developers and duplicating efforts.
If I follow the advice
https://pastebin.com/8M9Dbrgj
Not sure how that's any better... I still have no idea that the error occurred on line 2
https://pastebin.com/8M9Dbrgj
Not sure how that's any better... I still have no idea that the error occurred on line 2
[deleted]
[deleted]
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
https://monosnap.com/file/qhlwD6aXUW5bcl3TV5lPmKFDgjWDtD
I'm just curious, if I was to run my application on a linux server.
How would I ever know what caused the crash?
when I compile using `swiftc main.swift` and run with `./main`, the error seems even more useless.
all I get is:
How would I ever know what caused the crash?
when I compile using `swiftc main.swift` and run with `./main`, the error seems even more useless.
all I get is:
Swift/ContiguousArrayBuffer.swift:600: Fatal error: Index out of range
zsh: illegal hardware instruction ./mainI don't know, I write Swift on a Mac targeting macOS or iOS. I usually have Xcode open to build/run/debug and for documentation lookup, and alternate between that and VSCode for actually writing the code; worst thing about Xcode for me is the find-replace, that's probably the biggest reason I keep VSCode open.
You can load the coredump into GDB.
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.
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.
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.
Are there any LLVM langs that have fast compile times? I think that just kinda comes with the territory of having that IR step + all the optimizations that happen at compile time to help runtime performance.
That's a good point. I had in mind that there's some regret about the combination of type inference with type-based overloads, due to the search expense it adds to what ought to be straightforward parsing of long expressions.
Yeah, I think there are definitely parts of the language design / language features that are going to contribute, but when you need to parse to IR and then compile that to machine code, it seems any features you add that are nice for the developer are going to doubly hurt compile times. You see the same with ARC in swift (or the borrow checker in Rust).
AFAIK those language features are all handled in the frontend before outputting LLVM IR. LLVM optimization, code generation, linking, etc. should all be the same regardless of the source language.
I don't know about that example—when ARC was added to Objective-C back in the day, I don't remember clang feeling any slower as a result.
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.
Plenty of people make an incredible amount of money building apps in Swift, so your last sentence is just wrong.
Decent support for 3d party IDE would mean open sourcing all critical xcode parts that currently leave developers no choice.
Cocoapods is too old and bad for modern era package management. It’s not made for swift also.
Cocoapods is too old and bad for modern era package management. It’s not made for swift also.
Swift Package Manager exists
Cocoapods has been end of life’d
Cocoapods has been end of life’d
[deleted]
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.
I think you might have the history mixed up a bit. The Mono project started without Microsoft's involvement (and they were probably even annoyed by it at the time).
GNOME was betting on their own Vala language, which is still a thing, but never really gained much traction.
Eventually Microsoft bought Mono during their embrace of open source.
GNOME was betting on their own Vala language, which is still a thing, but never really gained much traction.
Eventually Microsoft bought Mono during their embrace of open source.
Microsoft never had anything to do with that with nice story full of butterflies.
The only UNIX Microsoft has ever supported during pre-Satya days, was Rotor for FreeBSD, nothing else.
Mono and DotGNU had nothing to do with Microsoft until Xamarin acquisition.
The only UNIX Microsoft has ever supported during pre-Satya days, was Rotor for FreeBSD, nothing else.
Mono and DotGNU had nothing to do with Microsoft until Xamarin acquisition.
> Never quite panned out.
I don't know what you're talking about, honestly. Maybe you're many years behind the current state of affairs.
.NET (core) is a very real thing. A extremely successful and powerful multi platform framework.
I don't know what you're talking about, honestly. Maybe you're many years behind the current state of affairs.
.NET (core) is a very real thing. A extremely successful and powerful multi platform framework.
> Microsoft even hired a top GNOME developer to port it to Linux and GNOME was going to be rewritten in C#
Do you have a source for the GNOME C# claim? I can't find one.
Do you have a source for the GNOME C# claim? I can't find one.
Miguel was not a MS employee. He did parlay Xamarin into an acqui-hire though and is now a softie.
do you remember who was the 'top GNOME developer'?
Probably talking about Miguel de Icaza. I think his history is wrong though. I don't recall any talk of rewriting GNOME in C# - they were all about their pet language Vala.
And Miguel started Mono way before Microsoft made C# cross-platform. At that point they were antagonists.
And Miguel started Mono way before Microsoft made C# cross-platform. At that point they were antagonists.
Microsoft had a research version of the CLR called Rotor (2002) that predated Mono (2004). Rotor built for Windows, FreeBSD, and macOs, albeit with a not-very-open license.
When Mono came along, the internal position at Microsoft was surprisingly positive. There was a dev slide deck that went into Mono in some depth. And a telling slide that said it wasn't a threat because the performance wasn't competitive at the time.
https://en.m.wikipedia.org/wiki/Shared_Source_Common_Languag...
https://en.m.wikipedia.org/wiki/Mono_(software)
When Mono came along, the internal position at Microsoft was surprisingly positive. There was a dev slide deck that went into Mono in some depth. And a telling slide that said it wasn't a threat because the performance wasn't competitive at the time.
https://en.m.wikipedia.org/wiki/Shared_Source_Common_Languag...
https://en.m.wikipedia.org/wiki/Mono_(software)
Rotor was BSD licensed, so I suppose if that’s your definition of a not very open license…
Rotor had it's own license:
https://en.wikipedia.org/wiki/Shared_Source_Common_Language_...
I have various snapshots of the Rotor 1 and 2 sources around and they have the SSCLI license. There is a file that contains BSD licensed code (pal\rotor_pal.h).
https://en.wikipedia.org/wiki/Shared_Source_Common_Language_...
I have various snapshots of the Rotor 1 and 2 sources around and they have the SSCLI license. There is a file that contains BSD licensed code (pal\rotor_pal.h).
Thank you for the follow up. You know after I posted that my thought was am I mistaking their BSD release for a BSD license, and of course I was. The memory isn’t what it used to be.
Was it originally BSD-licensed, or did it start out as the MS Public Source License or whatever it was called?
We could go back and check on Codeplex… oh wait.
We could go back and check on Codeplex… oh wait.
As a sibling poster updated it was some bastardized shared source license that never caught on.
Thank goodness MS got over their allergy to open source licenses, as they seem to prefer MIT nowadays for their releases.
My apologies for misremembering the details and being snarky. Humble pie eaten and enjoyed. :)
Thank goodness MS got over their allergy to open source licenses, as they seem to prefer MIT nowadays for their releases.
My apologies for misremembering the details and being snarky. Humble pie eaten and enjoyed. :)
No worries, and no humble pie required. Peace, good happiness.
Wow never knew that. So glad it didn't happen
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.
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.
Swift hasn’t required Xcode for several years now. It has robust command line tooling and a VSCode plugin.
https://www.swift.org/documentation/articles/getting-started...
https://www.swift.org/documentation/articles/getting-started...
Despite being terrible, the last time I checked, the experience in Xcode was somehow still meaningfully better than with the VSCode plugin
What don’t you like about the VSCode plugin?
For me it just spins forever and never manages to do any LSP things
If you haven’t tried recently I’d give it another go. A lot of work has gone in to the LSP this past year to stabilize it and improve performance.
Pretty similar to the Xcode experience, then
I find Xcode completion and especially doc lookup pretty good. It’s not as good as being able to jump straight into framework source code like with Android Studio but better than pretty much anything in VS Code in any language.
That is, as long as there’re no type errors in my code… once I get a little too creative in SwiftUI all bets are off.
That is, as long as there’re no type errors in my code… once I get a little too creative in SwiftUI all bets are off.
I believe it still does at least for iOS, or it did last time I checked (for a Swift library I was writing).
Building Swift code for iOS without going through xcodebuild is sort of obnoxious but is possible. You do need to have a copy of Xcode installed regardless of programming language simply because the iOS SDKs aren't distributed separately.
I feel like Swift is being held hostage by Apple. I can't get get the next version of Swift, because it's being distributed with a higher version of Xcode that only runs on an OS version I don't want to install (yet), and even if I did, I'd first have to buy a new Mac for that. That trick seems to work with enough developers to make Apple ever more rich and powerful and even more arrogant (if that's possible at all), but it doesn't work with me. As much as I appreciate Swift, I will only ever use it on my terms, not on Apple's.
This isn’t true, you can get the next version of Swift by downloading a pkg installer from https://www.swift.org/install/macos/
You can get it bundled with Xcode as well if you’d like, but it’s not necessary.
You can get it bundled with Xcode as well if you’d like, but it’s not necessary.
But you cannot run the product on an iDevice and a build for Mac Catalyst isn't even possible. “Bundled with Xcode” is very much necessary.
Swift isn't the one being held hostage, it's iOS development.
While i am sympathetic to you, you have to see that you represent a vanishing small use case for them.
Isn't that their complaint though? They don't want to participate in a language where they can only ever be a second class citizen.
> As much as I appreciate Swift, I will only ever use it on my terms, not on Apple's.
Apple's ethos for a long time have been "On our terms only", for almost everything they've built. Why would they treat Swift any differently?
Apple's ethos for a long time have been "On our terms only", for almost everything they've built. Why would they treat Swift any differently?
> I'd first have to buy a new Mac for that
Which means you are running Mojave and your Mac is at least 6 years old.
I wouldn't expect anyone to support developers who are running a two generation old OS.
Which means you are running Mojave and your Mac is at least 6 years old.
I wouldn't expect anyone to support developers who are running a two generation old OS.
I can run the latest version of my OS of choice on hardware twice that old.
This is only a problem that Apple has created to help them sell hardware. These days, a 6-year-old laptop is still a perfectly capable machine.
This is only a problem that Apple has created to help them sell hardware. These days, a 6-year-old laptop is still a perfectly capable machine.
And it is still a perfectly capable machine.
But you can't expect Apple to support it as a development platform. Especially when they want you to use the latest SDKs which only work on newer machines.
But you can't expect Apple to support it as a development platform. Especially when they want you to use the latest SDKs which only work on newer machines.
You're moving the goal posts. I'm not interested in SDKs that cannot work on a given OS or CPU, I just want to update the compiler to make use of progress in the language, without being forced by Apple to buy new hardware for that, or install a different OS. You pretending these things cannot be separated looks deeply disingenuous.
[deleted]
Using XCode is... unfortunate. Used it for only 10 minutes today and had a crash. Performance was very bad.
(Here's a bad one: I accidentally copied a whole file into the Find and Replace box. Instant Freeze and 1 frame per minute response.)
(Here's a bad one: I accidentally copied a whole file into the Find and Replace box. Instant Freeze and 1 frame per minute response.)
It’s Xcode.
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.
> 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 it really being released? Although some parts of the language and build chains are technically open source (as in, you can see the code), the project is still completely controlled by Apple at the top.
You are wrong about "some parts" - you can browse github.com/swiftlang to find out.
About control - serious question: how is this different from for example Rust, Go, Zig or Python? For each of those you can submit a change proposal through an official process and you can submit code changes through a pull request.
But also for each of those there is a non-zero chance that a smaller group of people who do governance of the project, the core team or leads or module owners, will either tell you that your proposal or code change is not appropriate or compatible with the project's goals or they will help you to merge it. That is exactly the same for Swift.
Why is Apple suddenly a dictator while every other project also has an agenda and strict rules that are being enforced?
Is the expectation to just be able to do whatever you want in a project like Swift?
About control - serious question: how is this different from for example Rust, Go, Zig or Python? For each of those you can submit a change proposal through an official process and you can submit code changes through a pull request.
But also for each of those there is a non-zero chance that a smaller group of people who do governance of the project, the core team or leads or module owners, will either tell you that your proposal or code change is not appropriate or compatible with the project's goals or they will help you to merge it. That is exactly the same for Swift.
Why is Apple suddenly a dictator while every other project also has an agenda and strict rules that are being enforced?
Is the expectation to just be able to do whatever you want in a project like Swift?
> how is this different from for example Rust, Go, Zig or Python
I believe op means Swift is different because Apple is the gatekeeper at the top of the Swift project https://www.swift.org/community/#project-lead
By contrast, other open languages usually have elected leadership and aren’t directly subject to a specific corporation.
I believe op means Swift is different because Apple is the gatekeeper at the top of the Swift project https://www.swift.org/community/#project-lead
By contrast, other open languages usually have elected leadership and aren’t directly subject to a specific corporation.
Go is pretty much controlled by Google
I don't follow it closely but there was a ton of drama around AWS influence on Rust through hiring key Rust devs.
Zig has BDFL
Python had BDFL
> About control - serious question: how is this different from for example Rust, Go, Zig or Python?
You can ask Chris Lattner about how many many changes were forced through the language before they were ready, or even properly designed, because Apple needed them: https://www.youtube.com/watch?v=ovYbgbrQ-v8
You can ask Chris Lattner about how many many changes were forced through the language before they were ready, or even properly designed, because Apple needed them: https://www.youtube.com/watch?v=ovYbgbrQ-v8
Basically, if companies who created language dump it on Github and let open source community take over it is nonviable. Because who will pay for project development that these mega corps dumped on community and washed their hands off.
On the other hand if companies take ownership, provide financing, design, vision, evolution of language, compiler, libraries and ecosystem etc it is nonviable because it is dictatorship now.
Solution is to let drive by commentators to have full commit rights on open source repositories if they want to change any part of language. Anything less unacceptable.
On the other hand if companies take ownership, provide financing, design, vision, evolution of language, compiler, libraries and ecosystem etc it is nonviable because it is dictatorship now.
Solution is to let drive by commentators to have full commit rights on open source repositories if they want to change any part of language. Anything less unacceptable.
You’re only focusing on access to source code, the comment is about leadership and decision making. Remember the OmniSharp story around VSCode from just two years ago? It’s a very high profile example of what can (and eventually will) happen with corporate-controlled projects.
Swift can’t evolve or even exist without Apple and so unless you’re Apple, then Swift is too great of a risk.
Swift can’t evolve or even exist without Apple and so unless you’re Apple, then Swift is too great of a risk.
> Swift can’t evolve or even exist without Apple and so unless you’re Apple, then Swift is too great of a risk.
I'm not sure what you're saying here. It's Apache licensed so you can just fork it. It's got pretty active development and a whole lot of software developers that use it-- if Apple decides to somehow lock down the repo and stop accepting PRs, what's stopping a group of developers from just making their own branch? It's got non-Apple cross-platform GUI frameworks, good support in editors... Sure it's 100% not as good off of Apple systems but I'm not sure what they'd be expected to do MORE than open it up with an Apache license?
And OmniSharp works just fine in VSCode from what I see. What am I missing?
I'm not sure what you're saying here. It's Apache licensed so you can just fork it. It's got pretty active development and a whole lot of software developers that use it-- if Apple decides to somehow lock down the repo and stop accepting PRs, what's stopping a group of developers from just making their own branch? It's got non-Apple cross-platform GUI frameworks, good support in editors... Sure it's 100% not as good off of Apple systems but I'm not sure what they'd be expected to do MORE than open it up with an Apache license?
And OmniSharp works just fine in VSCode from what I see. What am I missing?
They have also been working on a completely open source version of the Foundation library for use on Linux and other platforms. (IIRC the URLSession type is part of Foundation, as are many core building blocks that you need for making a real application.)
[deleted]
Can't you fork it then? Isn't that what open source is about?
Is Swift actually serious about embedded?
Of course! Tons of examples here:
https://github.com/apple/swift-embedded-examples
At WWDC24, we shared a session on embedded Swift, which is available on YouTube: https://www.youtube.com/watch?v=LqxbsADqDI4
More documentation on embedded Swift tooling here: https://github.com/swiftlang/swift/blob/main/docs/EmbeddedSw...
(Disclosure: I work at Apple.)
At WWDC24, we shared a session on embedded Swift, which is available on YouTube: https://www.youtube.com/watch?v=LqxbsADqDI4
More documentation on embedded Swift tooling here: https://github.com/swiftlang/swift/blob/main/docs/EmbeddedSw...
(Disclosure: I work at Apple.)
Wow! I’m really surprised by the ESP32 work here [1]. This looks super interesting! And, personally, unexpected.
This is the kind of thing that makes you want to quit your job and just tinker all day again.
[1] https://github.com/apple/swift-embedded-examples/blob/main/e...
This is the kind of thing that makes you want to quit your job and just tinker all day again.
[1] https://github.com/apple/swift-embedded-examples/blob/main/e...
Thanks for that link to the examples repo. I had just started looking into embedded Swift for an rp2350 project a couple days ago, but (being a novice in embedded hardware/microcontrollers) I got the impression from the Swift website that the device wasn't supported yet and I'd need an rp2040 instead. It looks like there's an example project for the rp2350 in that repo though, so I'm going to be playing with this tonight!
Swift is unbelievably cool but I wonder about using Swift for an embedded project as opposed to just C or with FreeRTOS for a more capable system. Is interoperability possible - as in FreeRTOS+swift?
For the most part, yes, it should be very achievable. Embedded Swift basically just produces an object file that looks like any object file from a C compiler. The objects mostly rely on very basic primitives like malloc/memcpy so it's pretty freestanding (you can turn off allocations, too). It also has very good support for importing C headers into Swift code so you can interop easily.
Probably the biggest roadbump for something like FreeRTOS is the asynchronous support though. Embedded Swift's async support is still extremely rudimentary and I didn't find much about how to extend it/attach it to other control loops. I think it only supports single-threaded execution right now as well.
Probably the biggest roadbump for something like FreeRTOS is the asynchronous support though. Embedded Swift's async support is still extremely rudimentary and I didn't find much about how to extend it/attach it to other control loops. I think it only supports single-threaded execution right now as well.
If you look at the blinking LED sample, it's pulling in the freertos header:
#include "freertos/FreeRTOS.h"
Why should it not, one of the design goals of Swift as C, Objective-C and C++ replacement was painless interop with those languages.
Thus it is more an issue of Swift embedded toolchain being able to be used alongside FreeRTOS on the specific hardware target.
Thus it is more an issue of Swift embedded toolchain being able to be used alongside FreeRTOS on the specific hardware target.
> Why should it not, one of the design goals of Swift as C, Objective-C and C++ replacement was painless interop with those languages.
This is actually a very good quality. I'm exploiting that for all it's worth in a job project where I'm gradually (file by file) converting a legacy codebase from Objective-C to Swift.
Providing an exit-strategy for Objective-C is good enough reason for me to at least have a basic working knowledge of the language.
This is actually a very good quality. I'm exploiting that for all it's worth in a job project where I'm gradually (file by file) converting a legacy codebase from Objective-C to Swift.
Providing an exit-strategy for Objective-C is good enough reason for me to at least have a basic working knowledge of the language.
Hi Tim. I liked your work with dart/flutter. Are you guys working on overhauling Xcode? The DX is atrocious.
Agreed.
It's not like they didn't have enough time to fix it either.
And they seem semi-capable of creating usable UI's elsewhere.
The thing is, when it comes to applications, both Apple and Microsoft compete with their own customers; which makes a pretty solid motivation for providing shitty developer experiences.
The thing is, when it comes to applications, both Apple and Microsoft compete with their own customers; which makes a pretty solid motivation for providing shitty developer experiences.
Did something happen with Xcode? I used it around 5 years ago, and it was pretty good and fast. I don't think it had dark mode but that's not too important to me.
No refactoring tools, lack of autocomplete, having multiple targets break compilation, errors in the ui, crashes running unit tests, it freaks out when switching git branches, spm can’t handle proxy servers, never ending indexing… List goes on and on. Xcode used to be good at around version 3. Everything that came after that has been disastrous.
Meanwhile Android Studio or VS Syudio are tools which are a joy to use and are built to help you and not to be constantly on your way
Fact is Apple should do like Google and admit there are better ides out there
Meanwhile Android Studio or VS Syudio are tools which are a joy to use and are built to help you and not to be constantly on your way
Fact is Apple should do like Google and admit there are better ides out there
> Xcode used to be good at around version 3.
I hate the other IDEs tbh
Yeah Xcode has its quirks but so does everything else. Nothing is perfect in this world.
What actually bothers me is Apple is now apparently trying to copy other IDEs (poorly) and making theirs worse for it. E.g. the new commit view which is an atrocity. They had something buggy yes, but at least decent. Now they have something buggy AND with a terrible UX.
Yeah Xcode has its quirks but so does everything else. Nothing is perfect in this world.
What actually bothers me is Apple is now apparently trying to copy other IDEs (poorly) and making theirs worse for it. E.g. the new commit view which is an atrocity. They had something buggy yes, but at least decent. Now they have something buggy AND with a terrible UX.
Xcode is fine as long as you skip Interface Builder and make a point to keep your SwiftUI views lightweight. For the latter my rule of thumb is to try to cap nesting in any given view at 3 levels and to break code out into new components for anything deeper, which is a good practice since readability starts declining steeply past 2-3 levels deep anyway.
It doesn’t have all the whizbang features of Jetbrains IDEs, but my experience is that those sorts of features only work correctly sometimes and can be as much of a hindrance as they are a help.
It doesn’t have all the whizbang features of Jetbrains IDEs, but my experience is that those sorts of features only work correctly sometimes and can be as much of a hindrance as they are a help.
Although opinions inside Apple about Swift vary, they seem to be investing in low level Swift for embedded, kernel use, and programming the “Secure Enclave” subsystem.
They certainly have many opportunities to use it for headphones, AirTag, flash driver, etc, beyond the very believable but less embedded use in kernel/Secure Enclave.
See also the wwdc session where they propose swift for building smart home thingies https://youtu.be/LqxbsADqDI4?si=KTYWPLdjGgTwK1UB
They certainly have many opportunities to use it for headphones, AirTag, flash driver, etc, beyond the very believable but less embedded use in kernel/Secure Enclave.
See also the wwdc session where they propose swift for building smart home thingies https://youtu.be/LqxbsADqDI4?si=KTYWPLdjGgTwK1UB
Yes, there was an entire WWDC ‘24 talk about it…
https://developer.apple.com/videos/play/wwdc2024/10197
Swift is a great language, but it is unfortunately still held back by the stigma of being perceived as only usable on Apple platforms.
https://developer.apple.com/videos/play/wwdc2024/10197
Swift is a great language, but it is unfortunately still held back by the stigma of being perceived as only usable on Apple platforms.
And until packages are actually shipped for all mainstream distros, the stigma is completely accurate.
No, neither "just install a tarball" nor "just install this docker image" count.
No, neither "just install a tarball" nor "just install this docker image" count.
Distro packaging for programming language ecosystems is so often hopelessly out of date. I’ve never used a distro toolchain or packages to build production software for any language Python’s age or younger.
Outside of C/C++/Fortran pretty much every project I see on Github prefers things like Rustup or Nix for toolchains to navigate around Debian/Ubuntu/RHEL’s “stability” approach.
Outside of C/C++/Fortran pretty much every project I see on Github prefers things like Rustup or Nix for toolchains to navigate around Debian/Ubuntu/RHEL’s “stability” approach.
I disagree vehemently. For any active language, distro packages should be at most 3 years old.
And for any language that's stable enough to be worth using, "3 years old" is good enough.
And for any language that's stable enough to be worth using, "3 years old" is good enough.
Python, Java, C#, JavaScript, Go, Ruby all improve so substantially in 3 years time, I can’t square the advantages of using a distro package for any of them versus using at least the latest LTS from upstream. What is so great about the distro package versus upstream, that it is worth being 2-3 years behind?
Mostly I hear “stability”, but I have encountered far more frustrations dealing with 3 year old software as a developer, than I ever have dealing with 6 month old software. If I have good test coverage, a way to deterministically reproduce my build environment, reliable CI, and a way to release packages and bugfixes to my users quickly, it seems the risk & blast radius of a 6 month old toolchain is quite limited.
Python is by some measures the most popular programming language, its first release was in 1991, and over the last 3 years performance improved significantly, see https://lost.co.nz/articles/sixteen-years-of-python-performa...
I imagine the only case I want an ancient toolchain is if I’m building libraries or software predominantly consumed by Debian stable or RHEL users / system package ecosystem, or I am doing some kind of high-assurance thing involving formal verification where I’m probably using a non-distro verified toolchain instead. I’ve never been too interested in either of those domains though.
Mostly I hear “stability”, but I have encountered far more frustrations dealing with 3 year old software as a developer, than I ever have dealing with 6 month old software. If I have good test coverage, a way to deterministically reproduce my build environment, reliable CI, and a way to release packages and bugfixes to my users quickly, it seems the risk & blast radius of a 6 month old toolchain is quite limited.
Python is by some measures the most popular programming language, its first release was in 1991, and over the last 3 years performance improved significantly, see https://lost.co.nz/articles/sixteen-years-of-python-performa...
I imagine the only case I want an ancient toolchain is if I’m building libraries or software predominantly consumed by Debian stable or RHEL users / system package ecosystem, or I am doing some kind of high-assurance thing involving formal verification where I’m probably using a non-distro verified toolchain instead. I’ve never been too interested in either of those domains though.
Both GCC and Clang have shipped support for major updates to C and C++ within the last 3 years. If C and C++ aren't stable enough, what is?
And is there any actual need to use those right now? No.
I lived through the C++11 transition (which was the only actually significant improvement C++ has ever had), and as much as GCC 4.6 was enticing, it really wasn't a burden to keep supporting GCC 4.4 in stable software. Only for ground-breaking development (which takes long enough to stabilize that stable distros will have the new GCC) is it worth starting to use the new features unconditionally.
Now, C++ does have a much better source-level compatibility story than most languages (e.g. `#if ... #define constexpr /* compiler too old */`), but that just means that newer languages have no excuse for refusing to learn from its successes.
I lived through the C++11 transition (which was the only actually significant improvement C++ has ever had), and as much as GCC 4.6 was enticing, it really wasn't a burden to keep supporting GCC 4.4 in stable software. Only for ground-breaking development (which takes long enough to stabilize that stable distros will have the new GCC) is it worth starting to use the new features unconditionally.
Now, C++ does have a much better source-level compatibility story than most languages (e.g. `#if ... #define constexpr /* compiler too old */`), but that just means that newer languages have no excuse for refusing to learn from its successes.
I just picked a random, notable feature (std::format) and the LTS my systems are currently on (22.04). The current Clang in universe is 14, which doesn't have a complete std::format implementation. That's one of the most popular features from a 5 year old language standard that many people are using today and yet it's still not available on a common LTS version without adding the LLVM repos.
Or containers. The Swift project is pretty good about keeping their Docker images up to date.
Working on it:
https://github.com/swiftlang/swiftly?tab=readme-ov-file
Bringing synopsis here for those who may not click:
swiftly is a CLI tool for installing, managing, and switching between Swift toolchains, written in Swift. swiftly itself is designed to be extremely easy to install and get running, and its command interface is intended to be flexible while also being simple to use. The overall experience is inspired by and meant to feel reminiscent of the Rust toolchain manager rustup.
swiftly is a CLI tool for installing, managing, and switching between Swift toolchains, written in Swift. swiftly itself is designed to be extremely easy to install and get running, and its command interface is intended to be flexible while also being simple to use. The overall experience is inspired by and meant to feel reminiscent of the Rust toolchain manager rustup.
I remember when all Linux projects used to be install a source tarball and do the configure, make config, make, make install dance.
That hasn't prevented Linux to take over most UNIX workloads.
That hasn't prevented Linux to take over most UNIX workloads.
Go has been shipping for more than a decade as a .tgz and does not have this stigma at all ...
Anyway, you probably missed the following
https://www.swift.org/install/linux/
I see packages for all major distros there.
But people will probably mention some distro not listed and say the mainstream distro support is a farce. For some reason people have set the bar for Swift incredibly unrealistically high and there will always be something wrong it.
Your loss though. Swift is amazing. Both on MacOS and Linux.
Anyway, you probably missed the following
https://www.swift.org/install/linux/
I see packages for all major distros there.
But people will probably mention some distro not listed and say the mainstream distro support is a farce. For some reason people have set the bar for Swift incredibly unrealistically high and there will always be something wrong it.
Your loss though. Swift is amazing. Both on MacOS and Linux.
If you actually click through, there is exactly one actual distro package there, and it is labeled "experimental". Everything else is exactly what I complained about - something that does not integrate into a real system.
That's not what I call "actually usable on non-Apple systems".
That's not what I call "actually usable on non-Apple systems".
Yes, one use case is to eventually replace the Safe C dialect Apple uses for iBoot firmware.
Apple probably has use cases for this and they’re bringing it into the open as a nice marketing thing. I wouldn’t count on long term support or compatibility beyond current priorities for Apple (same as their other SDKs for iOS, macOS etc).
Have a look at today's Swift track FOSDEM talks.
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.
The corporate language throughout that post is pretty cringe. It seems so unnecessary.
Doesn’t seem corporate at all:
Foundation: a first important step Chapter: the next stage of Swift technologies: it is a technology
Foundation: a first important step Chapter: the next stage of Swift technologies: it is a technology
It is so Apple, though. I can hear Craig's inflection just reading the sentence.
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
Recent discussion of Xcode, https://news.ycombinator.com/item?id=42803290
This article is completely wrong. I actually did what the author complained was impossible to do.
The article was wrong, but it motivated 100 comments about various issues with Xcode.
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?
> Does it improve something for non-Apple platforms?
Yes! This will improve the Swift and SwiftPM experience for _all_ platforms.
There are a number of goals outlined on our forums post https://forums.swift.org/t/evolving-swiftpm-builds-with-swif..., which goes into much more detail.
Yes! This will improve the Swift and SwiftPM experience for _all_ platforms.
There are a number of goals outlined on our forums post https://forums.swift.org/t/evolving-swiftpm-builds-with-swif..., which goes into much more detail.
[deleted](1)
It’s too late
i'd love to be able to build web servers in Swift. the language is such a joy to use
You already can.
Check out Vapor
Wasn't Vapor discontinued or do I have a false memory now?
It's still active. The last stable release was August/September last year.
I wish swift was built against normal LLVM instead of against Apple's fork of it.
[deleted]
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.
AccessorySetupKit is an Apple framework, not part of swift
Does the world need yet another build system? (not sure, just thinking out loud)
The idea is to end up with one fewer!
[deleted]
Can I cut and paste a Core Data Model that my LLM generated?
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.