Well I for one appreciate Swift’s focus on ergonomics and progressive disclosure. I think Rust is great, but I don’t see it as a great application-level programming language.
I think it’s wonderful that Swift is trying to be more cross-platform. No need to shoot down the efforts of people trying to bring a language they like to more places.
Rust is much less ergonomic than Swift, especially for application-level development.
I like to think about it like this: Rust forces you to think about memory where Swift doesn’t.
But what’s really cool is that Swift is adopting some of the great things about Rust’s ownership system, allowing you to “opt-in” to a Rust-style performance profile if you think the mental overhead is worth it for your use-case or domain.
What’s exciting to me is that Swift is becoming a great language that works at all levels of the stack while staying a language that feels really great to write.
IMO what’s largely held it back in adoption is its cross-platform experience, but you see that the Swift team is really trying to change the perception here (they’ve specifically tried to highlight using non-Xcode/non-Mac dev environments, deploying to Linux, developing embedded etc.).
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%.
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.
I don't think this blog post ever intended to provide a comprehensive comparison between Swift/Vapor and other languages/frameworks.
I think the bigger lesson from this writeup is that we should be careful when looking at these kinds of benchmark comparisons because there may be much more nuance to their results than there initially appears to be.
I think so too, I also saw it as a lesson on careful and methodical debugging. I've been in situations like the one written up, trying to debug something tricky where each team member is coming up with multiple wrong hypotheses and missing something obvious.
Yeah I get that it's frustrating. But it is open source, and there isn't anything stopping you or anyone else from making contributions that bring the language to more places. Sure, various aspects of the project could be improved but that doesn't mean it is "half assed".
The server-side Swift ecosystem has matured over the past few years, with specific attention from teams at Apple.
For example, regarding JSON, there has been a rewrite of the JSON encoder/decoder that results in a 200% - 500% speed up in deserialization! You can read about the (still ongoing) improvements to Foundation at https://github.com/apple/swift-foundation
Regarding logging, Apple has been pushing the development of community around the swift-log package at https://github.com/apple/swift-log. Maybe you’ve seen this, but just wanted to share!
One last thing: the Swift VSCode extension is actually really good! Not sure when you used it last, but I’ve been using it on a regular basis and it’s been great — and is only getting better. Here’s the link to the extension if you’re curious: https://marketplace.visualstudio.com/items?itemName=sswg.swi...
It’s true that Swift has had its various issues, but there’s a very real push by the core team and community to bring the language to new heights and places. Cross-platform support is getting better and better (check out what The Browser Company is doing with Swift on Windows) and a big source of performance bottlenecks are being addressed with the development of non-copyable and non-escaping types (Rust-like move-only types)!
Sorry that’s a lot, but I just wanted to point out that there’s a lot of hope in Swift and really interesting things are happening for the project!
My recollection is as recent as a few months ago. Well I guess I’ll have to take another go at it this month, hopefully. I used three or four different JSON libraries aside from Foundation, including as I mentioned the quite popular yyjson wrapper which I expected to be on par with the pure C implementation. I’m out of the loop with the Swift ecosystem at the moment, can’t recall all the names.
I experimented with several logger implementations, likely to have used the one you’re suggesting. Thanks for pointing it out.
With the Vscode extension and the language server I suppose I had very palatable experience. It just didn’t work most of the time until I’d recompile the projects. Setting it up was a bit annoying as well, no build tool chain automations for project imports and setup, had to do the setup by hand. If I recall correctly, with one project an unpleasant issue I had was with the Swift Package Manager and CocoaPods, the Vscode extension wouldn’t recognize the project structure, and I ended up setting up a CMake project, good I have an affinity for CMake, and exporting it. But Xcode did just alright with it. So I just went back to Xcode for all my Swift projects. I think a plain SPM project actually got properly recognized in Vscode, but lots of dependencies are beyond SPM, which incidentally is also quite a significant annoyance in the Swift ecosystem.
I wish Swift enjoyed more attention, like .NET has been having. Oh and in terms of documentation I feel Swift is nowhere near .NET, even though the setting is comparable.
Referring to your closing remark, I don’t feel like that’s a lot, it’s a pleasure to learn more about Swift’s ecosystem, so thanks for taking your time to reply and providing extra context.
I feel like Swift enjoys much more actual good will and positive attention than C#. HN and other communities seem to be hell-bent on repeating the statements that weren't true even back in 2016 when it had its first FOSS version.
For example, this submission currently has 136 upvotes and 60 generally positive comments. The last .NET submission that reached frontpage had 158 upvotes and 255 comments, many of which would repeat personal experiences from 2007, complaining about products and languages that are not related to .NET but to something adjacent at best, or criticizing imagined spec and implementation issues that do not correspond to how the runtime and language actually work.
If anything, it seems like Swift can succeed if Apple puts more effort into it and community sentiment will be headwinds, not the other way around as is the case with .NET.
Microsoft's management keeps undercutting any good will that .NET manages to win, that is why.
Recent examples MSTest being proprietary for Native AOT testing, and no plans to help improve xUnit into that direction.
New VS Solution format, that might only be supported on the C# Dev Kit, also under VS license.
Killing VS4Mac, which although it has its own set of issues, VSCode still doesn't provide the same level of tooling for Mac and iDevices development as VS4Mac did, forcing anyone that cares to go out and buy Rider licenses instead.
The dotnet watch removal drama to only have hot-reload available on VS, thankfully back pedalled only thanks the engagement of high level .NET developers, with help of the community backslash on social media.
I was not looking for a response from your account, thanks.
(context: pjmlp likes to post about .NET, Java and other adjacent platforms with authoritative and confident tone not backed up by source material or simply reposting second hand or surface impressions of events, rather than just reading through publicly available information in full which could help some of the comments with being less detached from reality)
I was not looking for a response from your account, thanks.
(context: neonsunset professional life is highly dependent on where .NET goes, biased by involvement on .NET team's work, and how .NET is perceived by the world outside Redmond).
Codable fundamentally limits the maximum performance of any encoding or decoding, no matter how fast your parser is. If you need faster performance you need to use a completely different solution.
I wonder what the author thinks about Swift’s new C++ interop story? Since the Swift compiler includes Clang, and can thus compile both your C++ and Swift into LLVM IR, without the need for an FFI later between the two, couldn’t this be the “Typescript for C++” that the author points out a space for? The Swift folks are very much thinking about Swift as a C++ successor that can be incrementally migrated to so I’m a bit surprised the author didn’t discuss it further — especially given Swift’s spiritual similarities to Rust.
There’s a couple great talks on this by folks on the Swift team.
I do not know a ton about it. Thanks for the pointers.
I kept up with Swift more in the old days, but it doesn't seem to have gained a ton of relevance outside of Apple platforms, which I don't develop for. Doesn't mean that I think that it's bad, just that that's why I haven't spent a lot of time with it yet.
For sure! Yeah I think a lot of people don’t realize that there’s actually a ton of really interesting work going on in Swift that is very relevant to the current conversation around languages these days (i.e. memory safety, data race safety, performance, development experience, etc.)
The cross-platform story is getting quite good with Swift, but I think a lot of people just aren’t aware of it. Linux support is good and Windows is getting better and better.
Swift is an interesting option, though that interop requires dropping support for non-clang toolchains, and I don't see that happening any time soon. I mean, it makes sense for code that exclusively targets Apple platforms, and maybe that's all that Apple and the Swift team care about?
I think it’s wonderful that Swift is trying to be more cross-platform. No need to shoot down the efforts of people trying to bring a language they like to more places.