Implementing parts of the Swift compiler in Swift(forums.swift.org)
forums.swift.org
Implementing parts of the Swift compiler in Swift
https://forums.swift.org/t/implementing-parts-of-the-swift-compiler-in-swift/59524
81 comments
> However, it would be a significant bump in requirements for using the compiler on macOS: currently, the compiler can run on macOS 10.9 or newer. This would move that requirement to macOS 10.15.
Is this even relevant? For using a newer Swift with Xcode I'm forced to upgrade the OS anyway. Xcode absolutely refuses to be installed on previous OSes. Can you sensibly develop in Swift with anything else besides Xcode?
Is this even relevant? For using a newer Swift with Xcode I'm forced to upgrade the OS anyway. Xcode absolutely refuses to be installed on previous OSes. Can you sensibly develop in Swift with anything else besides Xcode?
Yes, the swift toolchain includes a full set of command line apps. If you install swift on another platform like Linux for example, you won't have Xcode. You'll have the typical set of command line utilities you'd expect from compilers like gcc and llvm. You don't need Xcode, even for macOS and iOS dev.
Source: I do most of my swift development, including iOS and macOS dev, in a terminal. Editing with vim and using the swift command for the rest. You can even launch your iOS emulators and such from your command line while you're developing.
Source: I do most of my swift development, including iOS and macOS dev, in a terminal. Editing with vim and using the swift command for the rest. You can even launch your iOS emulators and such from your command line while you're developing.
> Can you sensibly develop in Swift with anything else besides Xcode?
JetBrains makes a fully-featured IDE for Objective-C and Swift. https://www.jetbrains.com/objc/
JetBrains makes a fully-featured IDE for Objective-C and Swift. https://www.jetbrains.com/objc/
It's a fine IDE, just like all their IDEs. But last time I used it for some Swift/SwiftUI, it still required to have Xcode installed.
Do you mean Swift? Or perhaps you mean iOS development since you mention SwiftUI?
We use AppCode (JetBrains) with server-side Swift and had to install XCode to get it to work.
I can't recall why it's necessary, but the first step in our developer onboarding README is "Install XCode, even though we don't use it"
FWIW our team has found JetBrains pretty fantastic for Swift. An important caveat of that being that we make a database product that runs on linux -- not a MacOS / iOS app that would benefit from all the special features of XCode. My guess is if that's your jam, XCode is the only high-productivity game in town.
I can't recall why it's necessary, but the first step in our developer onboarding README is "Install XCode, even though we don't use it"
FWIW our team has found JetBrains pretty fantastic for Swift. An important caveat of that being that we make a database product that runs on linux -- not a MacOS / iOS app that would benefit from all the special features of XCode. My guess is if that's your jam, XCode is the only high-productivity game in town.
It's probably the build-chain that comes with Xcode that requires the installation. You can probably do it yourself, but it'll be a bigger hassle.
SwiftUI works on macOS, too. [0]
[0] https://developer.apple.com/tutorials/swiftui/creating-a-mac...
[0] https://developer.apple.com/tutorials/swiftui/creating-a-mac...
SwiftUI, the frameworks, is not part of Swift, the language. You can happily use Swift without SwiftUI, or an Apple OS/hardware.
It's more a question of things like if you're building the Swift compiler in your CI system with macOS nodes less than 10.15, then you'll have to upgrade them. That can be problems if the build nodes you're building on are on hardware that doesn't support macOS 10.15. Now you have to buy a whole new Mac Mini or whatever just to continue building.
What about virtualization? https://github.com/kholia/OSX-KVM
Can you sensibly develop in Swift with anything else besides Xcode?
> Can you sensibly develop in Swift with anything else besides Xcode
kinda. I bring a throwaway laptop most everywhere which is enough to build swift packages and test using LSP-based IDE.
kinda. I bring a throwaway laptop most everywhere which is enough to build swift packages and test using LSP-based IDE.
If they’d get cross compilation working and a better story for Linux, I’d be VERY interested in building things with it.
Until then, it seems too impractical. I’m not sure who their dev audience is, but it’s surely not aimed at people like me.
Until then, it seems too impractical. I’m not sure who their dev audience is, but it’s surely not aimed at people like me.
They do now offer more than Ubuntu (and now with arm64 on Ubuntu too, I guess for rPi) https://www.swift.org/download/.
It is quite usable with SwiftPM or Bazel on Linux. And SwiftPM can also generate static binaries (packaged everything on Swift side up until Glibc).
VS Code extension support is passable.
It appeals to works between Rust and Python (i.e. application focused work that the default running speed is a plus not a requirement, also want to spend less time to think about object lifetime, more to think about the business logic).
It is quite usable with SwiftPM or Bazel on Linux. And SwiftPM can also generate static binaries (packaged everything on Swift side up until Glibc).
VS Code extension support is passable.
It appeals to works between Rust and Python (i.e. application focused work that the default running speed is a plus not a requirement, also want to spend less time to think about object lifetime, more to think about the business logic).
I'm surprised that they aren't making a bigger effort for Linux support.
Last time I tried swift on linux it wasn't even packaged by ubuntu.
If you `apt install swift` you get some object store tool.
If you `apt install swift` you get some object store tool.
As I understand, the primary issue packaging Swift for Linux is LLVM. Swift uses Apple's fork of LLVM and distributions want to compile against system LLVM and do not want two copies of LLVM slightly different.
This needs to be solved on Swift side. Rust had the same problem, and until it was fixed, Rust wasn't packaged by Linux distributions either. (I know this because I helped ensuring Rust's ability to compile against system LLVM.)
This needs to be solved on Swift side. Rust had the same problem, and until it was fixed, Rust wasn't packaged by Linux distributions either. (I know this because I helped ensuring Rust's ability to compile against system LLVM.)
Last I checked golang is not packaged either and that doesn't make it any less useful on Linux.
Swift works great on Linux. You can install it manually, or use the official docker image. I prefer using docker and have had a great experience (both developing and deploying).
Swift works great on Linux. You can install it manually, or use the official docker image. I prefer using docker and have had a great experience (both developing and deploying).
golang is packaged in Ubuntu since 18.04. Last time you checked must have been a long time ago.
https://packages.ubuntu.com/golang
https://packages.ubuntu.com/golang
Small thing, but I really wish we had URLSession async/await API on Linux Foundation already. I use Swift to write CLI apps and ArgumentParser is awesome with support for async/await, but when it comes to making network calls I always need to remember that's still missing.
You do have SwiftNIO (as far as making network calls) - but that leaves a lot to be desired from an out of the box usability perspective. Otherwise I totally agree, Foundation on Linux is missing some useful things.
True and thank you, it just feels a little overkill to bring in a separate package in my CLI apps just to make async network calls.
Why should they? That isn't their target audience.
Objective-C also has been available on Linux for about 25 years now, and it has hardly mattered.
Objective-C also has been available on Linux for about 25 years now, and it has hardly mattered.
> Why should they? That isn't their target audience.
Because they need it?
Apple discontinued macOS server, i bet they use Linux in some of their servers
All their networking related libs are available and tested for Linux [1, 2, 3]
Let's not forget that they package Swift for Linux, and now also for Windows [4]
Swift is a cross-platform language (you not wanting to understand it doesn't change this fact), it's not a macOS framework
[1] - https://github.com/apple/swift-nio
[2] - https://github.com/apple/swift-protobuf/blob/main/.github/wo...
[3] - https://github.com/apple/swift-distributed-actors/search?q=l...
[4] - https://forums.swift.org/t/announcing-swift-5-6-2-for-linux-...
Because they need it?
Apple discontinued macOS server, i bet they use Linux in some of their servers
All their networking related libs are available and tested for Linux [1, 2, 3]
Let's not forget that they package Swift for Linux, and now also for Windows [4]
Swift is a cross-platform language (you not wanting to understand it doesn't change this fact), it's not a macOS framework
[1] - https://github.com/apple/swift-nio
[2] - https://github.com/apple/swift-protobuf/blob/main/.github/wo...
[3] - https://github.com/apple/swift-distributed-actors/search?q=l...
[4] - https://forums.swift.org/t/announcing-swift-5-6-2-for-linux-...
That is charity to pay lip service to FOSS folks, just like the Darwin repos.
Most of the work on Linux and Windows isn't made by Apple employees.
Most of the work on Linux and Windows isn't made by Apple employees.
So you want a language fully owned by a company with 0 external contributors?
History tells us that it is not a good idea ;)
And your statement is not true at all, look at the commit history
History tells us that it is not a good idea ;)
And your statement is not true at all, look at the commit history
It has gone quite alright for Objective-C, .NET, and plenty of others.
Heck even C was fully owned by a company until UNIX V6 happened.
Heck even C was fully owned by a company until UNIX V6 happened.
objective-c is living its final years
.net would have been dead without the community driven mono effort
C "was", it would have been dead if it was still
Notice the pattern?
.net would have been dead without the community driven mono effort
C "was", it would have been dead if it was still
Notice the pattern?
Objective-C only matters thanks Apple ecosystem.
No one in the .NET world cared about mono, and if they hadn't be bought from Microsoft, they would already be doing something else, it isn't as if Xamarin and Unity were making them rich.
C only got adopted, because companies got into commercial UNIX workstations and it came with them, on the base install. Until Sun introduced the concept of UNIX user and developer editions, no one cared GCC existed.
Notice the pattern?
No one in the .NET world cared about mono, and if they hadn't be bought from Microsoft, they would already be doing something else, it isn't as if Xamarin and Unity were making them rich.
C only got adopted, because companies got into commercial UNIX workstations and it came with them, on the base install. Until Sun introduced the concept of UNIX user and developer editions, no one cared GCC existed.
Notice the pattern?
No. I don't see this pattern with Golang.
Did the community or external contributors implement generics into the language or did they wait for years for the core developers at Google to do it?
Was WASM support a community driven effort from design to implementation or was it the core developers that did all the work?
It appears that 99.99% of the work and proposals have been implemented by the core developer team at Google.
Did the community or external contributors implement generics into the language or did they wait for years for the core developers at Google to do it?
Was WASM support a community driven effort from design to implementation or was it the core developers that did all the work?
It appears that 99.99% of the work and proposals have been implemented by the core developer team at Google.
How’s this language doing? Any big projects on Swift in the last years?
We use Swift on the server at Steamship. Our Swift project is a federated database for NLP data (query, training, inference, embeddings — the whole bit)
I assume folks are familiar with the downsides of Swift on Linux so I’ll focus on what we like about it:
- Fantastic type system
- Good language extensibility (we use Swift to build ourselves a framework to develop Steamship more easily)
- Good LLVM extensibility
- Mostly performant
- Compiled
All in all, we're very happy with the choice. My biggest gripe is slow build & test times in GitHub actions.
If Swift developers are out there and wanting to dig into more systems-style development, I'm happy to chat.
I assume folks are familiar with the downsides of Swift on Linux so I’ll focus on what we like about it:
- Fantastic type system
- Good language extensibility (we use Swift to build ourselves a framework to develop Steamship more easily)
- Good LLVM extensibility
- Mostly performant
- Compiled
All in all, we're very happy with the choice. My biggest gripe is slow build & test times in GitHub actions.
If Swift developers are out there and wanting to dig into more systems-style development, I'm happy to chat.
> Mostly performant
I assume that means "efficient at runtime" - but by what metrics? CPU time? Memory usage? Power usage? Latency/responsiveness? Throughput?
What are you comparing it against?
> slow build & test times in GitHub actions
What is the cause of this? Is the generated code slow or just the compiler?
I assume that means "efficient at runtime" - but by what metrics? CPU time? Memory usage? Power usage? Latency/responsiveness? Throughput?
What are you comparing it against?
> slow build & test times in GitHub actions
What is the cause of this? Is the generated code slow or just the compiler?
> I assume that means "efficient at runtime" - but by what metrics? CPU time? Memory usage? Power usage? Latency/responsiveness? Throughput?
Not OP, but coming from Python, I find it is liberating to say: I need to write a for-loop for things, and it is OK, not going to be the most efficient thing, but it won't slow me down 1000x and become the major bottleneck. That has been said, Julia probably do the same thing.
Not OP, but coming from Python, I find it is liberating to say: I need to write a for-loop for things, and it is OK, not going to be the most efficient thing, but it won't slow me down 1000x and become the major bottleneck. That has been said, Julia probably do the same thing.
Assuming you have to do a lot of string processing (for NLP). Do you have any "shortcut" to do that in Swift? The API is thoughtful, but tedious to type, comparing to Python. It would be great if we have some semi-official "shortcut" libraries just for string processing (The recent RegEx literal is a welcome addition, but not enough).
That's a very gentle way to describe the agony of string processing in Swift :-).
We have written a few shortcut libraries ourselves, but we actually don't end up writing a great deal of string processing code in practice because most of our operations are expressed in a higher level query language that gets compiled down to lower-level operator implementations (which only get written once).
The vast majority of our code (maybe like a lot of systems?) ends up being more about the management of the broader data & processing environment that coordinates everything.
We have written a few shortcut libraries ourselves, but we actually don't end up writing a great deal of string processing code in practice because most of our operations are expressed in a higher level query language that gets compiled down to lower-level operator implementations (which only get written once).
The vast majority of our code (maybe like a lot of systems?) ends up being more about the management of the broader data & processing environment that coordinates everything.
This is a shameless plug, but I built Swift Cloud to help people build scalable backends in Swift: https://swift.cloud
Behind the scenes we compile Swift to WASM and deploy to Fastly's edge network, Compute@Edge. At my day job we are using this in production and serving thousands of requests per second on our Swift app. Overall it's a lot of fun to deploy Swift on server, but the developer UX still leaves a lot to be desired. Running and testing locally is still non-trivial.
Behind the scenes we compile Swift to WASM and deploy to Fastly's edge network, Compute@Edge. At my day job we are using this in production and serving thousands of requests per second on our Swift app. Overall it's a lot of fun to deploy Swift on server, but the developer UX still leaves a lot to be desired. Running and testing locally is still non-trivial.
This looks great, good work!
One tangential question: do you worry about using "Swift", which I assume is an Apple trademark, in the name of your product?
One tangential question: do you worry about using "Swift", which I assume is an Apple trademark, in the name of your product?
Thanks so much.
And short answer - Yes.
My guess is it's a matter of 'when' I have to deal with this. I've had the domain for a while, and this is something I've wanted to build for such a long time. Things fell into place when I was able to build a Swift SDK for Fastly's platform back in January this year. The stubborn engineer in me went ahead and used the domain anyway and launched what you see today.
And short answer - Yes.
My guess is it's a matter of 'when' I have to deal with this. I've had the domain for a while, and this is something I've wanted to build for such a long time. Things fell into place when I was able to build a Swift SDK for Fastly's platform back in January this year. The stubborn engineer in me went ahead and used the domain anyway and launched what you see today.
Gotcha, thanks for your answer :)
I already created an account! I’m definitely going to use this the next time I need a little cloud function
Love to hear that! Always feel free to reach out if you have any questions or run into issues.
I have no use for this project, but this seems super cool!
Still macOS language, a lot of cool features but not enough community on linux and for sure windows :/
SwiftUI and Metal look like big projects.
95% of the underlying metal driver is written in cpp.
Of course it is C++, that is what IO and Driver Kits use.
App developers use the Objective-C and Swift userspace libraries.
The newly released header only library for Metal in C++, is a poor man's binding, that wraps the C API of the Objective-C runtime, without the Metal frameworks written in a mix of Swift and Objective-C.
App developers use the Objective-C and Swift userspace libraries.
The newly released header only library for Metal in C++, is a poor man's binding, that wraps the C API of the Objective-C runtime, without the Metal frameworks written in a mix of Swift and Objective-C.
Metal shading language is C++14
The company I work for uses Swift a lot... that said, the performance sensitive parts of the code is still Cpp.
Swift is nifty but still not Cpp I guess.
Swift is nifty but still not Cpp I guess.
Is the company you work for mostly targeting Apple devices?
I'd be interested to hear if there is any large scale Swift usage outside of the Apple ecosystem.
If you are targeting Apple devices, was your performance sensitive code always written in Cpp or did you leave Objective-C for Swift+Cpp? Or, were the Cpp parts inherited and just wrapped with whatever your platform's encouraged language was?
(I used to do contract iOS work but I stopped around the time Swift came out due to taking a rewarding full-time job, so I never really spent much time on Swift beyond "huh, neat")
I'd be interested to hear if there is any large scale Swift usage outside of the Apple ecosystem.
If you are targeting Apple devices, was your performance sensitive code always written in Cpp or did you leave Objective-C for Swift+Cpp? Or, were the Cpp parts inherited and just wrapped with whatever your platform's encouraged language was?
(I used to do contract iOS work but I stopped around the time Swift came out due to taking a rewarding full-time job, so I never really spent much time on Swift beyond "huh, neat")
How does it compare performance wise to cpp in real-life.
AFAIK most people have been moving away from it in favor of Rust and Zig.
A lot of friends at FAANGs are still working in ObjC codebases, and probably gonna skip the whole Swift story by jumping straight to Rust when the time comes.
But of course this could be just in my bubble...
A lot of friends at FAANGs are still working in ObjC codebases, and probably gonna skip the whole Swift story by jumping straight to Rust when the time comes.
But of course this could be just in my bubble...
Rust is taking over the tools space for sure, replacing important tools that need to run often and speed is king, replacing tools written in python and perl. Rust is also making its way into new core cross-platform libraries that need speed, instead of C++, however, no one is going to rewrite C++ libraries.
No UI or product team is going to use Rust over Swift (or Kotlin) or whatever your stack currently depends on.
No UI or product team is going to use Rust over Swift (or Kotlin) or whatever your stack currently depends on.
If you mean anything other than iOS apps, sure. But for this latter case, there’s no real alternative. An iOS app in Zig or Rust is in an extremely small niche.
Would be interesting to know the "moving away from Swift to Rust / Zig" story. My impression is that Swift not even in consideration in most projects with Rust / Zig.
I can see some performance-sensitive projects being done in Swift, Rust, or Golang.
Funny, the place I don't like using Swift is its main use case, high-level iPhone apps. It's overkill. The complex Stackoverflow answers for "how to do (simple thing like getting a substring) in Swift" say so.
Funny, the place I don't like using Swift is its main use case, high-level iPhone apps. It's overkill. The complex Stackoverflow answers for "how to do (simple thing like getting a substring) in Swift" say so.
It is sad that this language is almost useless for anything else than osx/ios apps.
https://vapor.codes/ brings Swift to the server and it's quite good! Wrap that in docker and you can be running Swift anywhere pretty quickly.
And with async/await, server side Swift is really nice now. The old stuff with eventloops and SwiftNIO was painful.
Now it feels almost like writing Python, only with a real type system and not slow.
Now it feels almost like writing Python, only with a real type system and not slow.
I stopped using Swift before version 5, and async/await was always something I missed there and a big reason I liked Javascript. I can't believe how much developer time was wasted on promises and callbacks in so many languages. Good that Swift has async/await now.
Is it, really? I mean, it's Turing-complete, nice to use, quite fast... I don't see a reason not to reach for Swift if I want to do some reasonably generic data crunching (instead of say, Java, C++, Crystal or similar languages).
Finally, a Turing-complete language!
I used swift till 2.x, and it’s really sad that Apple missed the opportunity and didn’t wanted to promote swift outside their ecosystem, if they did that, for sure swift will be up there competing with nodejs, rails, go, rust, etc in the backend space, it was really new refreshing language.
Because I stopped using it, I don’t know how much the language changed and how it compares with go/rust in terms of performance, I would bet that it is bear go performance at least, knowing Apple seems to care about it.
Because I stopped using it, I don’t know how much the language changed and how it compares with go/rust in terms of performance, I would bet that it is bear go performance at least, knowing Apple seems to care about it.
Many developers are more than happy living in a pure Apple ecosystem, it is a big enough crowd.
Can it get even slower?
Be patient... We've seen how O(2^n) algorithms can be utilized in the Swift compiler, but it's still a long way to the Ackermann function... I have faith in them!
Or at least make sure new versions can be built with the previous (Rust-style), and not require downloading new binaries for every release (looking at you, Mono).
See Ken Thompsons now-infamous "reflections on trusting trust" and https://bootstrappable.org for why this is important.
(I may come off a bit grumpy from recently trying to port old versions of JDK and GHC to a newer toolchain; yet consider myself lucky to have the privilege).