8 ms·

Swift would be perfect if it wasn't dying a death by 1000 cuts thanks to the inherent conflict in its governance. Swift is caught between two clans: the Swift

Swift would be perfect if it wasn't dying a death by 1000 cuts thanks to the inherent conflict in its governance. Swift is caught between two clans: the Swift Working Group™ open-source community, and the Apple corporate entity who pays most of their salaries. Both have their own incentives and their own imperfections, but you guess who has the majority influence. Ridiculous, permanent, tech debt such as hardcoded compiler exceptions are permanently living in the compiler codebase. Even worse, half-baked concepts such as result builders are pushed through without any real discussion because Apple wants the SwiftUI syntax to look pretty. It's an amazing language still, but I can't see it surviving as nicely in the next 10 years if Apple doesn't learn to let go.

riscy 2y ago
Can you explain how result builders are half-baked? They’ve been used for more than SwiftUI by now. The Regex support since 5.7 uses them: https://www.hackingwithswift.com/swift/5.7/regexes https://www.hackingwithswift.com/swift/5.7/regexes
- cageface 2y ago
  Because they rely on variadic generics they can make type inference very slow or just fail completely, leading to the infamous and singularly unhelpful compiler error, "The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions".
  - paperplatter 2y ago
    Swift is the only language where I've had to fight the compiler to do its job. In earlier versions like 1.x and 2.x, it would often segfault. By 3.x it was still really slow to build. I regretted moving a project off ObjC back then. I thought maybe that was all fixed by now, but guess not?
    - cageface 2y ago
      On paper Swift has a lot going for it. In practice it's easily the worst devx out of the modern languages. And SwiftUI is still so full of bugs and performance pitfalls I'm actually quite pessimistic about the future of native apps on Apple platforms.
      - paperplatter 2y ago
        Yeah there's a reason people go to all that effort with React Native to avoid writing Swift code or dealing with Apple's UI frameworks, and it's actually a reasonable approach for the majority of apps.
        ameliaquining 2y ago
        I mean, I figure the more compelling reason to do that is so you can also ship an Android app without writing everything twice.
        paperplatter 2y ago
        Sorta, but it's not as easy as they make it sound. And people will use RN even for iPhone-first stuff.
        evilfred 2y ago
        except for the thousand times you end up having to dip down into native components
        nwienert 2y ago
        I'd say most of the time it's a handful of times or less. Uniswap is a good example of a large OSS three-platform app that shares almost all the code, uses very few native dependencies, and has great UX. I maybe biased since I worked there and made the UI framework they use, though. https://github.com/uniswap/interface https://github.com/uniswap/interface
monkmartinez 2y ago
That is a fascinating take and approach to contemplating a language. Can you think of any other languages that share a duality like Swift? I mainly play in the python ecosystem, but I am looking to branch out and really learn a compiled language. What you wrote about Swift makes sense and would be concerning if I had recently picked it up. "Yadda, yadda..." regarding picking the right tool for the job aside, I don't want to waste time on a language that can be usurped by a giant corporate borg anytime they see fit.
- dagmx 2y ago
  C# for Microsoft and for a long time people were afraid of Amazons influence on Rust But the reality is that many major languages already have very outsized corporate influence. Either at the language level or the compiler level. Swift is open source and has been separating from Apple ownership as of this year.
- benoau 2y ago
  I can certainly think of a web browser that has that same conflict of interest... in fact we are actually right in the midst of a "leopards ate our face" moment with ad blocking becomes undesirable to Google in Chrome.
- troad 2y ago
  > I am looking to branch out and really learn a compiled language Tip from a friend - just learn C++. It's not sexy, it's not new-fangled, but it's rock solid, runs half the world, and you will never struggle to find a job. You'll also understand what it is that all of the new-langs are trying to improve upon, and will be able to made an educated judgment about whether they succeed or not. A good resource for modern C++ (albeit it seems to be down rn?) is https://www.learncpp.com/ https://www.learncpp.com/. I'm not affiliated, it's just good.
  - 6gvONxR4sf7o 2y ago
    I’ve been meaning to do this for years, and just played around with rust a bit (liked it, but the wrappers around some c++ stuff i wanted to use were half baked). Learning rust, there was this “rustlings” thing [0] that was a set of guided exercises to go alongside the rust book. Fastest I’ve ever picked up a language, thanks to that. Do you or anyone know anything similar for c++? [0] https://rustlings.cool/ https://rustlings.cool/
Vegenoid 2y ago
> Ridiculous, permanent, tech debt such as hardcoded compiler exceptions are permanently living in the compiler codebase. A little search-engining didn’t surface info about this, could you point me in the right direction?
- jakey_bakey 2y ago
  https://x.com/krzyzanowskim/status/1818881302394814717 https://x.com/krzyzanowskim/status/1818881302394814717
  - Vegenoid 2y ago
    Thank you - yeah, that smells pretty bad. But, although it says "can't be changed", could it not be changed if SwiftUI were changed? An up-to-date compiler would no longer be able to compile projects using older versions of SwiftUI, but is there not a path to get there by updating SwiftUI to not require this exception, then some time later, deprecating the older versions of SwiftUI, either throwing a warning on compilation or putting it behind a compiler flag, and then finally removing it altogether? It would certainly take a while, but could be done if Swift is aiming to be a mainstream, long-term, cross-platform language - unless this kind of thing is just not done, or there is some technical aspect I am missing?
paperplatter 2y ago
If I were new to Swift and saw how complicated and version-specific the Stackoverflow answers* are for things that are super simple in other languages, I wouldn't expect things to get much easier from there. And that instinct would be right. * https://stackoverflow.com/questions/34540185/how-to-convert-index-to-type-int-in-swift https://stackoverflow.com/questions/34540185/how-to-convert-... https://stackoverflow.com/questions/32305891/index-of-a-substring-in-a-string-with-swift https://stackoverflow.com/questions/32305891/index-of-a-subs... https://stackoverflow.com/questions/39677330/how-does-string-substring-work-in-swift https://stackoverflow.com/questions/39677330/how-does-string... https://stackoverflow.com/questions/24250938/swift-pass-array-by-reference https://stackoverflow.com/questions/24250938/swift-pass-arra...
- stephencanon 2y ago
  FWIW, that answer (to the second link, after edit) is really old, and you can do string.firstRange(of: substring) since Swift 5.7. The top answer to your third question gives a pretty good explanation of why Swift string indices work the way they do (as well as showing nicer ways to spell a lot of the operations on them), which mostly addresses the first and third questions. It really seems that your last link is just asking for the `inout` modifier; I'm not sure why that one is especially confusing. Obviously, there's always stuff that can be further improved, but none of these are especially onerous (once you get past the "string indices are not just integers" step, at least--for people who really just want to pretend the world uses ASCII or work with UTF8 bytes directly, string.utf8 may be an nicer interface to use).
  - deleted 2y ago
    [deleted]
  - paperplatter 2y ago
    The thing is, each string-related answer ended up extending it with some methods that everyone wanted it to have in the first place, and the top-voted comments are like "why do we have to do this." It also shouldn't have required multiple updates to each answer. The time I was doing a lot of string manipulation in a team Swift project, we had to write our own wrapper that basically stored strings as arrays of printable characters because the native one was too annoying. This also protected us from all the breaking changes Apple made to strings across Swift versions. The inout one is different. It's confusing that arrays and dicts are structs, which have different rules from regular objects, and the syntax takes some getting used to: func addItem(_ localArr: inout [Int]) { localArr.append(4) }
pbreit 2y ago
Was Swift really necessary? Would it really not have been possible to build iOS apps on something like JavaScript?
- astrange 2y ago
  It wouldn't be performant enough. Resist the urge to go as abstract as possible on a battery-powered device someone else is paying for.
- xanth 2y ago
  A low level language that's ergonomically interoperable with objective-c was probably the best choice.
- Decabytes 2y ago
  Apple never set out to create Swift. Chris partner worked on it for fun in his spare time, and when he realized it could go somewhere he went through the channels to get it turned into an official project. With that being said it was tailor made to address important issues for Apple developed. For example, it has great interop with Objective-C which was a requirement to get it adopted, first at Apple, and then with the wider community. It is also built with safety and security in mind removing lots of undefined behavior and adding null safety. It is also statically typed while JavaScript isn’t. There are a whole host of other goodies that it has that make it better for Apple developers than just adopting JavaScript. Chris partner has lots of talks where he goes over the reasonings
  - tonyedgecombe 2y ago
    >Chris partner Chris Lattner
jordanmorgan10 2y ago
I get what you’re saying and largely agree, but without result builders SwiftUI wouldn’t exist, let alone “look pretty”. You seem to be devaluing the syntactic sugar it brings, which in this case makes a massive difference.
msk-lywenn 2y ago
I was always puzzled by the swiftUI syntax. Thanks for pointer me to result builders, I understand better now. I can't help but thinking the whole thing could be re-implemented with macros now? (result builders appeared in 5.4, macros in 5.7)
pjmlp 2y ago
You can apply the same complaint to Java and .NET ecosystems, both doing quite well, despite not everything being open source, or being managed by entities that FOSS folks rather not deal with. "Oracle, IBM, Azul, AWS, Google..... this and that." "Microsoft this and that."

riscy 2y ago

Can you explain how result builders are half-baked? They’ve been used for more than SwiftUI by now. The Regex support since 5.7 uses them: https://www.hackingwithswift.com/swift/5.7/regexes https://www.hackingwithswift.com/swift/5.7/regexes

cageface 2y ago
Because they rely on variadic generics they can make type inference very slow or just fail completely, leading to the infamous and singularly unhelpful compiler error, "The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions".
- paperplatter 2y ago
  Swift is the only language where I've had to fight the compiler to do its job. In earlier versions like 1.x and 2.x, it would often segfault. By 3.x it was still really slow to build. I regretted moving a project off ObjC back then. I thought maybe that was all fixed by now, but guess not?
  - cageface 2y ago
    On paper Swift has a lot going for it. In practice it's easily the worst devx out of the modern languages. And SwiftUI is still so full of bugs and performance pitfalls I'm actually quite pessimistic about the future of native apps on Apple platforms.
    - paperplatter 2y ago
      Yeah there's a reason people go to all that effort with React Native to avoid writing Swift code or dealing with Apple's UI frameworks, and it's actually a reasonable approach for the majority of apps.
      - ameliaquining 2y ago
        I mean, I figure the more compelling reason to do that is so you can also ship an Android app without writing everything twice.
        paperplatter 2y ago
        Sorta, but it's not as easy as they make it sound. And people will use RN even for iPhone-first stuff.
        evilfred 2y ago
        except for the thousand times you end up having to dip down into native components
        nwienert 2y ago
        I'd say most of the time it's a handful of times or less. Uniswap is a good example of a large OSS three-platform app that shares almost all the code, uses very few native dependencies, and has great UX. I maybe biased since I worked there and made the UI framework they use, though. https://github.com/uniswap/interface https://github.com/uniswap/interface

monkmartinez 2y ago

That is a fascinating take and approach to contemplating a language. Can you think of any other languages that share a duality like Swift? I mainly play in the python ecosystem, but I am looking to branch out and really learn a compiled language. What you wrote about Swift makes sense and would be concerning if I had recently picked it up. "Yadda, yadda..." regarding picking the right tool for the job aside, I don't want to waste time on a language that can be usurped by a giant corporate borg anytime they see fit.

dagmx 2y ago
C# for Microsoft and for a long time people were afraid of Amazons influence on Rust But the reality is that many major languages already have very outsized corporate influence. Either at the language level or the compiler level. Swift is open source and has been separating from Apple ownership as of this year.
benoau 2y ago
I can certainly think of a web browser that has that same conflict of interest... in fact we are actually right in the midst of a "leopards ate our face" moment with ad blocking becomes undesirable to Google in Chrome.
troad 2y ago
> I am looking to branch out and really learn a compiled language Tip from a friend - just learn C++. It's not sexy, it's not new-fangled, but it's rock solid, runs half the world, and you will never struggle to find a job. You'll also understand what it is that all of the new-langs are trying to improve upon, and will be able to made an educated judgment about whether they succeed or not. A good resource for modern C++ (albeit it seems to be down rn?) is https://www.learncpp.com/ https://www.learncpp.com/. I'm not affiliated, it's just good.
- 6gvONxR4sf7o 2y ago
  I’ve been meaning to do this for years, and just played around with rust a bit (liked it, but the wrappers around some c++ stuff i wanted to use were half baked). Learning rust, there was this “rustlings” thing [0] that was a set of guided exercises to go alongside the rust book. Fastest I’ve ever picked up a language, thanks to that. Do you or anyone know anything similar for c++? [0] https://rustlings.cool/ https://rustlings.cool/

Vegenoid 2y ago

> Ridiculous, permanent, tech debt such as hardcoded compiler exceptions are permanently living in the compiler codebase. A little search-engining didn’t surface info about this, could you point me in the right direction?

jakey_bakey 2y ago
https://x.com/krzyzanowskim/status/1818881302394814717 https://x.com/krzyzanowskim/status/1818881302394814717
- Vegenoid 2y ago
  Thank you - yeah, that smells pretty bad. But, although it says "can't be changed", could it not be changed if SwiftUI were changed? An up-to-date compiler would no longer be able to compile projects using older versions of SwiftUI, but is there not a path to get there by updating SwiftUI to not require this exception, then some time later, deprecating the older versions of SwiftUI, either throwing a warning on compilation or putting it behind a compiler flag, and then finally removing it altogether? It would certainly take a while, but could be done if Swift is aiming to be a mainstream, long-term, cross-platform language - unless this kind of thing is just not done, or there is some technical aspect I am missing?

paperplatter 2y ago

If I were new to Swift and saw how complicated and version-specific the Stackoverflow answers* are for things that are super simple in other languages, I wouldn't expect things to get much easier from there. And that instinct would be right. * https://stackoverflow.com/questions/34540185/how-to-convert-index-to-type-int-in-swift https://stackoverflow.com/questions/34540185/how-to-convert-... https://stackoverflow.com/questions/32305891/index-of-a-substring-in-a-string-with-swift https://stackoverflow.com/questions/32305891/index-of-a-subs... https://stackoverflow.com/questions/39677330/how-does-string-substring-work-in-swift https://stackoverflow.com/questions/39677330/how-does-string... https://stackoverflow.com/questions/24250938/swift-pass-array-by-reference https://stackoverflow.com/questions/24250938/swift-pass-arra...

stephencanon 2y ago
FWIW, that answer (to the second link, after edit) is really old, and you can do string.firstRange(of: substring) since Swift 5.7. The top answer to your third question gives a pretty good explanation of why Swift string indices work the way they do (as well as showing nicer ways to spell a lot of the operations on them), which mostly addresses the first and third questions. It really seems that your last link is just asking for the `inout` modifier; I'm not sure why that one is especially confusing. Obviously, there's always stuff that can be further improved, but none of these are especially onerous (once you get past the "string indices are not just integers" step, at least--for people who really just want to pretend the world uses ASCII or work with UTF8 bytes directly, string.utf8 may be an nicer interface to use).
- deleted 2y ago
  [deleted]
- paperplatter 2y ago
  The thing is, each string-related answer ended up extending it with some methods that everyone wanted it to have in the first place, and the top-voted comments are like "why do we have to do this." It also shouldn't have required multiple updates to each answer. The time I was doing a lot of string manipulation in a team Swift project, we had to write our own wrapper that basically stored strings as arrays of printable characters because the native one was too annoying. This also protected us from all the breaking changes Apple made to strings across Swift versions. The inout one is different. It's confusing that arrays and dicts are structs, which have different rules from regular objects, and the syntax takes some getting used to: func addItem(_ localArr: inout [Int]) { localArr.append(4) }

pbreit 2y ago

Was Swift really necessary? Would it really not have been possible to build iOS apps on something like JavaScript?

astrange 2y ago
It wouldn't be performant enough. Resist the urge to go as abstract as possible on a battery-powered device someone else is paying for.
xanth 2y ago
A low level language that's ergonomically interoperable with objective-c was probably the best choice.
Decabytes 2y ago
Apple never set out to create Swift. Chris partner worked on it for fun in his spare time, and when he realized it could go somewhere he went through the channels to get it turned into an official project. With that being said it was tailor made to address important issues for Apple developed. For example, it has great interop with Objective-C which was a requirement to get it adopted, first at Apple, and then with the wider community. It is also built with safety and security in mind removing lots of undefined behavior and adding null safety. It is also statically typed while JavaScript isn’t. There are a whole host of other goodies that it has that make it better for Apple developers than just adopting JavaScript. Chris partner has lots of talks where he goes over the reasonings
- tonyedgecombe 2y ago
  >Chris partner Chris Lattner

jordanmorgan10 2y ago

I get what you’re saying and largely agree, but without result builders SwiftUI wouldn’t exist, let alone “look pretty”. You seem to be devaluing the syntactic sugar it brings, which in this case makes a massive difference.

msk-lywenn 2y ago

I was always puzzled by the swiftUI syntax. Thanks for pointer me to result builders, I understand better now. I can't help but thinking the whole thing could be re-implemented with macros now? (result builders appeared in 5.4, macros in 5.7)

pjmlp 2y ago

You can apply the same complaint to Java and .NET ecosystems, both doing quite well, despite not everything being open source, or being managed by entities that FOSS folks rather not deal with. "Oracle, IBM, Azul, AWS, Google..... this and that." "Microsoft this and that."