5 ms·

I actually see it in the exactly opposite way. A couple years ago, Swift was a nicely designed language, with a manageable number of composable features which

by skohan 4y ago

I actually see it in the exactly opposite way. A couple years ago, Swift was a nicely designed language, with a manageable number of composable features which could be used to do just about anything. With the features which were released alongside SwiftUI, it seems like that went out the window, and Swift pivoted towards being a DSL for iPhone apps.

kaba0 4y ago
I honestly don’t understand what were they thinking. Choose a random language’s random feature and swift has it. That’s hardly a good thing for a programming language, and it shows — there are some very nasty interactions between different features.
- skohan 4y ago
  I still think there's a lot to like about Swift, and actually programming in some subset of Swift is some of the most fun and expressive programming I can think of, but it has undoubtedly become kind of a mess. A lot of magic happening, and not in a good way.
  - kaba0 4y ago
    I agree, I was very enthusiastic at the beginning of learning it. And if nothing else, it is a great refresher of Pl features. I’m just afraid that the language can’t be properly maintained from the insane matrix of all these features (I once got a type inference timed out error..)
    - Tainnor 4y ago
      > I once got a type inference timed out error.. I used to work on a large Swift program. "Type inference timed out" was an incredibly common error that we would encounter (we used a lot of operator overloading and generics and that had something to do with it). I have never encountered any other language where this was such a regular problem.
pohl 4y ago
I find it difficult to empathize with that reaction. Other languages have complicated corners that I can safely ignore, why not Swift? Rust has its macros, Swift has its result-builders. The latter wins a nice way to declaratively-describe UI widgets, but if that's not what I'm doing I don't need to think about it.
- skohan 4y ago
  It's not about the features it's about priorities. In principal as you say you can just ignore the bits you don't use, but there are still some glaring holes like variadic generics which didn't get attention presumably because the core team was focused on SwiftUI. And due to the governance of the language, the "community" priorities will always take a back seat to Apple's product priorities, so it feels a bit funny to invest too heavily in the language for that reason alone.
  - pohl 4y ago
    Thank you for elaborating, that does help me appreciate your point of view better. I personally preferred that they prioritized result builders higher — I guess I agree with them that the needs of the UI layer were more urgent. It would be nice to have variadic generics, though.
- NobodyNada 4y ago
  > Rust has its macros, Swift has its result-builders. The difference is that Rust macros are general — they're useful for everybody, and they can be used to implement nearly any kind of custom syntax or code generation. There was talk on swift-evolution going back to the Swift 2-3 days about how Swift was eventually going to get “hygienic macros” that looked something like Rust’s proc-macros. But this was a very long-term goal; everyone knew it would take years to design and implement such a system that had the flexibility, safety, and expressivity we all wanted. In the meantime though, Apple started to add a lot of complicated features using compiler magic. This started with Codable, which added language support for serializing and deserializing objects to formats like JSON. This was awesome, and became one of Swift’s best features IMO. But the implementation bothered me a little: it’s a protocol where the compiler will synthesize a default boilerplate implementation if you don’t implement it manually. But this is exactly the kind of thing that a real hygienic macro system would be better for; e.g. Rust's serde does the same thing as Codable, but it's way more powerful and more flexible. IIRC some people pointed this out on the forums, but this was dismissed with “we want to ship this now, and macros are years down the road.” Oh well, don’t let perfect be the enemy of good, right? But the Swift 5 release had even more compiler magic — a bunch more protocols gained automatic compiler synthesis, and then “result builders” happened. Again: a feature that’s helpful in isolation, and solves a real problem, but greatly increases the language surface area. And since these features are implemented using compiler magic, only the compiler team can add new features, and it takes a long time. So in practice, the only magic features that get implemented are those that Apple needs for their libraries. Whereas if they had spent that time and effort working on a hygienic macro system, they could have achieved Codable, result builders, and every other use case library authors can imagine. Chris Lattner has indicated that this sort of thing was part of the reason he left the core team: "It is obvious that Swift has outgrown my influence, and some of the design premises I care about (e.g. "simple things that compose") don't seem in vogue any more." [0] It became clear (partly through this, but also because of a LOT of other stuff) that the evolution of the Swift language was being driven by Apple's internal schedules, and not the other way around. Controversial or half-baked features were frequently rushed through review in order to be ready in time for WWDC -- or even worse, shown off in surprise reveals at WWDC, with the core team saying things like "yeah we know this is a bad design, but we showed it in the WWDC keynote so we can't change it now" [1]. At this point, I started to experiment with Rust because Swift's memory-management overhead was causing me too many performance headaches. It felt like a breath of fresh air: the language feels like it evolves at a snails' pace compared to Swift, but every feature that makes it into stable is extremely polished and very well-thought-out, especially with regard to how it fits with the rest of the language, and how it works in "weird" situations like embedded environments. [0]: https://forums.swift.org/t/core-team-to-form-language-workgroup/55455/6 https://forums.swift.org/t/core-team-to-form-language-workgr... [1]: https://forums.swift.org/t/se-0258-property-wrappers-second-review/25843/194 https://forums.swift.org/t/se-0258-property-wrappers-second-...
georgelyon 4y ago
I tend to agree with much of the criticism of SwiftUI, namely that it and the underlying mechanism (result builders) is over-indexed on the UI-for-iPhone-apps use case. But I think Swift's greatest strength is what I mentioned in the parent comment: progressive disclosure. You don't need to use result builders and if you don't, the complexity of the language stays the same. I contrast that with C++ which has added some powerful, complex features that underpin most of the language, making it more necessary to understand the full scope of the feature set to get anything done.

by skohan 4y ago

kaba0 4y ago

I honestly don’t understand what were they thinking. Choose a random language’s random feature and swift has it. That’s hardly a good thing for a programming language, and it shows — there are some very nasty interactions between different features.

skohan 4y ago
I still think there's a lot to like about Swift, and actually programming in some subset of Swift is some of the most fun and expressive programming I can think of, but it has undoubtedly become kind of a mess. A lot of magic happening, and not in a good way.
- kaba0 4y ago
  I agree, I was very enthusiastic at the beginning of learning it. And if nothing else, it is a great refresher of Pl features. I’m just afraid that the language can’t be properly maintained from the insane matrix of all these features (I once got a type inference timed out error..)
  - Tainnor 4y ago
    > I once got a type inference timed out error.. I used to work on a large Swift program. "Type inference timed out" was an incredibly common error that we would encounter (we used a lot of operator overloading and generics and that had something to do with it). I have never encountered any other language where this was such a regular problem.

pohl 4y ago

I find it difficult to empathize with that reaction. Other languages have complicated corners that I can safely ignore, why not Swift? Rust has its macros, Swift has its result-builders. The latter wins a nice way to declaratively-describe UI widgets, but if that's not what I'm doing I don't need to think about it.

skohan 4y ago
It's not about the features it's about priorities. In principal as you say you can just ignore the bits you don't use, but there are still some glaring holes like variadic generics which didn't get attention presumably because the core team was focused on SwiftUI. And due to the governance of the language, the "community" priorities will always take a back seat to Apple's product priorities, so it feels a bit funny to invest too heavily in the language for that reason alone.
- pohl 4y ago
  Thank you for elaborating, that does help me appreciate your point of view better. I personally preferred that they prioritized result builders higher — I guess I agree with them that the needs of the UI layer were more urgent. It would be nice to have variadic generics, though.
NobodyNada 4y ago
> Rust has its macros, Swift has its result-builders. The difference is that Rust macros are general — they're useful for everybody, and they can be used to implement nearly any kind of custom syntax or code generation. There was talk on swift-evolution going back to the Swift 2-3 days about how Swift was eventually going to get “hygienic macros” that looked something like Rust’s proc-macros. But this was a very long-term goal; everyone knew it would take years to design and implement such a system that had the flexibility, safety, and expressivity we all wanted. In the meantime though, Apple started to add a lot of complicated features using compiler magic. This started with Codable, which added language support for serializing and deserializing objects to formats like JSON. This was awesome, and became one of Swift’s best features IMO. But the implementation bothered me a little: it’s a protocol where the compiler will synthesize a default boilerplate implementation if you don’t implement it manually. But this is exactly the kind of thing that a real hygienic macro system would be better for; e.g. Rust's serde does the same thing as Codable, but it's way more powerful and more flexible. IIRC some people pointed this out on the forums, but this was dismissed with “we want to ship this now, and macros are years down the road.” Oh well, don’t let perfect be the enemy of good, right? But the Swift 5 release had even more compiler magic — a bunch more protocols gained automatic compiler synthesis, and then “result builders” happened. Again: a feature that’s helpful in isolation, and solves a real problem, but greatly increases the language surface area. And since these features are implemented using compiler magic, only the compiler team can add new features, and it takes a long time. So in practice, the only magic features that get implemented are those that Apple needs for their libraries. Whereas if they had spent that time and effort working on a hygienic macro system, they could have achieved Codable, result builders, and every other use case library authors can imagine. Chris Lattner has indicated that this sort of thing was part of the reason he left the core team: "It is obvious that Swift has outgrown my influence, and some of the design premises I care about (e.g. "simple things that compose") don't seem in vogue any more." [0] It became clear (partly through this, but also because of a LOT of other stuff) that the evolution of the Swift language was being driven by Apple's internal schedules, and not the other way around. Controversial or half-baked features were frequently rushed through review in order to be ready in time for WWDC -- or even worse, shown off in surprise reveals at WWDC, with the core team saying things like "yeah we know this is a bad design, but we showed it in the WWDC keynote so we can't change it now" [1]. At this point, I started to experiment with Rust because Swift's memory-management overhead was causing me too many performance headaches. It felt like a breath of fresh air: the language feels like it evolves at a snails' pace compared to Swift, but every feature that makes it into stable is extremely polished and very well-thought-out, especially with regard to how it fits with the rest of the language, and how it works in "weird" situations like embedded environments. [0]: https://forums.swift.org/t/core-team-to-form-language-workgroup/55455/6 https://forums.swift.org/t/core-team-to-form-language-workgr... [1]: https://forums.swift.org/t/se-0258-property-wrappers-second-review/25843/194 https://forums.swift.org/t/se-0258-property-wrappers-second-...

georgelyon 4y ago

I tend to agree with much of the criticism of SwiftUI, namely that it and the underlying mechanism (result builders) is over-indexed on the UI-for-iPhone-apps use case. But I think Swift's greatest strength is what I mentioned in the parent comment: progressive disclosure. You don't need to use result builders and if you don't, the complexity of the language stays the same. I contrast that with C++ which has added some powerful, complex features that underpin most of the language, making it more necessary to understand the full scope of the feature set to get anything done.