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

▲

tarentel 44 minutes ago | parent | next [-]

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.

▲

akaltar 36 minutes ago | parent | prev | next [-]

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

▲

ppeetteerr an hour ago | parent | prev | next [-]

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.

▲

fauigerzigerk an hour ago | parent | next [-]

>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.

	▲	zozbot234 36 minutes ago \| parent \| next [-]
		> 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.
	▲	wahnfrieden an hour ago \| parent \| prev [-]
		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.

▲

ComputerGuru an hour ago | parent | prev | next [-]

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).

	▲	ppeetteerr 41 minutes ago \| parent [-]
		That's right, I said TypeScript but yeah, it's v8 under the hood.

▲

wahnfrieden an hour ago | parent | prev [-]

For web server benchmarks, it’s far behind typescript. Async has further degraded performance competitiveness

It also has C++ interop btw

▲

Terretta 2 hours ago | parent | prev | next [-]

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.

▲

dagmx an hour ago | parent | prev | next [-]

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.

▲

zozbot234 39 minutes ago | parent [-]

> 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.

▲

dagmx 26 minutes ago | parent [-]

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.

	▲	hypeatei 5 minutes ago \| parent [-]
		> ease of binding to C++ 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...

▲

gwbas1c an hour ago | parent | prev | next [-]

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#.

	▲	pjmlp an hour ago \| parent [-]
		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.

▲

pjmlp an hour ago | parent | prev | next [-]

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.

▲

keyle an hour ago | parent | prev [-]

Quite enjoyable. Some compiler errors are a pain.

	▲	cvwright an hour ago \| parent [-]
		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.