I've been writing Swift daily, since the day it was announced, and have shipped a number of apps, written in it.
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.
>The string processing is powerful, but inconvenient when you want to do things like indexing by offsets or ranges, due to Unicode semantics. (This is probably a good thing in general.)
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 in the code, especially since people usually think it is not complex.
If you want an array of UInt8, just use that.
The part about the regex I agree with. They are slow and that’s a shame. I do not personally use regex much though, and don’t think it should be done much in prod either, unless there are no other options, but that does not excuse a poor implementation.
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 a 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.
FWIW, AoC is very non-representative of real-world string manipulation problems.
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.
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 `nthCharacter(n:)`, but that's nitpicking. It's a one-liner to add yourself.
I'm curious, in what niches are people using Swift for new applications these days? I've enjoyed working with Swift in the past (albeit in very limited capacities), but I haven't personally come across any Swift-based initiatives in a while. I had high hopes for Swift for TensorFlow, but it was ultimately killed off.
I've been writing Swift daily, since the day it was announced, and have shipped a number of apps, written in it.
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/
>The string processing is powerful, but inconvenient when you want to do things like indexing by offsets or ranges, due to Unicode semantics. (This is probably a good thing in general.)
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.
> poorly designed String API
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 in the code, especially since people usually think it is not complex.
If you want an array of UInt8, just use that.
The part about the regex I agree with. They are slow and that’s a shame. I do not personally use regex much though, and don’t think it should be done much in prod either, unless there are no other options, but that does not excuse a poor implementation.
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 a 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.
FWIW, AoC is very non-representative of real-world string manipulation problems.
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.
> poorly designed String API
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 `nthCharacter(n:)`, but that's nitpicking. It's a one-liner to add yourself.
I'm curious, in what niches are people using Swift for new applications these days? I've enjoyed working with Swift in the past (albeit in very limited capacities), but I haven't personally come across any Swift-based initiatives in a while. I had high hopes for Swift for TensorFlow, but it was ultimately killed off.
I'm using it for the "business logic" (control plane) in an embedded device. Yocto integration may be useful to others doing same. [1]
[1] https://github.com/jeremy-prater/meta-swift
Usually for native iOS/macOS applications.
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...
Apps for Apple platforms.