> slower than [...] nlohmann::json

considering that nlohmann::json not even a performance-oriented json library, generally benchmarking at 20% of the performance of RapidJSON (which itself is not even close to the fastest you can reach in C++) that's... scary

I noticed the same thing. Either Swift performances are atrocious, or I'm missing something.

Just the other day I was trying to sort a large array of strings in Swift and it was painfully slow. A 3 lines Python script managed to sort the same dataset _at least_ 10x faster.

I think it'd be curious to see the code, some example strings, and whether or not you compiled with optimizations enabled — if you're willing to share. There's no reason for this to have been the case.

Here you go: https://pastebin.com/iemfTkzx

As a dataset, I just use find to generate a list of paths from the file system:

find / > large.txt

I tested with Swift 5.7 and 5.9, and Python is always between 4x and 10x faster.

swift strings handles unicode

How recent were your experiences?

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.

Same applies on the memory management front, while it is understandable the decision they have made, for compatibility with Objective-C frameworks and runtime, most tracing GCs with 20+ years deployment experience are still faster than Swift on server workloads.

And it is worth remembering that Objective-C only got ARC, because adding a tracing GC was a failure, given C semantics, and most applications being prone to crashes, when the GC got pointers wrong, thus automating retain/release pairs was a much safer approach.