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).

> 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

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?

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?

It’s even possible to compile on one machine and timeout on another.

I agree with you, but sounds like a rough problem:

https://danielchasehooper.com/posts/why-swift-is-slow/

The author is welcome to add type annotations if they want…?

?? No other language times out error checking. This is insanity.

Not regularly but many languages have type systems that are algorithmically worse, like TypeScript

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.

Sure, but often the duct tape and plywood makes it difficult to make things that are reliable and stay out of your way.

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.

Algorithmically worse doesn't mean worse in practice

Can you show a common line of type script that will take exponential complexity for typescript to resolve?

I think you misunderstood my comment.

My understanding is you are saying TypeScript has a similar complexity problem in its type system as Swift.

I am wondering if you have a common example that would timeout or have problems.

If not then I struggle to see what similarity you are seeing.

(Genuine question, I am interested in what other languages do)

No, I'm saying it has a worse system than Swift's. The point I'm making is that they've designed things such that the normal case doesn't hit this, while Swift keeps adding APIs that exercise the worst of their type system.

Everyone misunderstood your reply.

Perhaps it was a pure academic reply? Because reality always trumps theory.

> Perhaps it was a pure academic reply

Yes, exactly.

> 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

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.