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
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 ./mainBut 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...
You 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.)
> 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?
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.
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.