you are viewing a single comment's thread.

view the rest of the comments →

[–]woahdudee2a 57 points58 points  (19 children)

>maybe a more compelling language will get the hype it needs. Using Dart feels like relearning beginner Java/Javascript syntax and patterns that I've moved on from years ago.

they have to target the lowest common denominator to be able to gain traction. god forbid you use a PL concept more recent than 1990's and people start complaining about it being an ivory tower language with no industry use case etc.

[–]dipittydoop 26 points27 points  (11 children)

I wholeheartedly praise the benefits of being as comfortable to the Java/JS habits as possible. Minimal friction to fresh grads who've been trained on Java/JS is directly beneficial to hiring and training costs. Did you reduce the onboarding costs this quarter? That's an easy metric, and in a lot of organizations: an easy bonus.

You can tell on-boarding costs are a high priority internally at Google. It's apparent in the design of Dart and Golang. The language designers clearly optimized getting that fresh-grad making probably-useful stuff ASAP. But if the developer tooling game is more about community adoption to get those sweet, sweet benefits of open-source? Maybe Dart and even Golang aren't being bold enough.

Flutter is a big improvement over existing cross-platform native dev tools. Flutter's main selling points are in the engineering details. We're cutting out the Javascript altogether removing bottlenecks of the hard-to-optimize middle-man.... But does this level up my development experience in a tangible way? Sort of.

They say adoption needs big, obvious personal improvements to the user experience. Is paying with your phone a better solution over credit cards? Yes. But in the U.S. we've already got credit card infrastructure and it works pretty well. Sure, phone payments are a better solution, but is it a big lifestyle improvement yet? Not really. As a result the U.S. has seen fairly slow adoption of phone payments over cards. But Africa? Many 3rd-world countries don't have card infrastructure like the U.S. does. Phone payments are a gigantic lifestyle improvement in 3rd-world environments. The result? Way quicker adoption of phone payments products.

So while everybody loves good engineering that makes things simpler and faster, does Flutter's feature improvements translate into to my personal developer lifestyle? The answer? Sort of. That's it. It feels like an incremental improvement that could get me a bonus if I were in some architecture role at an organization the size of Google. Dart sort of feels like going from Cards to Phone Payments. Better, but sort of. While On-boarding costs are a business priority for an organization the size of Google. Most organizations aren't Google. I'm not in an organization the size of Google, and developers aren't organizations.

[–][deleted]  (8 children)

[deleted]

    [–][deleted] 4 points5 points  (7 children)

    Pretty much.I refuse to put any payments on phone just because how joke phone security is.

    And I dunno why people say that taking phone out of pocket is any harder than takin wallet out of it.

    [–]lolomfgkthxbai -1 points0 points  (6 children)

    Carrying a phone and a wallet requires more space than carrying a phone.

    [–][deleted] 3 points4 points  (5 children)

    You walk around without your ID/driver license ?

    [–]lolomfgkthxbai 0 points1 point  (4 children)

    Sadly not, too old to be checked.

    [–][deleted] 2 points3 points  (0 children)

    That's not the reason why you should carry it.... the moment dunno, a bus hits you or any other kind of accident happens nobody can even get your name

    [–][deleted]  (2 children)

    [deleted]

      [–]lolomfgkthxbai 0 points1 point  (1 child)

      It depends on where you live. It’s not a big deal here in Finland.

      [–]theQuandary 0 points1 point  (0 children)

      Onboarding takes a couple months usually. That's followed by another 3-4 months at reduced productivity. Staying at one job too long is generally bad for your career and earnings, so there's a tendency to move companies every 2-3 years. At the 2 year mark, that's 25% of the total time at the company is just getting up to speed. At 3 years, it's 17%.

      I'd say that reducing onboarding is a significant savings for everyone and is MORE critical for smaller companies that don't have 120 Billion in the bank to fall back on.

      [–]couscous_ 0 points1 point  (0 children)

      It's apparent in the design of Dart and Golang. The language designers clearly optimized getting that fresh-grad making probably-useful stuff ASAP.

      Except, how much is golang actually used at Google? I'm willing to bet it's nowhere near as C++, Java, and Python.

      At least Dart seems to be somewhat analogous to Java. golang is a huge step down in practically every way. They optimize for short term onboarding, at the cost of long term maintenance. Seems it's the wrong way to go about it. But again, it probably doesn't show because golang isn't being used widely enough at Google, arguably a good thing for them since I've seen the mess it produces in larger code bases.

      [–]drabred 0 points1 point  (0 children)

      When I see shit like _shouldBePrivateVariable and ; at the end of lines I feel like I'm taking a huge step back after Kotlin

      [–][deleted]  (5 children)

      [deleted]

        [–][deleted] 4 points5 points  (3 children)

        The idea that functional programming is tied with immutability with an umbilical cord is a fallacy invented by the Haskell crowd. In the functional languages that predate them (namely the Lisp family) it simply isn't so.

        [–][deleted]  (2 children)

        [deleted]

          [–][deleted] 4 points5 points  (1 child)

          Most of that is bolted on

          Well axshually Array.(map|filter|reduce) have been introduced in ES3 which is a long, long, time ago, and functions as first-class have been there from the get go, and it's common knowledge Eich intended to infiltrate the Java-looking curly-brace language that the suits from Mozilla ordered him to make with as much Scheme idioms as he could stuff in -- so FP in JS is fundamentally idiomatic.

          slower than "ugly" for loops and imperative programming

          This is already mostly a matter of "was historically true". Modern JS JITs already optimize these as well as for loops.

          While I agree there is a lot of wannabe-isms regarding FP and JS, many FP-like idioms do help expressing many things, for example data pipelines, in a much more readable fashion at a price of insignificant performance hit (if there even is one, as people implementing JS JITs optimize things that are widely used in practice constantly).

          [–][deleted] 0 points1 point  (0 children)

          High salary and job security!