Hacker News Reader

>Swift also took a bunch of goodies from Rust - No garbage collector - Traits via "protocol"

I'd say they took them from Apple's own Objective-C additions who had those for decades before Rust (ARC and protocols).

This is correct.

Yeah, Objective-C Protocols are so old that they influenced Interfaces in Java 1.0.

As another huge rust fan myself, Swift 6 has really won me over.

I find myself reaching for Swift as the default for a lot of things rather than Rust, especially with the advent of C++ Interoperability and the new Swift embedded stack and ownership model.

The only thing I really need is a UI story on other platforms, but it’s an area Rust is lacking great solutions too. I suspect the C++ interop might eventually make Swift have great Qt bindings to compete with PySide as an accessible way to make multi platform UIs.

There’s a very minimal example using C++ interop in Qt’s test suite:

https://github.com/qt/qtdeclarative/tree/dev/tests/manual/he...

I’ve kicked around with the C++ interop a few times. Projects like Qt that use raw pointers extensively seem hard to expose. Ended up having to wrap Qt classes to model as a value type which was straight forward but it’s not nearly as seamless as the Objective-C++ experience

Ah, very cool. Thanks for the link and write up

Agreed that Swift looks quite amazing. There’s some cool talks on how they’re trying to move FoundationDB to Swift and their approach.

I think the main problem, and this is a really big problem, is that based on a very shallow investigation I did a couple months back, the ecosystem for server-side stuff barely exists.

And in my opinion, the ecosystem is one of the deciding factors when picking a language.

I have a slight inkling that Apple internally is using Swift for backend stuff somewhere, especially with all the ML stuff they just shipped. Word on the street is their datacenters are full of M-series chips. I could see those servers running Swift + distributed actors + mlx.

The move to make swift run on Linux could be part of that work - their sysadmins, devops, and backend folks probably use Vim/VSCode and deploy on Linux.

We might see the release of a very good backend framework by apple for Swift that works on Mac/Linux.

The new macros they added kinda bolt on serde into the language too - and the distributed actor stuff is basically RPC in the language.

Yes their “private cloud” runs on Swift, which supposedly increases security because they believe Swift has things nailed by now.

I believe it’s confirmed that they’re doing it with Swift, buried somewhere in the ML post IIRC.

Apple deploys a ton of their server stuff on Linux. Plus they appear to be doing all new code in Swift and moving old code over slowly.

They’re also using embedded Swift in the Secure Enclaves and other small processors due to its safety, though I think they have an extra layer of automated security checking that they use internally that doesn’t exist in the public builds.

But in short, yes. I believe they’re trying to use Swift for everything at this point and getting away from C/C++/whatever even for kernel work.

Most server code Apple writes is Java. They are slowly trying out Swift, but it's not really correct to say that all new code is Swift.

Swift and Go are on polar ends of the language complexity spectrum. Someone who enjoys Go for what it is, i.e. a dead simple, straightforward language, would not see Swift as being "better".

Some people want generics and ADTs in Go. If you're using go because it's

1) fast

2) expressive

3) concurrent

4) compiles natively

then I think Swift is the better of the two.

If you just want a very simple language, then sure, Go is there. But I don't think that's necessarily what makes Go, Go.

after using swift extensively i did not find it better of the two, in fact it is a complex keyword ridden language that seems bolted together at very many angles, each swift codebase i enter is like a new mystery to unfold because of its extremely rocky evolution

One thing that bugs me to this day is reading Swift code without an IDE can be an exercise in “let me build up a mountain of context first”, due to the way enums and types can get shortened.

It’s nice to write but a pain to review. Meanwhile if I read Rust or Go, it’s more or less what you see is what you get.

I do agree in general that it’s frustrating that Rust hasn’t kept up with some of Swift’s pushes, but then again that’s the difference when you have the richest company in the world involved.

For context, I’ve written many apps in Swift, deployed a backend in Vapor, and worked with teams who use the language. I always thought I’d get over it but it just never fully clicked.

Yes! Reading Swift code, even tutorial code, can be difficult.

I would say that yes, in fact, simplicity is characteristic of Go. That is clear from how the go team considers the impact of every new language feature, often choosing not to do things that would've been considered obvious in other languages. Many parts of the community still resent generics, and there is widespread backlash to the new iterators proposal. Most Go enthusiasts wouldn't be fans of Swift and vice versa.

Swift has its strengths against Go but it does not really beat Go at Go's own game.

Where are channels and select? Why is async code special? Why do protocols have to be explicitly adopted? Why are errors "thrown" instead of returned?

The async question is actually really interesting - and gets at a few things Swift does very differently from some other languages.

Normal languages just sort of call functions on threads - and use locks when there is contention. You certainly can write the same sort of code in Swift - but that is not how async functions work.

The issue with locks is that waiting on a lock could be expensive - depending on the type of lock. And it also ties up the thread. If you have a thread pool you could end up with a lot of threads getting tied up in locks.

Async functions are suspendible. When they encounter a data hazard - the thread is released and allowed to go work on something else. When the conflict clears the function is picked back up and execution continues. Note: the way this is designed means that a _different_ thread may continue execution of the async function, and async functions should assume that they may change threads during execution. But this does prevent stalled threads just waiting on some condition. The compiler needs to extra notation to know your function has been designed around this sort of operation.

Basically: Async functions are not normal functions - they're allowed to be suspendible and may change threads mid execution - hence the extra notation. This improves both performance and safety.

But that's the thing, we're comparing with Go, where all functions behave that way, and no async/await ceremony is required. Go has many weaknesses, but I don't think a language that treats async as unusual/special beats Go in that respect.

This is just a hunch but likely because of the application the two languages were originally designed for. Go is/was a purely backend lang (as I understand it) whereas Swift was built with the UI in mind which must be run on the main thread. So Swift has async/await for making clear boundaries between synchronous (aka UI) operations and asynchronous operations.

I’m am not well educated on the subject though so take that with a grain of salt.

This is a good point. It's possible to use Go this way too, but it gets tricky. You can lock the main goroutine to its O/S thread with runtime.LockOSThread and then do the heavy lifting on other goroutines, sending messages back to the main goroutine typically using channels. Given Swift's lineage, this is probably more ergonomic there than in Go.

This melding of the sync and the async is actually kinda interesting to me. I know that at least in lots of environments, the sync and async paths are effectively separate for things like I/O[1]. I wondered (and still do for some cases) how Go handles this.

For those curious I looked at Windows and Linux, but not much else.

Linux: no io_uring support. There's debate on even whether to use it as people are discussing security implications[2]. It looks like (from perusing this issue, but could be wrong) AIO wasn't used.

Windows: it looks like they're using IOCP everywhere. Seems sensible enough.

General case: there seems to be an open issue regarding this[3].

[1]: For example, Windows has IOCPs, Linux has io_uring, FreeBSD has kqueue, POSIX has... POSIX AIO, etc.

[2]: https://github.com/golang/go/issues/31908

[3]: https://github.com/golang/go/issues/6817

Interesting. My understanding of how things get implemented is that all code runs essentially "async" by default, but the runtime scheduler can switch to running code synchronously when requested (runtime.LockOSThread) or necessary (e.g. "slow" calls to C via cgo).

I was not aware that file I/O isn't async on Linux. Even so, I'm pretty sure network I/O and channel operations (send/receive/select) are async via epoll. I'm not as sure about these, but I think time.Sleep and sync.Mutex.Lock suspend the goroutine as well.

I think it depends on the person. My anecdotal experience is that I'm using Go for hobby projects because with Python at my day job, I wanted a modern language with fancy-ish static typing. Additionally, I wanted it to be equally practical on Win/Mac/Linux, and to not run inside a VM.

The obvious first candidate was Rust, but the low-level features were unnecessary overhead. A "higher-level Rust" is literally Swift, but the portability is not there. The search basically ended here, so I went with Go as a consolation prize - I don't get a fancy type system to play with, but the development ergonomics, especially with the v2 modules system, are the best I've experienced yet.

Have you checked out the static linking option announced yesterday? Portability has increased a lot.

I have, and I am indeed very hopeful about the WWDC 2024-related Swift announcements. My comment was meant to illustrate my thinking circa a year or two ago.

How’s the compilation speed?If it’s going to replace Go, that’s gotta be sub second for a medium sized project on my clunky old laptop.

Why, would you care if it's a full second or even 5 seconds?

Go hyped their compilation speed a lot in its early years, but unless it's C++ templates level slugginess it's not like it's that big of deal.

Compiling fast has ripple effects throughout your workflow. Having your iteration time go from 1s to 5s is a massive difference: it can mean you break out of the flow state when you restart your server to test your code.

As someone dealing with Swift everyday (and, before that, faster langs like Elixir and Typescript), I can only agree. Sometimes my incremental builds take 20-30 seconds and it feels like a huge toll. Waiting on the CI (which is a weak machine) is up to 25 minutes until the test suite has passed - a large chunk of that being compilation time. Releases take 5-10 minutes.

I really like Swift, but I’d highly appreciate faster compilation times.

Once you use a language where compile times are essentially invisible, it’s hard to go back.

Swift compilation is slower than C++.

C++ with heavy template use or C++ as glorified C-with-classes?

C++ with heavy template use.

Supposedly faster in Swift 6 but I don't have any big swift projects to throw at it. It uses LLVM so it's not going to be as fast as Go's.

In Swift 6 they:

- Improved parallelism via compilation pipelining (ie top-level object files are referencing not-yet-compiled symbols but can still proceed while those compile in the background)

- Parallelized and pipelined debug symbol generation (lazy debug symbols)

Assuming my experience with Swift 5 is still accurate, compilation speed is at least an order of magnitude slower than Go.

It’s a much more powerful language. In my opinion slower compilation is worth it for all of its great features. (Does Go even have parametric enums?). But its definitely a trade off.

That’s the one big loss from moving off Objective-C. Because the language was so stupidly simple to parse and didn’t have a lot of “we’ll figure that out for you from what you wrote” it could be compiled incredibly quick on today’s machines.

I know they’re working on improving it. I’m glad they are. But that speed is something I definitely miss.

Ocaml makes me wonder if we really do need the trade off. It’s a fairly advanced language, and compiles super fast. I wonder why it’s such an outlier among advanced languages?

> IMO Swift 6 is a better Go and than Go, and a better Rust for app-dev type stuff, which seems to be what people want to use Rust for.

This is a great assessment. There are some shortcomings in go that I wish weren't and I'm kind surprised that people having decades of language design experience under their belt ended up designing go.

I'm looking for a way to generate server stubs from OpenAPI specs. If that, I'm all set with Vapor+OpenAPI and would retire go for my container adventures.

I'm looking for a way to generate server stubs from OpenAPI specs

I don't have experience with OpenAPI, but is this what you're looking for? https://www.swift.org/blog/introducing-swift-openapi-generat...

You're right. This actually is first class Apple[0] and can't get any better than that whereas with Go, I am stuck with so many third party packages. They work well but kinda... not so elegant. Decent enough given what the language can offer.

[0] https://github.com/apple/swift-openapi-generator

You almost caught up to Dart.

- Built for embedded devices and already has RISC-V support

- Already has WASM was a compilation target

- Not just an LSP but amazing VSCode tooling

- Native C, C++, Java, Rust and JavaScript interop and a .NET bridge is in the works it seems.

- Typed "throws"

- Static linking (in development)

- Data-race free by default

Unique features to Swift:

- Distributed actors for concurrency that run on distant machines. (This is doable but not native to the language)

- non-copy RAII generic types (not actually sure what this is so I assume it’s not in Dart)

> - Native C, C++, Java, Rust and JavaScript interop

dart doesn't do C++ interop

Isn’t “data-race free” in Dart achieved by just not really sharing mutable memory between isolates? Probably because the web version needs to map isolates to web workers, right?

For now but this is in the pipeline too.

https://github.com/dart-lang/language/blob/main/working/333%...

Great writeup, and I love that the authors looked at a lot of other languages. The solution section on how to prevent races is a bit light still - I‘m curious how they will solve this.

I think there will need to be exceptions to a strict race-free model eto not take away from dart‘s current capabilities, and without forcing people into something like a borrow checker. Swift has `@unchecked Sendable` which lets you tell the compiler "I promise I'll take care myself to keep everything in there race-free".

What I‘ve been missing in Swift are tools that let me add safety _within_ such @unchecked Sendables. There's the Swift Atomics lib: https://www.swift.org/blog/swift-atomics/, but its quite limited in its capabilities. So for now, I find myself reaching for tools provided by the community, like pointfree's LockIsolated: https://github.com/pointfreeco/swift-concurrency-extras/blob....

Swift has a garbage collector. Reference counting is a form of garbage collection.

> No garbage collector

No tracing gc. Ref counting is the other kind of garbage collector.

I'm primarily a C++ developer these days, and if the C++ interop is actually good then I'm very excited for the future. For app-dev type stuff it really does seem like it's better than Rust, and I can definitely see a world where we start migrating some code into Swift.

Edit: back from watching the video, and a few observations:

- Swift does not suffer from Rust's refusal to add things into the standard library. gasp regex support in stdlib? Async/await runtimes?

- Default testing framework is a godsend, especially when integrated into the build system

- Rust but better for everything that's not low-level systems development is the impression I get

The default testing framework made my jaw drop a bit - I have a very hard time seeing Rust have the enthusiasm or momentum to implement something like that right now.

Why do you think they wouldn't? (I don't keep up with Rust+its community closely enough to know.)

But Rust has had a default testing framework since 1.0?

I'm not a (direct) user of the C++ interop, but everything I've heard about it has been quite positive. A few hopefully relevant resources, first a couple of videos:

- "Introducing a Memory-Safe Successor Language in Large C++ Code Bases" (John McCall; CppNow 2023) https://www.youtube.com/watch?v=lgivCGdmFrw

- "Swift as C++ Successor in FoundationDB" (Konrad Malawski; Strange Loop 2023) https://www.youtube.com/watch?v=ZQc9-seU-5k

And then a series of blog posts by Doug Gregor:

- "Swift for C++ Practitioners" https://www.douggregor.net/posts/

And finally:

- "Mixing Swift and C++" (Swift.org) https://www.swift.org/documentation/cxx-interop/

Apple is using it for some low-level stuff and they appear to be trying to improve that every year.

I think they want to be able to use a limited subset of it in their kernel. Actually I think they already are but I’m not positive.

Obviously it started as an application level language but I do think they’re trying to move it down the stack as well.

Given there is native C++ interop, is exporting a C ABI still a seemingly experimental/niche feature? Same question with interop between C and Swift.

Recently went with using Kotlin Native over Swift on macOS for this reason, the C ABI export and C interop were painless.

Swift has painless interop with Objective-C, which is just C plus small talk.

C should already be pretty easy, though I haven’t really used it myself. I only use the Objective-C stuff.

I know they’ve been working on C++ but don’t have any experience to comment. Someone else had a nice comment listing resources on that.

Swift has had first-class C interop for a long time.

It is only C++ interop that is more experimental/in-progress.

Algebraic data types are not a Rust invention and aren't exclusive to that language.

I don’t think they were trying to claim that, just that it was a feature that was in Rust that they liked and wanted to keep using.

Just like Rust didn’t invent not using garbage collection.

> - No garbage collector

ARC is a GC, and a slower one than most traditional tracing GC's.

Reference counting and garbage collection are different.

They’re both forms automatic memory management, but they work in very different ways.

No they're not. Reference counting is a garbage collection algorithm. Its even described as such in most literature on garbage collection.

Reference counting and garbage collection are different, yes. But in terms of classifying "no garbage collection" under "things that Swift took from Rust", Swift's pervasive reference counting is much closer to classic tracing GC than it is to Rust's system of single ownership.

Automatic memory management is a synonym for garbage collection. Reference counting is a form of garbage collection.

First of all, traditional (tracing) GCs require more expensive runtimes and consume much more memory. ARCs are also much more predictable in their behavior and pave the way for greater compile time optimizations. ARC is key in providing Swift its ability to maintain its low memory footprint compared to, say, Java.

Second, yes, ARC is a GC method. But when the language says "no garbage collector", they just mean no traditional (tracing) GC runtime because, for better or worse, tracing GC is what people think of when they hear "garbage collector".

> traditional (tracing) GCs require more expensive runtimes and consume much more memory

Not really no. Look at go, D, nim, or any ahead of time compiled language.

> ARC is key in providing Swift its ability to maintain its low memory footprint compared to, say, Java

Again not really. Java has other issues. Like lack of value types, conservative escape analysis, needing extra memory for profiling and the jit, and HotSpot’s GCs are focused on server applications and are designed not to release memory until they’re about to run out.

Even if this were true ARC trades memory for execution speed. I can’t find the exact paper right now but the ixy implementations showed that you end up spending an unhealthy amount of time just counting references when you stay in pure swift code. I think it was somewhere > 30%.

The ixy examples were definitely nowhere near being idiomatic code.

Right. They spend a lot of time in pure swift and not within its C++ runtime, but when you want to compare garbage collection algorithms that doesn't really matter. The fact is that ARC is slow and you spend a ton of time counting references. Something an alternative algorithm wouldn't have to do.

- Anonymous enums/structs in parameters/match statements

I'm not sure what you mean by this, could you elaborate?

> Anonymous enums/structs in parameters

Can you share an example of this? It sounds really interesting but I couldn’t find any references. Do you mean the parameter “packs” features?