5 ms·

Rust, Go, and Swift were all coming up around the same time. Rust looked ugly, Go underwhelmed me, and Swift aeemed like the best “language” at the time, with m

Rust, Go, and Swift were all coming up around the same time. Rust looked ugly, Go underwhelmed me, and Swift aeemed like the best “language” at the time, with many opinions that aligned with my own. Having now spent time in all three, swift feels the most ergonomic and has features that make me feel productive. I still feel like there isn’t much “there” in Go, and rust makes me feel like I’m solving for the compiler rather than working on whatever problem I was needing to work on. Edit to add: SwiftUI, however, is a mess that I loathe. I may be in the minority of enjoying the IoC choices in Interface Builder and AppKit.

jkubicek 2y ago
SwiftUI is just amazing for the first 30 minutes you use it... then you make a minor syntax error deep in some nested views and you're selectively commenting out coded blocks to hone in on the error like a caveman. It makes print-statement debugging look cutting edge.
- turnsout 2y ago
  As an early adopter of SwiftUI, this hasn't been my experience—but I understand that a lot of people struggle with it. I think it's pretty opinionated, and if you stick to the "preferred" way of doing things, life is easier. The biggest (and known) issue with SwiftUI is the complex error messages you get, and the fact that the type checker will give up and ask you to break up your view into "distinct sub-expressions." Really the issue is almost never the complexity of a view, but some simple syntax error (passing the wrong type to a function, etc).
  - troupo 2y ago
    > The biggest (and known) issue with Isn't this literally what the person above is talking about? > Really the issue is almost never the complexity of a view, but some simple syntax error (passing the wrong type to a function, etc). The issue is that this is a big, known, common problem that cannot be solved, apparently
    - grandempire 2y ago
      Yeah. My understanding is the design of type inference is flawed and requires exponential complexity to resolve and it’s not fixable without breaking change. Why this is not a top priority before literally anything else?
      - yAak 2y ago
        I agree with you, but sounds like a rough problem: https://danielchasehooper.com/posts/why-swift-is-slow/ https://danielchasehooper.com/posts/why-swift-is-slow/
        saagarjha 2y ago
        The author is welcome to add type annotations if they want…?
        grandempire 2y ago
        ?? No other language times out error checking. This is insanity.
        saagarjha 2y ago
        Not regularly but many languages have type systems that are algorithmically worse, like TypeScript
        9dev 2y ago
        As a user, I couldn’t care less about the algorithmic beauty of the type system if it works, lets me type complex things reliably, and is fast enough to stay out of my way. Does it do that by being a mess of duct table and plywood? Totally fine for me.
        saagarjha 2y ago
- troupo 2y ago
  > deep in some nested views It doesn't even have to be deep. I ran into this issue on very few quite simple components. The compiler just gives up because somehow swift's type system makes it impossible to figure out
- bjustin 2y ago
  This problem is very real. There is at least an ok way to avoid it getting too bad: make lots of View and ViewModifier structs, with each one having smallish amounts of code. Split them up to the extent that it feels silly. As an added bonus, this is also the way to get good performance at run time. It helps minimize how many views need to get re-evaluated when something changes.
cosmic_cheese 2y ago
This is more or less how I feel too. Writing Swift feels good, and once you make a habit of avoiding code smells that trip up SourceKit, syntax coloration and all that works well enough too. SwiftUI on the other hand gets to be a mess for anything larger than small components and collection view cells. And so I write pure code UIKit most of the time. It’s not trendy but it’s very effective.
ben_w 2y ago
I agree about SwiftUI. It's something I want to like, but everything about it… no. For me, SwiftUI does exactly two things better than UIKit: tables and collection views. For everything else, it's so much easier to get stuff done with UIKit*, regardless of if I'm working with Interface Builder or making UI in code (as per various projects I've dropped into). In theory, reactive UI is good. In practice, at least in the case of SwiftUI, the "magic" data passing does sometimes fail — perhaps someone put in the wrong @ on the property — and then you've got to debug some weird magic, and if there's a sensible place to put a breakpoint for that kind of problem I have yet to learn it. In theory, the UI is reusable across all Apple platforms. In practice, the nature of the user experience is so different that actually trying this makes it suck for everyone — you don't want finger-sized buttons on a mouse-driven UI or tiny mouse-suitable click areas for a mobile UI, and I have no idea what the user expectations are for tvOS or WatchOS despite having written apps for both because hardly anyone shares their experiences and lessons learned. In theory, having the code be the source of truth for the WYSIWYG editor is great. In practice, the WYSIWYG editor keeps giving up because of e.g. a compiler error, and decides to stop forever until you manually resume the preview. * I'm mostly on iOS rather than macOS, but I'd assume UIKit and AppKit have the same strengths and weaknesses.
- cosmic_cheese 2y ago
  Even outside of iOS I’m not fully convinced that declarative/reactive is “the way”. Jetpack Compose while not as bad as SwiftUI in some ways shares many of its problems, including the magic, inscrutable stack traces, and challenges in reasoning. Past a certain level of complexity imperative UI feels more manageable.
- saagarjha 2y ago
  > In theory, the UI is reusable across all Apple platforms. This is the practice (when people are lazy). The theory that Apple presented was that you are supposed to tweak your UI for each platform and share some of the common code.

jkubicek 2y ago

SwiftUI is just amazing for the first 30 minutes you use it... then you make a minor syntax error deep in some nested views and you're selectively commenting out coded blocks to hone in on the error like a caveman. It makes print-statement debugging look cutting edge.

turnsout 2y ago
As an early adopter of SwiftUI, this hasn't been my experience—but I understand that a lot of people struggle with it. I think it's pretty opinionated, and if you stick to the "preferred" way of doing things, life is easier. The biggest (and known) issue with SwiftUI is the complex error messages you get, and the fact that the type checker will give up and ask you to break up your view into "distinct sub-expressions." Really the issue is almost never the complexity of a view, but some simple syntax error (passing the wrong type to a function, etc).
- troupo 2y ago
  > The biggest (and known) issue with Isn't this literally what the person above is talking about? > Really the issue is almost never the complexity of a view, but some simple syntax error (passing the wrong type to a function, etc). The issue is that this is a big, known, common problem that cannot be solved, apparently
  - grandempire 2y ago
    Yeah. My understanding is the design of type inference is flawed and requires exponential complexity to resolve and it’s not fixable without breaking change. Why this is not a top priority before literally anything else?
    - yAak 2y ago
      I agree with you, but sounds like a rough problem: https://danielchasehooper.com/posts/why-swift-is-slow/ https://danielchasehooper.com/posts/why-swift-is-slow/
      - saagarjha 2y ago
        The author is welcome to add type annotations if they want…?
        grandempire 2y ago
        ?? No other language times out error checking. This is insanity.
        saagarjha 2y ago
        Not regularly but many languages have type systems that are algorithmically worse, like TypeScript
        9dev 2y ago
        As a user, I couldn’t care less about the algorithmic beauty of the type system if it works, lets me type complex things reliably, and is fast enough to stay out of my way. Does it do that by being a mess of duct table and plywood? Totally fine for me.
        saagarjha 2y ago
troupo 2y ago
> deep in some nested views It doesn't even have to be deep. I ran into this issue on very few quite simple components. The compiler just gives up because somehow swift's type system makes it impossible to figure out
bjustin 2y ago
This problem is very real. There is at least an ok way to avoid it getting too bad: make lots of View and ViewModifier structs, with each one having smallish amounts of code. Split them up to the extent that it feels silly. As an added bonus, this is also the way to get good performance at run time. It helps minimize how many views need to get re-evaluated when something changes.

cosmic_cheese 2y ago

This is more or less how I feel too. Writing Swift feels good, and once you make a habit of avoiding code smells that trip up SourceKit, syntax coloration and all that works well enough too. SwiftUI on the other hand gets to be a mess for anything larger than small components and collection view cells. And so I write pure code UIKit most of the time. It’s not trendy but it’s very effective.

ben_w 2y ago

I agree about SwiftUI. It's something I want to like, but everything about it… no. For me, SwiftUI does exactly two things better than UIKit: tables and collection views. For everything else, it's so much easier to get stuff done with UIKit*, regardless of if I'm working with Interface Builder or making UI in code (as per various projects I've dropped into). In theory, reactive UI is good. In practice, at least in the case of SwiftUI, the "magic" data passing does sometimes fail — perhaps someone put in the wrong @ on the property — and then you've got to debug some weird magic, and if there's a sensible place to put a breakpoint for that kind of problem I have yet to learn it. In theory, the UI is reusable across all Apple platforms. In practice, the nature of the user experience is so different that actually trying this makes it suck for everyone — you don't want finger-sized buttons on a mouse-driven UI or tiny mouse-suitable click areas for a mobile UI, and I have no idea what the user expectations are for tvOS or WatchOS despite having written apps for both because hardly anyone shares their experiences and lessons learned. In theory, having the code be the source of truth for the WYSIWYG editor is great. In practice, the WYSIWYG editor keeps giving up because of e.g. a compiler error, and decides to stop forever until you manually resume the preview. * I'm mostly on iOS rather than macOS, but I'd assume UIKit and AppKit have the same strengths and weaknesses.

cosmic_cheese 2y ago
Even outside of iOS I’m not fully convinced that declarative/reactive is “the way”. Jetpack Compose while not as bad as SwiftUI in some ways shares many of its problems, including the magic, inscrutable stack traces, and challenges in reasoning. Past a certain level of complexity imperative UI feels more manageable.
saagarjha 2y ago
> In theory, the UI is reusable across all Apple platforms. This is the practice (when people are lazy). The theory that Apple presented was that you are supposed to tweak your UI for each platform and share some of the common code.