Apple is open sourcing Swift Build(swift.org) |
Apple is open sourcing Swift Build(swift.org) |
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.
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.
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.
That would actually help the language get traction. At this point it's a dying language.
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.
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.
They painted themselves in a corner. Apple being the best computing platform while trying to please everyone can never be a serious proposition. Either they are the best and everyone uses macOS, or we have to be so careful that any alternative is more interesting that what they propose.
This 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.
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.)
"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.
Kotlin depends on the JVM and is also not compiled.
Rust? Now you're talking. Except that it has warts, too.
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.
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.
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#.
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.
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.
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.
See C#/.Net Core. It runs on Linux for so many years. But people still treat it as "Microsoft's thing".
uh, wasn't .NET open-sourced under exactly the same pro/con, except towards Windows hegemony?
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.
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
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.
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.
Plenty of people make an incredible amount of money building apps in Swift, so your last sentence is just wrong.
Cocoapods is too old and bad for modern era package management. It’s not made for swift also.
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.
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.
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.
Do you have a source for the GNOME C# claim? I can't find one.
And Miguel started Mono way before Microsoft made C# cross-platform. At that point they were antagonists.
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.
https://www.swift.org/documentation/articles/getting-started...
> 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.
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?
The corporate language throughout that post is pretty cringe. It seems so unnecessary.
Foundation: a first important step Chapter: the next stage of Swift technologies: it is a technology
Recent discussion of Xcode, https://news.ycombinator.com/item?id=42803290
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.
Maybe the friendly default would be to have the symbolicated reports on, but perhaps this has performance impact so it’s off.
``` 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│>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):
?
Not sure how that's any better... I still have no idea that the error occurred on line 2
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 ./mainYou can get it bundled with Xcode as well if you’d like, but it’s not necessary.
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?
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.
(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.)
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.)
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...
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
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.
No, neither "just install a tarball" nor "just install this docker image" count.
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.
Updates tied to OS and crashes more than it should.
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.
<Open source contributor> “let’s see who you really are”. <pulls off mask>. Apple employee.
There’s obviously a snarky comment to make here about Go developers and duplicating efforts.
Cocoapods has been end of life’d
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.
#include "freertos/FreeRTOS.h"
Thus it is more an issue of Swift embedded toolchain being able to be used alongside FreeRTOS on the specific hardware target.
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.
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.
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.
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.).
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.
And one of my biggest gripes is the way you can extend things from anywhere else, easy to cause a mess.
But it is a shame, because many of the ideas are good imho.
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.
Lets play this game?
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.
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.
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.
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.
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.
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.
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.
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
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.
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?
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.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).
We could go back and check on Codeplex… oh wait.
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
This doesn't provide anything useful either.
> zsh: illegal hardware instruction LLVM_SYMBOLIZER_PATH=/usr/local/opt/llvm/bin/llvm-symbolizer swift main.swift
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.
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).
Kotlin’s syntax is also weird/quirky in some ways.
I'm curious to learn what you mean by this! :)
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.
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.
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.
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.
> 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.
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.
Hm, I've been using macOS (alongside others) for the past 20 years straight. In what ways is it hostile and buggy?
zsh: illegal hardware instruction swift main.swiftI disagree.
Source: Someone who has been programming Apple since 1986, and has heard last rites being administered to Apple, many times.
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.
Impossible to argue otherwise.
Some are already adopting it like Ladybird browser.
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.
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. :)
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.
And for any language that's stable enough to be worth using, "3 years old" is good enough.
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.
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.
That hasn't prevented Linux to take over most UNIX workloads.
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.
That's not what I call "actually usable on non-Apple systems".
Typically not a great idea to be against humans, especially the ones that give you money.
Last time I checked, their market cap was North of $3T, so someone is giving them money…
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 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.
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.
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.
Apple forcing an API is not enough to sustain a language's popularity.
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.