To anybody with experience, how's Swift? Especially outside MacOS/iOS programming. Let's say I want to use it standalone for doing some systems programming, how's the standard lib? I'd like to not rely on apple specific frameworks like uikit
As a language, I really like it. It feels very much like a cousin to Rust with a few tradeoffs to be more ergonomic.
The standard library is pretty good but the extended ecosystem is not as strong outside of Apple platforms, though that is improving.
If the ecosystem improved, like this project here, it would probably be my go to language. Failing that it’s usually rust , Python, C# and C++ for me.
UI libraries outside of Apple frameworks is about as weak as all those other languages if you don’t have Qt bindings. Qt does have Swift bindings officially in the works though so that could change.
Rust can be just as ergonomic. It takes some minor boilerplate of course, since you're resorting to coding patterns that are somewhat unidiomatic - but not nearly as much as the likes of C# or Java.
Default parameters, null shortcircuits, lazy static initializers, computed properties, ease of binding to C++, RC by default, defer.
Both languages are great, but I don’t think they’re on the same ergonomic level by any means.
I wouldn't really call this an "ergonomic" feature of a language. That's a whole research project.
Regardless, C++ interop in Swift isn't straightforward and there are a multitude of issues. One being that you need to compile your C++ codebase with Apples fork of LLVM and in some cases add annotations in your C++ so that Swift plays nice (which basically isn't interop at that point)
You can see the Ladybird projects issue tracker[0] and issues on the Swift forum that LB maintainers have created[1][2] to get an idea. Swift adoption has stalled due to these.
0: https://github.com/LadybirdBrowser/ladybird/issues/933
1: https://forums.swift.org/t/ladybird-browser-and-swift-garbag...
2: https://forums.swift.org/t/ladybird-gc-and-imported-class-hi...
I’m not sure why annotations are a bad thing to you. They’re not necessarily swift specific and could benefit other bindings too, and their existence doesn’t mitigate that it’s a binding. Or do you not consider rust being bindable to any non-C language since you’d have to write CFFI bindings in between?
You get the bare bones standard library, some of it still WIP, and naturally most libraries were written expecting an Apple platform.
Windows workgroup was announced yesterday, and Linux support is mostly for macOS/iOS devs deploying some server code, because naturally OS X Server is no more.
The other point I've seen is that its string library is slow and very accurate.
Besides that, the C-interop means you have quite a bit of flexibility in leveraging existing libraries.
Swift strings default to operating on grapheme clusters, which is relatively slow. But you can always choose to work with the underlying UTF-8 representation or with unicode scalars, which is fast.
The only situation where UTF-8 incurs overhead is if the String comes from some old Objective-C API that gives you a UTF-16 encoded String.
That’s how I took over maintenance of SwiftSoup and made it over 10x faster according to my benchmarks. Besides various other optimizations such as reducing copying, adding indexes, etc.
The unicode-segmentation crate implements this for Rust, in case it matters for accuracy.
It also has C++ interop btw
Depending on your goals, it's worth giving C# a test-drive given Swift's similarity to C#.
And if making reference counting part of the picture, Cedar, Modula-2+,...
Finally catching up with what we already had in the 1990's and lost, in a couple of decades split between C, C++ and VM based languages.
Well, that's from the Objective C history; and Objective C borrows a lot from those languages.
The thing is, once you're doing systems programming, it's unlikely you're going to call any Objective C APIs, or APIs that have an Objective C history. You're more likely to call something in C.
Also Objective-C has nothing to do with those languages, so I got lost in what history.
It picks from C and Smalltalk.
// I'm an originally Pascal and assembly dev (learned most Internet dev langs along the way) who hated what people did with Java (until last 5 years), failed to like Ruby, liked Clojure, disliked go, did like Nim, but really found Swift to be fresh air for data shapes and flow. And the tooling experience with git repo to iCloud build to testflight is worth every penny of the annual dev fee.
It’s a lovely language but the compiler has got to be the most unreliable I’ve ever seen.
It crashes semi-frequently. And it will sometimes try to run analyses that are way beyond O(n). So you can have perfectly valid code that it can’t compile, until you simplify or reduce the size of some function.