Advent of Swift
Key topics
The Swift programming language is under scrutiny as developers tackle the Advent of Code challenge, sparking a heated debate about its String API. Some commenters, like frizlab and happytoexplain, vehemently defend Swift's approach, arguing that other languages get it "horribly wrong" when handling Unicode semantics, while others, such as zzo38computer, counter that indexing by bytes would be more practical. The discussion reveals a consensus that Swift's String API is intentionally designed to prioritize Unicode correctness over raw performance, with ezfe clarifying that this means sacrificing constant-time indexing. As the community weighs in, it becomes clear that Swift's niche is still thriving, with ChefboyOG wondering about its modern applications, and amomchilov pointing out that Advent of Code's string manipulation challenges may not reflect real-world use cases.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
1h
Peak period
16
0-6h
Avg / period
5.6
Based on 28 loaded comments
Key moments
- 01Story posted
Dec 14, 2025 at 3:04 PM EST
19 days ago
Step 01 - 02First comment
Dec 14, 2025 at 4:32 PM EST
1h after posting
Step 02 - 03Peak activity
16 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 16, 2025 at 6:13 PM EST
17 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
This is being too generous to Swift's poorly designed String API. The author gets into it immediately after the quote with an Array<Character> workaround, regex issues, and later Substring pain. It's not a fatal flaw, a language backed by one of the richest companies in the world can have few fatal flaws, but AoC in particular shines a light on it.
I really like Swift as an application/games language but I think it unlikely it can ever escape that domain.
I wholeheartedly disagree and counterpoint that all other String APIs are wrong (bold statement, I know). Accessing a random index of a String is a complex (slow) operation, and as such, should be reflected as complex, especially since people usually think it is not complex.
If you want an array of UInt8, just use that.
Regarding the domain, I recognize it seems to have difficulties escaping the “native iOS/macOS apps,” but IMHO it should not. It is a language that is simple to use, with reasonable memory handling default (ARC), though it can also use the memory ownership model of rust. Generally speaking using Swift is possible everywhere. I use it personally for an app (native and web front, and back), and it is extremely cool.
Its ecosystem is also becoming quite interesting. Most of the libs are from Apple, yes, but they are also very qualitative.
All in all I think it’s shame Swift is not more used overall in the industry.
Nope nope nope.
I have to agree strongly with my sibling commenter. Every other language gets it horribly wrong.
In app dev (Swift's primary use case), strings are most often semantically sequences of graphemes. And, if you at all care about computer science, array subscripting must be O(1).
Swift does the right thing for both requirements. Beautiful.
OK, yes, maybe they should add a native `nthCharater(n:)`, but that's nitpicking. It's a one-liner.
In Rust "AbcdeF"[1] isn't a thing, it won't compile, but "AbcdeF"[1..=1] says we want the UTF-8 substring starting from byte 1 through to byte 1 and that compiles, and it'll work because that string does have a valid UTF-8 substring there, it's "b" -- However it'll panic if we try to "€300"[1..=1] because that's no longer a valid UTF-8 substring, that's nonsense.
For app dev this is too low level, but it's nice to have a string abstraction that's at home on a small embedded device where it doesn't matter that I can interpret flags, or an emoji with appropriate skin tones, or whatever else as a distinct single grapheme in Unicode, but we would like to do a bit better than "Only ASCII works in this device" in 2025.
In 2005 it's rather old-fashioned. There's lots of 8859-1 and cp1252 out there but people aren't making so much of it, and Unicode aka 10646 is clearly the future.
In 2015 it's a done deal.
Here we are in 2025. Stop treating non-Unicode text as anything other than an aberration.
You don't need checks "for every string operation". You need a properly designed string type.
It's often the case that we know where a substring we want starts and ends, so this operation makes sense - because we know there's a valid substring this won't panic. For example if we know there's a literal colon at bytes 17 and 39 in our string foo, foo[18..39] is the UTF-8 text from bytes 18 to 38 inclusive, representing the string between those colons.
One source of confusion here, is not realising that UTF-8 is a self-synchronising encoding. There are a lot of tricks that are correct and fast with UTF-8 but would be a disaster in the other multi-byte encodings or if (which is never the case in Rust) this isn't actually a UTF-8 string.
We don't care that it takes longer, we all know that, we still need to do a bunch of string operations anyway, and it's way worse with swift than to do an equivalent thing than it is than pretty much any other language.
Like I said, you can easily extend String to look up graphemes by integer index, but you should define it as a function, not a subscript, to honor the convention of using subscripts only for constant-time access.
If you know it's safe to do you can get a representation as a list of UInt8 and then index into that.
The AoC format goes out of its way to express all problem inputs and outputs in simple strings with only basic ASCII text, just for compatibility with the most programming environments. This is very different from almost all real-world problem, where the complexities of human language are huge.
[1] https://github.com/jeremy-prater/meta-swift
I use it also for a server of mine (and generally any new project I have).
I have also a few open-source projects in Swift[1][2], but none known.
[1] https://github.com/xcode-actions
[2] https://github.com/Frizlab?tab=repositories&q=&type=&languag...
I have learned to like the language. It's not perfect, but comes closer than most. I've written in a lot of languages, over the years.
My other language is PHP, which I use for my backend work. I've probably been writing that for over twenty years, but I still don't like the language.
As I was learning Swift, I started this series of posts[0]. It's still ongoing, but I haven't added anything in a while, and the language has progressed, since the earlier posts.
[0] https://littlegreenviper.com/series/swiftwater/
It’s no big deal. I don’t really do much backend work, so PHP is fine for that.
https://github.com/antfarm/AdventOfCode2024