{"id":48087,"date":"2025-06-13T16:58:35","date_gmt":"2025-06-13T20:58:35","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=48087"},"modified":"2025-06-24T13:59:08","modified_gmt":"2025-06-24T17:59:08","slug":"swift-marketing-and-speed","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2025\/06\/13\/swift-marketing-and-speed\/","title":{"rendered":"Swift Marketing and Speed"},"content":{"rendered":"

Mishal Shah<\/a> (Reddit<\/a>):<\/p>\n

\n

Over the past few months, the website workgroup has been redesigning Swift.org. On behalf of the website workgroup, I’m pleased to announce that we have merged the initial changes.<\/p>\n

Our goal with the site redesign has been to make Swift.org more approachable for newcomers to Swift, highlight the language’s technical strengths, and make it easy to get started. That led to a focus on the website’s appearance, improving the user experience, and emphasizing important features such as Swift’s multiplatform support.<\/p>\n<\/blockquote>\n\n

jawbroken<\/a>:<\/p>\n

it’s unfortunate that the analytics script causing cmd-click to not open links in a new tab<\/a> hasn’t been fixed in the redesign, something that has been an issue for at least 7 years<\/a>. better luck next redesign, i guess<\/p><\/blockquote>\n\n

Swift.org<\/a>:<\/p>\n

\n

Swift is the powerful, flexible,\nmultiplatform programming language.<\/p>\n

Fast. Expressive. Safe.<\/p>\n

[…]<\/p>\n

Swift is the only language that scales from embedded devices and kernels to apps and cloud infrastructure.<\/p>\n<\/blockquote>\n\n

Nevin<\/a>:<\/p>\n

\n

I’ve been using Swift and contributing to Swift Evolution for a decade, it is by far my favorite and most used programming language, and I am a huge fan.<\/p>\n

Nonetheless, when I read those lines, my immediate reaction is “Wait, the<\/em>, and the only<\/em>? Are they saying that no other language<\/em> does those things?”<\/p>\n

Even if true, statements like that make me question the reliability of the narrator, and they come across as somewhat disparaging of other languages rather than just building up this one.<\/p>\n<\/blockquote>\n\n

Overall, I like the new homepage, but some of the wording is a bit<\/a> much<\/a>, and I think it’s unnecessary. There’s no need to pretend it’s something it’s not. I felt the same way about some of the benchmarks used to tout Swift’s performance when it was first introduced.<\/p>\n\n

Frank A. Krueger<\/a>:<\/p>\n

\n

Swift String<\/code> parsing is embarrassingly slow. I just converted code from String<\/code> indices<\/code>\/SubStrings<\/code> to Data<\/code> indices<\/code>\/SubSequences<\/code> (assuming UTF8, meh) and performance was 100x faster. Went from 8 minutes to parse an 80 MB file to 5 seconds.<\/p>\n

(Also 5 seconds is stupidly slow. Even Python can parse the same file, with the same algorithm, in about 1 second.)<\/p>\n<\/blockquote>\n\n

My experience is that Swift can<\/em> be very fast. But, especially with strings and bridging, you have to be careful and measure because sometimes there are unexpected sources of slowness. Likewise, code using Data<\/code> can really fly, but it can also get incredibly bogged down in safety checks if you don’t annotate your code such that Swift can statically prove exclusive access.<\/p>\n\n

There were some important new String<\/code> optimizations announced at WWDC.<\/p>\n\n

David Smith<\/a>:<\/p>\n

Bridging non-ASCII NSMutableStrings<\/code> from ObjC will be slower at the point of bridging, but<\/em> the String<\/code> produced as a result will be much faster.<\/p>

One particular case this tradeoff can end up not paying off in is if you then bridge the resulting String<\/code> back to ObjC. If you’re in that situation the recommendation is to not double-bridge strings if you can avoid it.<\/p>

<\/p><\/blockquote>\n\n

Previously:<\/p>\n