6 ms·

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

• 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
              • fingerlocks 2y ago
                I have made a lucrative career by porting fragile, slow, bug-ridden react-naive disasters to native code bases. There is a lot of demand for this from startups that took the cross-platform shortcut and the MVP became the product.
                • nwienert 2y ago
                  You can make a disaster in any framework. SwiftUI is a mess, for example, and slow. React Native took a while to mature, but with the right tooling you can ship amazing UX now. I don’t doubt there’s a ton of crap out there. But you’re wrong if you think you can’t make seriously great stuff with it. It’s matured quite a lot. And the React programming model is untouched, hot reloading and dev tools far ahead, and code share is worth it with something like Tamagui that actually optimizes to each platform. If I never had to touch an ObservableObject again that would be great.
      • seec 2y ago
        To be honest, the way they are damaging their brand/products/OS just to make a bit more money is enough to be pessimistic about Apple. But it's very true that the state of the language can be felt in their native apps, that tend to suck pretty bad recently. I still can't get over the nightmare that is the split up of iTunes; at least we knew that it was clunky because of old age, the new stuff is just bad.
    • astrange 2y ago
      I can think of a few others where you have to do that; most of them are the kind of languages whose fans say they're impossible to write bugs in.
      • paperplatter 2y ago
        If Rust is one, yeah I have to fight that compiler but it's because it's doing its job and not letting me do invalid things. Not because the compiler has some feature "not yet implemented" or has bugs.
        • paperplatter 2y ago
          Also, is anyone familiar with the weirdness with tuples in Swift? All I remember is they never worked the way I expected, and for some reason something in our code specifically worked for tuples up to size 5.
          • plorkyeran 2y ago
            Swift only got variadic generics fairly recently, and before that you couldn’t write code which was generic over tuple size. Instead you had to codegen versions for each size of tuple you needed to support.
            • paperplatter 2y ago
              I think that was it. There was also something about tuples inside of dictionaries that Swift 1 or 2's compiler segfaulted on.
      • cageface 2y ago
        Rust is hard but I've never had the compiler just throw up its hands and tell me it's up to me to figure out what's wrong.
        • astrange 2y ago