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.
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.
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?
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.
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.
One tangential question: do you worry about using "Swift", which I assume is an Apple trademark, in the name of your product?
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.
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.
Swift is nifty but still not Cpp I guess.
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")
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...
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.
No UI or product team is going to use Rust over Swift (or Kotlin) or whatever your stack currently depends on.