Announcement

Collapse
No announcement yet.

Google Reaffirms Commitment To Kotlin Programming Language For Android

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by starshipeleven View Post
    I think that's hardly a language issue.
    This will be fixed in a few years. As Java gains AoT compilation capability, I'm pretty sure Google will start compiling apps on the server side and only push the resulting binaries to your phone.

    In the grand scheme of things, dependencies are the plague of everything that's not compiled down to executable code, be it Java, Kotlin, C#, Python or JavaScript (*cough*node*cough*). Keep dependencies fine-grained, developers will complain there's too many of them; lump dependencies together, developers will complain about bloat. This used to be minor annoyance, but in the age of the smartphone and the microservices, it starts to weigh against these languages. (Don't get me wrong, they're all still viable, just a tad harder to sell in said contexts.)

    Comment


    • #12
      Originally posted by bug77 View Post

      This will be fixed in a few years. As Java gains AoT compilation capability, I'm pretty sure Google will start compiling apps on the server side and only push the resulting binaries to your phone.
      It's been a thing for some time.

      Comment


      • #13
        Originally posted by bug77 View Post

        Yes, Kotlin fixes many Java shortcomings. But man, is Kotlin code an eye sore to read... I mean, if the last argument of a method is a lambda expression, you can write it outside of the function call's parantheses. Why?
        Yeah, and there are other weird things, like how the constructor for a class is defined in the class declaration or something weird like that.

        Comment


        • #14
          Originally posted by bug77 View Post

          This will be fixed in a few years. As Java gains AoT compilation capability, I'm pretty sure Google will start compiling apps on the server side and only push the resulting binaries to your phone.

          In the grand scheme of things, dependencies are the plague of everything that's not compiled down to executable code, be it Java, Kotlin, C#, Python or JavaScript (*cough*node*cough*).
          Why does it feel like this argument leads to the next problem static- vs dynamic-executables vs light interpreters (wasm/bytecode)?

          Keep dependencies fine-grained, developers will complain there's too many of them; lump dependencies together, developers will complain about bloat. This used to be minor annoyance, but in the age of the smartphone and the microservices, it starts to weigh against these languages. (Don't get me wrong, they're all still viable, just a tad harder to sell in said contexts.)
          Things like protobuf helps to extend the life of bloated languages allowing for quick reuse of existing code/libraries in massive ecosystems. I agree with your statement that it is and hopefully will continue to be harder to sell in microservices and other environments that actually create incentive to write good code.

          That said, people don't understand the advantages of bloated applications (increased productivity while maintaining backwards compatibility). Imagine being able to run your favorite legacy GTK+ or QT based application without having any build or runtime issues.. I know I'd have crazy old beryl or superkarambas themes all over my screen. Most apps isn't expected to last very long since we have lost the ability to plan for the future and break backwards compatibility to reduce bloat (amongst other things). Simply base all our short term plans on market reaction and if it works out try to make your bloated framework or language last as long as it can possibly can. In this regard to bloated apps are the best fit for the market demands.

          In all honesty related to the reason above I prefer robust native apps over feature rich, modern UX. Like discord vs IRC. I'm simply stating that I'm the minority... by far.

          Comment


          • #15
            Originally posted by tildearrow View Post
            Kotlin = 7 More Megabytes per App

            The Simple Apps are a big example of this bloat.
            Supposedly simple but actually bloated.
            Remember back before "Material Design" when Android apps were often only a couple hundred kilobytes?

            Comment


            • #16
              Originally posted by bug77
              This will be fixed in a few years. As Java gains AoT compilation capability, I'm pretty sure Google will start compiling apps on the server side and only push the resulting binaries to your phone.
              They did that five years ago when they replaced Dalvik with ART. The compilation happens on app installation.

              Originally posted by bug77
              In the grand scheme of things, dependencies are the plague of everything that's not compiled down to executable code, be it Java, Kotlin, C#, Python or JavaScript (*cough*node*cough*).
              Not in JavaScript. Dependencies get bundled into one big JS file, as has been tradition since the beginning.

              Comment


              • #17
                Originally posted by uid313
                Kotlin on Android is quite nice, partly due because Java is so horrible. Especially the outdated Java that is available on Android. No getter/setters, lambdas, type interference, etc.
                The Android SDK supports Java 8 now. I don’t see the point of Kotlin really. Modern Java is nicer to look at, it just needs support for records to get approved to help eliminate some more boilerplate and it’ll be in a good place.

                Comment


                • #18
                  Originally posted by tildearrow View Post
                  Kotlin = 7 More Megabytes per App

                  The Simple Apps are a big example of this bloat.
                  Supposedly simple but actually bloated.
                  That's probably because those idiots refuse to use code and resource shrinkers.

                  I worked on a messaging app, and we were at 21 MB, shrink it to 16 MB by removing some unused resources and converting some PNGs to WebP. And that was without code shrinking. Of course, we hadn't tried to use Kotlin yet on that app.

                  Comment


                  • #19
                    Originally posted by starshipeleven View Post

                    Not seeing why Kotlin should be worse than Java. It basically is still Java.

                    Apps on android have always been bloated as hell.
                    Only some apps are bloated, because they refuse to use code and resource shrinkers. There's also APK splits, that can reduce the APK size even further, plus Google automatically attempts to compress APKs and only transfer changed files.

                    Facebook is a prime example of bloated app that refuses to use standard Android tools that would heavily reduce it's size.

                    Comment


                    • #20
                      Originally posted by bug77 View Post

                      This will be fixed in a few years. As Java gains AoT compilation capability, I'm pretty sure Google will start compiling apps on the server side and only push the resulting binaries to your phone.
                      Android's had AoT compilation since Android 5.0 ...........

                      Comment

                      Working...
                      X