6 ms·

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 ou

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
        Sure, but often the duct tape and plywood makes it difficult to make things that are reliable and stay out of your way.
        troupo 2y ago
        And yet TypeScript doesn't fail with a cryptic nonsensical error just because you have the impossible component with an unfathomable number of two nested lists, like in SwiftUI.
        saagarjha 2y ago
        Algorithmically worse doesn't mean worse in practice
    - cyberax 2y ago
      Yeah. I have a bunch of code with bog-standard linear algebra classes (vec2, vec3, mat2, ...). No generics, no nothing. Just simple classes with operator overloading. After the recent minor XCode upgrade, Swift can't deduce the type for an expression `((v2 * scalar1) * v3)`, I have to split `let tmp1=v2*scalar1` for it to work. Like, wtf, Apple?
      - grandempire 2y ago
        It’s even possible to compile on one machine and timeout on another.
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.

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
        Sure, but often the duct tape and plywood makes it difficult to make things that are reliable and stay out of your way.
        troupo 2y ago
        And yet TypeScript doesn't fail with a cryptic nonsensical error just because you have the impossible component with an unfathomable number of two nested lists, like in SwiftUI.
        saagarjha 2y ago
        Algorithmically worse doesn't mean worse in practice
  - cyberax 2y ago
    Yeah. I have a bunch of code with bog-standard linear algebra classes (vec2, vec3, mat2, ...). No generics, no nothing. Just simple classes with operator overloading. After the recent minor XCode upgrade, Swift can't deduce the type for an expression `((v2 * scalar1) * v3)`, I have to split `let tmp1=v2*scalar1` for it to work. Like, wtf, Apple?
    - grandempire 2y ago
      It’s even possible to compile on one machine and timeout on another.

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.