Comment by hollowturtle
4 hours ago
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
One of the biggest issues I ran into years ago was debugging outside of macOS was a nightmare. Even now, debugging is a terrible experience on a non-trivial project. I am not really sure if it the size of the projects I've worked on, interop with objc, compiler configs, project configs, or what, but it has always been a bad experience. I used it on/off for a project on Linux and the debugger didn't work at all. This was so long ago I am sure that has changed but at least so far in my experience, lldb will stop working at some point. I've worked on large Obj-C and C++ codebases and never ran into any of the problems I've run into with swift in this area.
Apple really needs to decouple swift debug and profiling tools from Xcode. I've been using vscode for swift work but hate having to switch back to Xcode for the tools.
Here's what I wrote on this subject back in September. Nothing has changed so far as I can see.
https://news.ycombinator.com/item?id=45417366
I tried using it on Windows, but it failed to compile as soon as I used file IO. The error was non-descriptive and had no matches online. I couldn't figure it out so I tried it without file IO, but as others have said the compiler is odd, the errors are odd, and in general doesn't feel like the tooling is nearly as good as most other popular languages
Not quite systems programming but this might give you some insight. Swift is memory efficient, and runs stable backend services. I've seen benchmarks showing that it's slightly more performant than typescript but twice as memory efficient (but not as efficient when it comes to memory management compared to Rust, C, and C++).
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.
>The other point I've seen is that its string library is slow and very accurate.
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.
> Swift strings default to operating on grapheme clusters, which is relatively slow.
The unicode-segmentation crate implements this for Rust, in case it matters for accuracy.
Unicode scalars are not so fast. But yes working directly with UInt8/Data bytes is efficient.
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.
Being only slightly more performant than an interpreted GC-only language is hard to believe (even though typescript is just a spec and you probably meant slightly more performant than v8).
That's right, I said TypeScript but yeah, it's v8 under the hood.
For web server benchmarks, it’s far behind typescript. Async has further degraded performance competitiveness
It also has C++ interop btw
It's lovely, not “always has been” but since, say, 5.10.
// 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.
Swift is pretty good.
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.
> It feels very much like a cousin to Rust with a few tradeoffs to be more ergonomic.
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.
I disagree that rust can be as ergonomic. I’ve been writing rust for longer than Swift , and there’s a lot of niceties in Swift.
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.
3 replies →
Swift "feels" like C#. A lot of systems programming is done in C#.
Depending on your goals, it's worth giving C# a test-drive given Swift's similarity to C#.
Traditionally I would say it feels more like Ada, Modula-2, Object Pascal.
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.
> Traditionally I would say it feels more like Ada, Modula-2, Object Pascal.
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.
1 reply →
Could be better, think .NET Core 1.1 timeframe when Microsoft finally decided to make it cross-platform.
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.
Quite enjoyable. Some compiler errors are a pain.
What an understatement :)
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.