[dmart]

With safe concurrency and typed throws, Swift is starting to look a lot like a friendlier Rust to me. Honestly pretty excited to take a look at it again, though I doubt it will become my daily driver due to the smaller package ecosystem. Hopefully cross-platform Foundation is a step towards improving that though.

[steelbrain]

> Swift is starting to look a lot like a friendlier Rust to me.

That’s what i thought and rewrote my cli util in swift. Ran great on macOS, tried to build for windows and found out there’s no well maintained, actively developed http server for windows for swift.

Dont let these wooing crowds fool you

[asplake]

Ha! That seems to answer my next question: what’s its story for web development? Does it have one?

[alexashka]

You can't compile for Linux from XCode (defacto IDE for all things Apple) and all web dev runs on linux.

If you like having an IDE instead of scrolling multi-page compiler error dumps in your terminal window - this is a complete non-starter.

The leading Swift web framework (Vapor) suggests you use Docker to build for Linux. I gave it an honest try - their empty starter 'hello world' web server takes more than a minute to compile. Ok, but surely it'll be faster after I make a one liner change? No - their docker workflow has 0 compiler caching - you'll be waiting more than a minute every time.

Complete non-starter.

I ended up installing a VM, installing the swift compiler and that only takes 2-3 seconds to re-compile a 1 liner change (in a print statement, in an empty project, lol). Consider me very deeply unimpressed.

By comparison - a visual studio code + docker + python/ruby/javascript setup is a well oiled, working machine.

[JoeMattiello]

You can install other toolkits for Xcode. There’s even an aws toolkit.

[alexashka]

Is it possible to write code in Xcode, press compile and have the debugger show me where an error is when compiling for linux.

If yes, please show me the way because I've failed and I've given it an earnest try.

[saagarjha]

You can use LSP?

[w10-1]

> story for web development

Under the hood, Swift-NIO and async Swift is a pretty powerful basis for writing performant servers. Aside from Vapor, there are other small/fast containers like hummingbird.

Not mentioned (surprisingly) is Swift support for wasm/wasi, for deploying code directly in the browser.

Also, "some say" that macros could revolutionize both static and dynamic generation by moving a good portion of site generation to compile time. I'm not aware of any libraries realizing that promise yet.

Finally, Swift concurrent actors have supported distribution for some time, so you can have all-Swift distributed systems, where the client code works with both local and remote servers.

[myko]

Vapor works great on Linux and macOS. Haven't tried Windows (pretty much only run Steam there these days)

[neonsunset]

For fast web servers, you could use .NET, especially if you care about Windows. It gives you good ecosystem and consistent experience across all platforms. Even FreeBSD support has improved considerably as of lately. It is already built on top of what Swift, Java and others call "NIO". In .NET it's just "SocketAsyncEngine" users will never know about unless they look for it :)

[Larrikin]

Did you look at Kotlin?

[synergy20]

Swift does not use virtual machine and garbage collection, it competes more to c++ and rust and if Apple is serious about pushing it cross platform that's definitely a welcome move, in fact, I can't wait even though I have never programmed in swift. the main point is that, it's memory safe, and seems much easier to code than rust.

[kaba0]

> garbage collection

Reference counting is garbage collection, and it performs significantly worse from a throughput perspective than tracing GC, which is possibly the most common metric for web server type workloads.

It really is not nitpicking, we should just really use tracing GC when we mean it.

[vetinari]

There is kotlin native, which generates native code, using the same llvm that c++, rust and swift use. It doesn't have to use virtual machine, it is just one of targets.

[synergy20]

not sure if it is 'production ready' and how does its performance/size go comparing to c++/rust/swift, in the end though, it's the ecosystem that matters.

[darby_nine]

> garbage collection

is reference counting not considered a form of garbage collection?

[syndeo]

Nope; no having to pause execution and clean up. Miguel de Icaza (the creator of Mono) explicitly mentions this as one of Swift's key strengths over GC languages like C# during a talk about Swift at GodotCon 2023: https://www.youtube.com/watch?v=tzt36EGKEZo&t=7s&pp=ygURc3dp...

[pjmlp]

Miguel naturally wants to sell Swift for Godot story.

Also some the Mono issues were related that they never had Microsoft's budget for implementing a bleeding edge runtime.

From Computer Science point of view RC is and will stay a GC algorithm.

https://gchandbook.org/contents.html

https://sites.cs.ucsb.edu/~ckrintz/racelab/gc/papers/levanon...

https://sites.cs.ucsb.edu/~ckrintz/racelab/gc/papers/AzaPet-...

[kaba0]

Maybe he should then read a book on garbage collectors that all start with ref counting..

Also, is it “pause execution and clean up” together? As ref counting obviously has to clean up, that’s the whole point - and it actually does so by blocking the mutator thread (the actual program written by the user). Then we didn’t even get to the point where syncing counters across threads are possibly the slowest primitive operation a CPU can do, so if we can’t know that an object will only ever be accessed from a single thread, ref counting has plenty shortcomings. Oh also, nulling the counter in case of a big object graph will pause execution for considerable amount of time (particularly noticeable in case of a c++ program exiting which uses a bunch of shared ptrs)

[neonsunset]

Perhaps? Most scenarios that explicitly involve .NET's GC vs Swift's ARC display much better performance of the former, to the point where the fact that ARC does not have GC pauses does not help if the whole things is multiple times slower, in many ways it's like Go's """low-pause""" GC design discussions that completely ignore allocation throttling and write barrier cost.

Swift lacking proper performant GC is a disadvantage. Upcoming features solve it by likely enabling more scenarios to sidestep ARC, but their impact on the Swift as a whole, and user applications that use them, is yet to be seen.

It's important to always remember - there's no free lunch.

I'm sad that Miguel de Icaza seems to have a bone to pick with C# nowadays, but it's not surprising given Xamarin story.

[darby_nine]

Man the term must have changed since I was in school; i thought garbage collection was a much more general concept than a specific tactic to achieve this end of automatic memory collection. Pity, it was a useful term.

It's worth noting many others also consider automatic reference counting to be a form of gc, albeit one with different strengths and weaknesses than stack- and heap-scanning varieties

[glhaynes]

Memory safe and, with Swift 6, data race safe.

[pzo]

there is Kotlin Native - "Kotlin/Native is a technology for compiling Kotlin code to native binaries which can run without a virtual machine."

https://kotlinlang.org/docs/native-overview.html

[timeon]

> Swift does not use virtual machine and garbage collection, it competes more to c++ and rust

Doesn't it use ARC by default?

[azinman2]

Which is reference counting, not garbage collection. Ref counts free when count = 0. Garbage collection scans all object pointers and looks for loops / no missing pointers.

[mkl]

That's tracing garbage collection. Reference counting is another type of garbage collection. https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...

[vor_]

Reference counting is a kind of garbage collection.

[synergy20]

it does, I thought ARC is more performant than GC and has no stop-the-world issue,thus not a GC

[neonsunset]

Usually, it's the other way around: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

binary-trees is almost completely dominated by the time spent in allocator code, and stresses its throughput. This benchmark showcases how big of a gap is between manual per-thread arenas, then tracing generational multi-heap GCs, then ARC and more specialized designs like Go GC. Honorable mention goes to BEAM which also showcases excellent throughput by having process-level independent GCs, in this case resembling the behavior of .NET's and OpenJDK GC implementations.

[pebal]

ARC is a variation of GC. Besides, a tracing GC doesn't have to stop the world at all.

[rudedogg]

It has nowhere near the performance characteristics of those languages. It could, but it doesn’t. Look up a variety of language benchmarks. It’s typically ranked around Python/Javascript. You can get as fast as C but the code is very atypical.

[azinman2]

There's no way it's close to Python. Where are the benchmarks?

https://github.com/sh3244/swift-vs-python

Shows a huge difference, as expected for a typed memory-safe compiled language using LLVM versus an interpreted language with a global interpreter lock.

[rudedogg]

https://forums.swift.org/t/really-bad-performance-with-concu...

[pzo]

It is slower, like probably ~3x but lets not exaggerate that it ranks around python

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[neonsunset]

Edit: Kotlin is perfectly fine for _just_ web-servers, Vert.X is great. On systems programming, read below:

All JVM languages are not viable by definition for this domain. Object oriented and heavily abstracted nature of the underlying runtime implementations prevents their effective usage in systems programming due to lack of fast FFI, structs, particularly so of custom layout, and the historical aversion of the ecosystem to low-level features.

Kotlin native does not count because presently it has 0.1-0.001x performance of OpenJDK, it is that bad, and I assume is subject to the common subset of features that must also be expressible with JVM.

.NET, especially with compilation to native statically linked binaries (NativeAOT) is an option, and I believe, due to ecosystem maturity as well as very heavy focus on performance in all recent .NET versions as well as continued improvement of low-level features (portable SIMD, byref pointers with simple lifetime analysis, static linking with C/C++/Rust/etc.), it is a strong contender. Unlike Java, C# has great systems programming story, after all, it was influenced as much by C++ as it was by Java, sadly many only ever think about the latter.

However, I'm looking forward to Swift 6. Once it is out, I'd love to see it offer more opportunities at ensuring static dispatch and generic monomorphization (in .NET, generics with struct arguments are always monomorphized like in Rust, so you have tools for zero-cost abstractions) and happy paths allowing to bypass prohibitive cost of ARC with new annotations. By using LLVM, Swift has theoretically great performance ceiling, even if it does not deliver on it just yet, losing to C# by a good margin on the more complicated code due to ARC and dynamic dispatch. But because Apple seems to be invested in using it for tasks that will require addressing these shortcomings, it is pretty exciting to see where they will take it.

[sandreas]

Isn't Kotlin based on JVM and Swift is natively compiled? That's a pretty significant difference and I'm not aware of any "to native" compiler for Kotlin like the NativeAOT approach exists for .NET...

[vetinari]

https://kotlinlang.org/docs/native-overview.html

[amaranth]

There are in fact two "to native" compilers for Kotlin, the one for Kotlin only is called Kotlin Native but you can also use graalvm native-image to compile any JVM language to native.

[jakey_bakey]

How hard is it to build an HTTP server?

(Yeah, this is a dumb question but I'm asking anyway)

[Eric_WVGG]

Do you mean from first-principles, or letting someone else do the work and use a framework?

Apple did the hard work, https://github.com/apple/swift-nio.

If you just want a big framework to launch an API, that's been around for years: https://vapor.codes

[taftster]

Sneakily hard, actually. There's different versions of HTTP (of course), so pick your target. But when you hit HTTP/2.0, it's not a simple request/reply model (if HTTP/1.1 can be described as such). The intermixing of various client headers and what they imply to server behavior, handling of the streams and when to open vs. when to close, http/2 multiplexing, etc. Don't forget HTTP/3 which uses the QUIC protocol (UDP based) instead of TCP.

Interestingly though, a trivial HTTP server is actually very easy to implement as well. A very crude HTTP/1.0 server (or maybe even a limited scope HTTP/1.1 server) can actually make for a fun afternoon project. Like minimal (or no) concurrency support, all TCP connections closed after the request/response cycle, GET only (or maybe POST only), etc.

So it's a mixed bag of what you want and how you define an HTTP server.

[astrange]

I can't think of a good reason to want to implement the complex parts. Write an HTTP service if you must, but make it HTTP/1.0 (or 1.1 for keepalive) and stick it behind nginx to do the newer versions and SSL termination.

(I also think all HTTP services should if possible be written in a shared-nothing CGI type language, and not embedded in your random stateful program. This way you can't accidentally leak info across user sessions.)

[taftster]

Both of these are great points. I do really appreciate an nginx (or other load balancer) front end. Or even cloudflare or whatever AWS/Azure offers. A simple horizontally scalable HTTP/1.1 backend with a reverse-proxy that can uplift your app is a great strategy.

Also, your comment about "shared-nothing" is interesting too. It surely doesn't hurt to think about it in this way, but likewise, might be out of scope for a simple web server concept (for example, if you're not even really supporting sessions at all).

[akvadrako]

That all depends on your requirements. A few hundred lines of code will get you pretty far, but there are about 100 optional features in common use.

[porcoda]

I’ve migrated to swift for some nontrivial projects that were formerly C++. Quite happy so far, and didn’t find rust nearly as pleasant when I tried the same thing there. I don’t want explicit memory management very often, so ARC works great for me. Haven’t had any issues with portability either, although I don’t test often on windows so I’m not confident there but Linux and Mac have been great.

[dogprez]

I'm glad you found something you like. I just want to make it clear that the things about Rust that make it "unfriendly" are also the things that make it able to do things other languages can't do, like compile-time memory safety. Depending on what you are making, that might make little difference. I just wanted to make sure you appreciated what Rust can do that other languages can't.

[astrange]

This is an article about another language that can do that.

[dogprez]

No, sorry, it's not https://doc.rust-lang.org/1.8.0/book/references-and-borrowin...

[astrange]

Swift does have borrow checking: https://www.swift.org/blog/swift-5-exclusivity/

Basically the difference is that Swift's is more implicit, happens more at runtime, and it will make some programs work via copy-on-write that Rust would reject.

So that's obviously more limiting. It's more flexible when you can allocate memory freely, but it doesn't work if you can't.

[dogprez]

> happens more at runtime

Bingo, that's the difference. That's why I said "compile-time memory safety". This is what Rust gives you for your trouble, zero (runtime) cost for memory safety.

[darby_nine]

Curious! In what ways do you do you see swift as friendlier than Rust? I perceived it as functionally equivalent, although Swift had a lot more "magic" involved and it was less clear how things might work memory-wise.

[dagmx]

To me, Swift has better ergonomics for most people.

Ref counting by default makes most programs easier to deal with.

Guard let (though recently somewhat introduced in rust) are much more friendly ways to unwrap optionals.

Being able to provide parameter defaults and aliases.

Easy passing in of callbacks. Easier async.

Null chains with the Question mark operator.

I really like rust, but it’s much faster to get to a working program in Swift.

And with the new CXX interop, I now reach for Swift by default since I have to deal with a lot of C++ libraries.

[darby_nine]

> Easier async.

I was on board until this one. Async is a rough spot for rust, but I find the async strategy swift went with absolutely baffling and difficult to reason about.

[dagmx]

I’m curious, what puts you off of them? Actors are pretty standard ways to do it, and I feel like most of the successful rust implementations are actor based as well.

[9dev]

More magic (thus less required explicitness) and less involvement with memory management are typically considered as friendly traits in programming languages.

[darby_nine]

> More magic (thus less required explicitness) and less involvement with memory management are typically considered as friendly traits in programming languages.

Really depends on the context. I really, really, really hated this instinct in the ruby on rails community when I was still doing that. Magic is nice until it doesn't work the way you expect, which is when it becomes an active liability.

I really don't spend much time thinking about memory management in Rust, but I can certainly understand why one might be happy to not have to design around ownership and lifetimes. I really like the explicit nature of it, though, makes it super easy to read and reason about code you've never seen before.