1. 85
    1. 20

      I’d be interested to learn how they got organizational buy-in to fully adopt a <2 year old language. I presume there’s likely some de-risking from the fact it’s made and produced by the platform vendor, but even still it seems like asking for trouble by being an early adopter (especially as it was re-iterated that the business was heavily influenced by the outcome of this project).

      1. 21

        It’s remarkably easy for teams to fall into the trap of “chasing the shiny”, even with good oversight and experienced engineers.

        I’m reminded of Gunpei Yokoi, Nintendo, and “lateral thinking with withered technology”:

        Essentially, Lateral Thinking with Withered Technology boils down to using mature technology in novel or radical applications. At the time of the invention of the Game & Watch, LCD display technology was everywhere. It was a well-understood process and because prices for individual components had dropped so much, integrating an LCD into a product was relatively inexpensive. Some people at Nintendo wanted to use fancier technology in the Game & Watch, technology that would have reduced battery life and raised costs, but Yokoi insisted that affordability was key and that the player cared more about fun gameplay over flashy technology


        1. 8

          In the case of programming it’s even more applicable since you can do more or less everything in Objective-C that you could do in Swift – just in different ways. It’s not like writing a program in Swift enabled new features that would be impossible to implement in Objective-C.

          This is different from LCD screens vs. fancier screens, where the fancier screens at least offer features that would be impossible on LCD screens, and it’s essentially a trade-off choice of “fanciness vs. costs and battery life”.

        2. 6

          That’s a great story.

          Another expression of this idea is innovation tokens. Your organization or team or project is allocated 1 or 2 or maximum 3 innovation tokens, which you have to use to pay for any novel technology choices you make. Using a brand new language would certainly cost 1 or 2 innovation tokens.

      2. 5

        For me this is the craziest part. I can see re-writing a single service in it or a PoC app to see how the dev tools are and how debugging it is etc. ….but going full-blown “we’re rewriting everything” is kind of insane!

    2. 9

      I would love to read a thread where someone explains why the app is so gigantic to begin with. It does not do a whole lot, so what is all this code doing?

      1. 19

        The author explains this in a reply here: https://mobile.twitter.com/StanTwinB/status/1337055778256130062

        The app looks simple from the user perspective. But on the global scale the business rules are insanely complicated. Every region has custom rules/regulations. Different products have different workflows. Some regions have cash payments. Every airport has different pick rules…

        See also the people replying to that discussion, they talk about how unreliable networking means they can’t do this stuff on the backend.

        1. 3

          they talk about how unreliable networking means they can’t do this stuff on the backend.

          Uber is infamous for having over 9000 microservices. They even had to “re-invent” distributed tracing, because NIH syndrome or something (Jaeger, now open-tracing). I really, really doubt they do it all on the client. They have to make sure the transaction is captured anyway and without network, how can you even inform drivers?

          1. 4

            Presumably they verify everything on the backend anyway because you can’t trust the client. My guess is that the network is reliable enough to submit a new trip, but not reliable enough to make every aspect of the UI call out to the backend. Imagine opening the app, waiting for it to locate you, then waiting again while the app calls out to the network to assess regulations for where you are. Same thing picking a destination. That latency adds up, especially perceptually.

      2. 12

        Yeah that’s the part that gets me, it’s like the dril tweets about refusing to spend less on candles. Just write less code! Don’t make your app the Homer Simpson car! What is the 1mb/week of new shit your app does good for anyways? It’s easy, just play Doom instead of typing in Xcode.

        I don’t have hypergrowth mentality though, I guess that’s why Uber rakes in all the profits.

        1. 6

          I guess that’s why Uber rakes in all the venture capital dollars to subsidize their product

          Fixed it for ya ;-)

        2. 1

          I would love to see Chuck Moore’s (RIP) take on 1 MB/week. He might just have a seizure.

          1. 5

            Thankfully, Chuck Moore is alive.

            1. 6

              Ah, man, well I have egg on my face. I feel quite silly. I’m going to slink into a corner somewhere.

      3. 5

        I recall a few years ago someone disassembled Facebook’s (I think) Android app and found it had some stupendously huge number of classes in it. Which led to a joke about “I guess that’s why their interviews make you implement binary trees and everything else from scratch, every developer there is required to build their own personal implementation every time they work on something”.

        Which is cynical, but probably not too far off the mark – large organizations tend to be terrible at standardizing on a single implementation of certain things, and instead every department/team/project builds their own that’s done just the way they want it, and when the end product is a single executable, you can see it in the size.

        1. 4

          I wonder if there could also be some exponential copy-paste going on, where instead of refactoring some existing module to be more general so it satisfies your need, you copy-paste the files and change the bits you need. Then somebody else comes along and does the same to the package that contains both your changed copy and the original package, so there are now 4 copies of that code. The cancerous death of poorly managed software projects.

          1. 2

            Scary… and probably very true.

    3. 33

      Great story, but why do so many people think it’s a good idea to write entire articles on Twitter? It’s even worse than publishing them on Medium, and that says a lot!

      1. 16

        Because that’s where the readers are. (Same reason Willie Sutton robbed banks.)

        I hate Twitter so, so much, and that’s one of the reasons. Even with the new supersize 280-char limit, it’s still such a choked, impoverished writing medium. Constraints can be good, but when they’re a choice, not when you’re forced into the constraint because it’s baked into the only platform that meets your needs.

        1. 12

          Writing is also pretty easy too for them. Each thought can be composed piecemeal and worked into a larger thread. It’s compatible with shorter attention spans for /writing/.

          Maintaining a blog is ceremony/effort if you’re not actively committed to it. The next lowest effort/easiest distribution is Medium, and we all know what we think of that.

          Constraints can be good, but when they’re a choice, not when you’re forced into the constraint because it’s baked into the only platform that meets your needs.

          Many constraints were because of forced limitations. That was the post of many of them.

          1. 3

            Yeah, you’re right about forced constraints. I guess it’s that any one constraint is good for some things but bad for others. Twitter has been a great boon to standup comedians and haiku poets, I’m sure.

            WordPress.com is pretty low-effort; it has issues but not so much as Medium. If it or something like it were more popular, people could write their tweet-threads there. Unless, as you say, they’re ADD enough that they’d get blank-page fright and never write anything.

            (I’m trying hard not to start bemoaning the demise of LiveJournal again. It coulda been a contendah…)

            1. 12

              Another thing that might be interesting is that people can reply to the indivual atomic units of thought easily too. It’s really more like structured/permament IRC than it is a blog.

              And yes, from the people who DO write mega tweet storms tell me, blank page fright is huge.

            2. 9

              WordPress.com is pretty low-effort; it has issues but not so much as Medium. If it or something like it were more popular, people could write their tweet-threads there. Unless, as you say, they’re ADD enough that they’d get blank-page fright and never write anything.

              I don’t know; I suspect it’s more of a barrier-of-entry thing. Twitter is kind of ephemeral and “write and forget”, whereas writing on your personal WordPress site takes more effort, as it’s less ephemeral.

              The same with comments on e.g. Lobsters: I usually just write them, read over them a little bit, and post. Whereas on my website I tend to take a lot longer to write more or less the same stuff. If something’s on my website, I want to make sure it’s reasonably accurate, comprehensive, and written as well as I can. Usually this entire process takes up quite a lot of time for me. For some Lobster comment or Twitter remark, it’s a bit different.

              It’s really difficult to put my feelings on this in words; so I hope this makes sense 😅 But publishing something on my (or any) website just comes with a lot higher barrier of entry for me, and I’m probably not so special that I’m the only one.

              @calvin mentioned “blank page fright”; which is more or less the same thing in a way, just expressed different, I think(?)

              At any rate, Twitter is hardly my favourite platform for these kind of things, but if the choice is between “it would never be published at all” and “it’s published on a platform I don’t like”, then the second option is clearly the better one.

        2. 4

          Because that’s where the readers are.

          Then Tweet a link.

          Might be a great story, but I’m not reading it in 20 parts on Twitter.

          1. 4

            And many people will not click a link.

          2. 2

            Plus clearly many, many people are. Writers go where readers are, and though you may not like reading things in this way on Twitter, there are enough people who do to make a market for this sort of material.

        3. 1

          The choked, impoverished writing medium is what makes it so much fun!

      2. 11

        For some people this is the answer.

        It’s easier to just write a set of tweets. When you publish a wall of text you gotta format it, you feel like proof-reading, etc.

        A tweetstorm is like…. whatever, just get it out there. Hell, type it in drafts and it’ll post the tweetstorm for you.

        This is like instagram stories: A way to reduce the barrier to sharing content. And some stuff is low effort, but some stuff is just high quality. It’s also, like other said, a way to share to people who are following you.

        1. 2

          you gotta format it, you feel like proof-reading, etc.

          I think there might be a reason why people do this.

          Ironically, this ‘article’ is more of a ‘wall of text’ than most blog posts, in that it’s just a collection of ‘text bricks’ stacked on top of each other, with no real structure. As a result, it’s practically unreadable.

        2. -1

          Thanks for pointing this tweet out, but I don’t buy that for a minute. If you have so much ADHD that you can’t do it any other way, you could still tweet your story and then copy-paste the sentences into a blog post. No one could be that debilitated by ADHD that he wouldn’t be able to do this basic thing.

          Also, a blog post is written once and read many times (ideally). It’s disrespectful to your readers to force this horrible format on them. If I were in this situation, I’d ask a friend to help me format a “tweetstorm” into a nice blog article. Even long texts wouldn’t take that much time.

          1. 11

            Uh, hey maybe don’t make comments that people with ADHD could do something when the evidence and statements of actual people with ADHD say they can’t. One of the key experiences of ADHD is executive dysfunction, meaning mental challenges around planning, problem-solving, organization, and time management. People with executive dysfunction (which isn’t solely experienced by people with ADHD) describe it in a number of ways that can be illuminating:

            Mental differences like this aren’t something you push through. Maybe sometimes you can (people with disabilities often describe experiencing fluidity in the severity of their challenges), but maybe sometimes you can’t. The experience of others demanding that they push through, or judging them for failing to push through, is one of the main challenges faced by disabled people. If you spend time listening to disability advocates, you’ll hear them talk about how they’re not disabled because something is wrong with them, they’re disabled because of limitations in the systems we all operate within, and the expectations and demands of our collective culture.

            So please, don’t toss out comments about how disabled people ought to function. They’re doing their best, and the expectations you’re putting out there are a core part of the challenges they face.

            1. 1

              Did you even read my comment before pasting your pasta here? Even disabled people ought to be able to ask for help, and in this case, I see no reason why someone with ADHD and executive dysfunction shouldn’t be able to ask someone for help in this regard.

              1. 6

                I did read your comment.

                I’m also flattered you think my post is a copypasta.

                Seems unlikely you’ll be convinced, but to hammer it home: saying “disabled people ought to be able” or even “disabled people ought,” is the problem. If you do not have executive dysfunction, you do not know what it’s like to live with, and should defer to people who do live with it when they talk about what is reasonably doable for them.

                1. 3

                  I’m also flattered you think my post is a copypasta.

                  Not taking sides here, but just wanna say, that is the best kind of rhetoric.

              2. 6

                Let me describe how I post on Lobsters. First, I think about what I want to post. Then, usually I don’t post it.

                If I do decide to post, then I commit myself to keeping a browser tab open for about half an hour while I write my post. I try to get my evidence lined up, opening additional tabs with each consideratum so that I won’t forget what I’m writing about.

                Paragraphs are usually written out of order. Entire sentences are written, rewritten, discarded, and written again. Phrases become semantically satiated and read wrong in my mind. I worry that I have used too many words. I worry that I haven’t used enough.

                I constantly feel disconnected from myself and also from my audience. I don’t understand how to relate to people, or how to ensure that my meanings are preserved. In fact, I am used to being horribly and hilariously misinterpreted.

                The help that I would ask from you is for you to reread the parent post and reconsider your stance. There is no universal way in which humans are supposed to interact with computers.

                Alternatively, take a programmer’s point of view: A module is not merely a collection of code snippets, and it is disingenuous to suggest that folks can simply collate code snippets into meaningful modules.

              3. [Comment removed by author]

          2. 7

            Also, a blog post is written once and read many times (ideally). It’s disrespectful to your readers to force this horrible format on them. If I were in this situation, I’d ask a friend to help me format a “tweetstorm” into a nice blog article. Even long texts wouldn’t take that much time.

            But you’re not in this situation.

          3. 4

            You may not realise it, but this is what your post looks like from the outside:

            • You’re mistaking your personal dislike for a universal dislike.
            • You’re laying your personal preferences on other people as responsibilities.
            • You’re presuming you know what other people can or can’t do, or how they should or shouldn’t spend their energy and friend-favours.

            That is not how you reason your way to correct conclusions, and it is not how you win friends and influence people.

      3. 8

        No constraints, no glory!

        But really the real reason is that I put weeks of research and editing into my blog posts, in some case months… while I can hammer a tweetstorm out in five minutes.

      4. 4

        As much as I hate Twitter ‘articles’, I think they’re actually better than Medium articles, which is… impressive.

      5. 1

        Agreed. This would be a pretty lengthy blog post, and this format is just awful. Really good war story though.

    4. 5

      It seems like they tried to coordinate the size reduction from the top, which is hard for many reasons, not least that size problems – like performance problems – can be characterised as death by a thousand cuts.

      I’ve read about an alternative approach to deal with that problem, which is to find out how much an oversize app costs (which they did) and then translate that down to an optimal price point of $/kB.

      Let every team sell size reductions on their little slice of functionality at that price, and you have everyone incentivised to reduce size in whichever way they reasonably can without accidentally incurring greater costs than just shipping the oversize application would result in. The localised decision making will make much better choices on what to optimise than any global control could. Teams that build large functionality will have better opportunities to reduce their size by a fraction than teams building tiny features. Just as it should be!

    5. 4

      For me the biggest surprise is the director’s response “If we don’t get this right we might as well pack our bags” and then they doubled down. I get the whole “too big to fail” mentality, but it seems like it would have been better to just go back to the objc based app and/or just port the app back to objc. Curious what the net loss would have been if they had switched back vs starting an eternal fight with a very green compiler.

      The amount of burnout this single rewrite caused is probably incomprehensible!

      (side note: I’m glad I came across the threaded site before trying to read this on twitter, awful)

    6. 3

      We started decompling our object files and going over the symbols line by line to identify why our Swift code size was so much larger. We deleted unused features. Tyler had to rewrite the watchOS app back into objc. - https://twitter.com/StanTwinB/status/1336935373696462848

      Deleting features because your code size is too big seems like an antiquated problem and I’m surprised to see a problem like this appear in a modern language that is only a few years old. I don’t know enough about iOS development to tell if Uber was doing anything wrong to cause this. Is this a Swift problem?

      1. 4

        If I had to guess: they probably have client-side A/B tests (or other such things) that are controlled by a server-side config. This means the implementation for both sides of the A/B test are included in the binary.

        If they decided to end the A/B test and roll one side out to 100% of users… they don’t strictly need to get rid of the code for the other side. It’s a lower-priority cleanup task, the kind that can easily fall by the wayside, at least until something like this makes it more urgent.

        But because it’s controlled by a server-side config, the compiler and toolchain can’t actually tell whether that code is unused, because the only thing controlling it is something like

        if (serverSideConfig.useNewThing) {
        } else {

        As far as the compiler is concerned, doOldThing() is still referenced and “used” even if the server-side always sets useNewThing for everyone.

    7. 6

      I wish I was one of those people who worked at FAANG for a year straight out of college, just to have the padding on my resume, so I don’t have to think about it anymore. Sucks to think my career would probably have been a little better if I did that. Now it’s seems too late, it seems even more pointless (especially during COVID) to work at one of these companies, unless all you care about is money. Working for a FAANG seems totally pointless if you’re mid-career, they have weird problems that are always self-inflicted and the lessons learned are typically so far removed from anything you can practically use if you start your own company.

    8. 4

      I’d say most fault here is with the Swift compiler team.

      I’m not surprised that people had to pay for the technical debt caused by Swift adding features all the time, instead of making sure that the “basics” work.

      When do people learn that adding features doesn’t improve a language?

      1. 11

        I don’t know any evidence that adding features was at the expense of speeding up compilation or linking. The two seem to involve different specialties; I’m guessing the gurus who know about the innards of the type system and optimizer are not the same people working on front-end stuff like key-paths.

        Rust has similar issues, probably for similar reasons since both have similar type systems. I don’t know if anyone has written any 100MB Rust programs yet, or how long they took to build if they did.

        I try not to take pot-shots at software I don’t know the internals of, but I’m suspicious that some of this might be Uber’s fault, overengineering their app. Do you really need 100MB of code for an app that lets you book taxis, when all the really heavy lifting is being done on the server?

        1. 14

          It’s funny that this story is entirely written on Twitter, a platform whose iOS app (which solely lets you scroll through 140~280 character messages and post same messages) weighs in at 124,5 MB.

          It seems that the bigger the company, the bigger the software, as also demonstrated by https://lobste.rs/s/c8xwgl/why_is_google_cloud_ui_so_slow

          1. 9

            A few years ago someone tore apart some of the worst iOS size offenders to figure out why they’re so enormous. Part of the problem is dependency hell induced by CocoaPods and Carthage, where the app uses a bunch of open source frameworks that depend on other frameworks, and they’re all separate dylibs so they can’t be dead-stripped. And there were asset horror stories like thousands of uncompressed PNGs, and even gigantic video files baked in just so the app can show you a movie the first time it launches.

          2. 3

            I checked the apps on my phone, and most of them are really huge:

            Revolut        316M
            Grab           280M
            Gojek          215M
            Google Maps    180M
            Signal         120M
            Spotify        120M
            Termius        111M
            WhatsApp       75M
            MyTelekomSel   73M
            Telegram       72M
            CouchSurfing   61M
            VLC            52M
            FTPManager     50M
            FastMail       10M

            Grab and Gojek are more or less the Asian variants of Uber, and they’re both above 200M. It all adds up to 1.7G, and I don’t have all that many apps installed.

            No idea why Revolut needs to be a whopping 316M 🤔

            1. 4

              I find it really telling that the size of things installed from the Play Store seems to be measured in hundreds of MiBs, the size of things installed from F-Droid is often under 1 MiB and pretty much always under 10 MiB, yet at least as useful. Most of the bloat seems to come from things like the Facebook SDK and similar ad-related things.

            2. 3

              I believe FastMail is a small wrapper around a web page. If you aren’t connected to the internet, the app doesn’t even load. So it’s great that it’s a tiny app, but that design would be a hard sell for an app like Uber where they want it to load when the cell network isn’t super reliable. Plus it’s annoying I can’t read my email when I’m offline.

              1. 1

                Yes, correct. It’s actually not a very good mobile app, but I use it because I’m too lazy to set up anything else, and I use my desktop in 99% of the cases anyway.

        2. 3

          The two seem to involve different specialties; I’m guessing the gurus who know about the innards of the type system and optimizer are not the same people working on front-end stuff like key-paths.

          It’s called “taking responsibility”.

          If “front-end” people can’t manage to keep the UI from hanging when leveraging the type system the “type system people” built, that’s the responsibility of the “type system people”.

          Apple has enough money for this – this is not Scala, where the compiler team throws some binary over the fence with a version announcement regardless of whether the version has any kind of IDE support or documentation.

          1. 4

            I think you missed my point, which was that adding features doesn’t necessarily come at the expense of making the optimizer faster, because engineers aren’t commodity resources that management can choose to throw at one or the other task. There’s probably a very limited global supply of people who can do that kind of work on a compiler, and I’m sure the ones at Apple have been working as hard as they can, because it’s their baby.

            1. 3

              The point is that adding language features is the most efficient way to destabilize a language across the whole compile → runtime → standard library → tooling → IDE → third-party library stack.

              So yes, adding languages comes at the expense of improving all other parts of the language, as those who “propose” language additions are rarely the people who have to deal with the fallout.

              the ones at Apple have been working as hard as they can, because it’s their baby

              I think the way the UI library came to be tells a different story.

      2. 10

        Not all languages are born perfect, like B was. Some say that the added features of C are valuable, but I would rather that K & R made the “basics” work before embarking on a new language. What will we have next year; “D”?

        1. 5

          Agreed! Imagine how much misery that would have saved us.

          I think it’s highly embarrassing for this profession that “program crashes/hangs/malfunctions” is such a common occurrence that 5 billion non-developers are not only acutely aware of it, but consider it an unsurprising state of things.

          It’s as if large parts of humankind were familiar with civil engineering jargon because collapsing bridges were a daily occurrence.

    9. 1

      All those engineering struggles to fit in 100mb, which Apple later increased - not worth it =)

      1. 2

        It allowed them to continue iterating and working as usual for most teams while limit was not increased, otherwise they would hit it pretty soon, as far as I did understand it.

    10. 0

      Sidenote: if your story spans more than 5 tweets, throw it in a paste or a blog.

      1. 1

        I dunno. Dave Winer, the “grandfather of blogging” has permalinks to each (short) paragraph on his entries, and you can retweet them directly. Using Twitter just bypasses all that and you don’t need to use Userland ;)

        1. 2

          That thing you linked doesn’t appear to be an article or an attempt to tell a story, though. It’s just a collection of apparently unrelated thoughts that happen to be formatted as though they were paragraphs in an article.

          1. 1

            Or, you know, tweets…

            Anyway, it’s consistent in posts that have a general theme: http://scripting.com/2020/12/09/181925.html?title=appleZealotsSuck

            I’m old enough to remember when permalinks to each paragraph was the hot new thing (maybe 15 years ago?). They were called “purple hashes” or something ? The “Golden Age” of blogging was weird.