7 ms·

Dart doesn't have the adoption yet and has a different plan when it comes to mobile ( https://github.com/flutter/flutter https://github.com/flutter/flutter ).

• dom96 10y ago
  Why do you consider Go unsuitable for UI development?
  • patates 10y ago
    You can't have generic functions that can wrap data so you end up passing concrete models or interfaces to views - no generic view-models for you. The inflexibility of the type system isn't a big deal when you are working on network applications or tools, but causes serious duplication when you do anything that passes around concepts internally.
    • bsaul 10y ago
      i don't think generic is relevant to GUI. objective c didn't have generics, and i don't think it mattered in any way when they built cocoa. now generics is a problem of its own when working with data and algorithms, but they managed to get along with it in the backend so far, so...
      • dagi3d 10y ago
        obviously it is doable, but that does not mean there aren't better solutions today.
  • dguaraglia 10y ago
    UI development is one of the areas where object orientation really helps encapsulate the code in smaller chunks that are easy to map mentally to the graphical representation. I'm not sure Go's interfaces are as powerful of an abstraction. Mind you, there might be an opportunity there for developing a different kind of UI paradigm where interface elements don't map to objects and actions are the main driver of screen updates. Anyone has any ideas of such a paradigm?
    • mywittyname 10y ago
      > UI development is one of the areas where object orientation really helps encapsulate the code in smaller chunks that are easy to map mentally to the graphical representation. I'm not sure Go's interfaces are as powerful of an abstraction. See, I feel the opposite. I think UI programming is the worst application of OO-design because the data and actions of a UI are inherently decoupled. You have have n data structures and m events that can be fired on a page and not every event is associated with every data structure. However, importantly, any event can be associated with any number of data structures, some of which may not even be conceived at the time of run/execution. OOP-doesn't work well in situations where you have functions that can operate on lots of disparate data-types. When you apply OO principals to UI work, you end forcing a coupling that artificially limits what you can do with the data, requiring an increasing the levels of abstraction in order to provide baseline functionality. For example, when you have a button, it's an object, then if you want to apply a listener to it, you need to create a method on Button that accepts a listener. But to ensure that the method can actually interact with the passed object, you need to create an interface then ensure that every potential listener implements it. There is an entire world of classes that could be bound to the listener as-is, but those existing classes don't implement the correct interface since they didn't know of its existence. So the OOP-land solution is to write wrappers for every class you'd like to attach as a listener to the button. In a functional world, you can attach any function that takes the appropriate number of arguments and be on your merry way. If the function doesn't fit that mold for whatever reason, you can cleanly wrap it in an anonymous function right where you're attaching it as a listener.
      • 10y ago
  • PeCaN 10y ago
    Go is unsuitable for programming, and UI development typically involves some programming.
  • bsaul 10y ago
    well, objects are great for mutable state encapsulation. a view , a scrollbar, a listview, etc are all highly mutable ( 60 times a second) and you can very well organize all of them in a 2 or 3 level hierarchy of inheriting classes ( a listview is a kind of view). but, you may probably as well organize them as nested property sets each of which containing the other ( like a listview contains a view part and a list part). Not sure the result will be as elegant, but i'm curious to look at the result.
• geodel 10y ago
  Java's value is not some inherent superiority of language for mobile development, it is about throwing (100s of) millions of dollars and 100s of engineers to make it work. And I think it remains true for C# also. Unless someone sinks 100s of millions on C# too it seems non-starter to me. By the way Microsoft has already tried mobile ecosystem with .net/C# that did not work out very well.
  • cwbrandsma 10y ago
    I wouldn't say that was because of .net/C#. Nor did the iPhone succeed because of ObjectiveC or Android because of Java.
  • serge2k 10y ago
    The transition from Java to C# is pretty easy and pleasant as C# is similar but better.
    • bottled_poe 10y ago
      > C# is similar but better Oh really? Why?
      • naasking 10y ago
        Better operators, properties, lambdas, a standard library that exploits lambdas pervasively, type inference, simple generators and async/await. Java has anonymous classes and static interface members as the only real advantages over C#.
        • invalidname 10y ago
          I work a lot with Java and C# and you just described the reasons I prefer Java (which FYI has lambdas today). The async/await API's and their rigid nature was torture and the language was overly loose as if users asked for everything and got it... The reason I left C++ for Java 20 years ago is the things it removed and discarded (e.g. operator overloading) C# to me is a step back in the direction of "everything but the kitchen sink".
• mr_overalls 10y ago
  I always hear of the JVM's legendary capabilities, the result of so many million engineer-hours baked in. What would be required to bring the CLR into parity with it?
  • fetbaffe 10y ago
    I don't know, but remember that Android does not run the JVM, it runs the now deprecated Dalvik or the more modern ART, both Google in house projects. None of them have all those million engineer hours baked in, not even close. My guess is that the CLR have more man hours spent on than both those two implementations combined.
    • sandGorgon 10y ago
      This is no longer true. http://arstechnica.com/tech-policy/2016/01/android-n-switches-to-openjdk-google-tells-oracle-it-is-protected-by-the-gpl/ http://arstechnica.com/tech-policy/2016/01/android-n-switche...
      • needusername 10y ago
        It is my understanding Android simply uses the class library of OpenJDK. Android will continue to used the ART VM instead of the HotSpot VM.
        • sandGorgon 10y ago
          True, but I personally believe this is the first step to adoption. The whole issue was around licensing..not because the Hotspot vm had something fundamentally missing (zygote and MVM notwithstanding)
          • needusername 10y ago
            That's hard to know and I have no insider knowledge. From the outside it seems like a lot of work. Firstly HotStop is not optimized for fast startup, small footprint or short GC pauses. There is talk about merging the Java ME VMs but such things usually take years. Secondly Google built many proprietary extensions, eg DEX. I'm not sure that ART can even execute Java bytecodes.
• bitmapbrother 10y ago
  Dart is a first class citizen in their Fuchsia OS. I wouldn't be surprised to see Fuchsia replace Linux one day on Android/Andromeda.
  • pjmlp 10y ago
    I might be proven wrong, but I doubt it is going anywhere. After Google own teams decided to go Typescript, the Dart team seems to keep searching for reasons to keep the project alive.
• Nullabillity 10y ago
  Just go use Kotlin instead. Much nicer than C#, runs on any JVM.
  • xorxornop 10y ago
    Much nicer? You mean "at parity"
    • zigzigzag 10y ago
      The syntax is a lot lighter and more modern than C#
  • m_fayer 10y ago
    In some ways it's nicely ahead of C#, but it's still missing some extremely desirable language features, namely async/await/yield.
    • jmfayard 10y ago
      kotlin 1.1 will have coroutines which cover generators/yield async/await stack-less continuations https://github.com/Kotlin/kotlin-coroutines/blob/master/kotlin-coroutines-informal.md https://github.com/Kotlin/kotlin-coroutines/blob/master/kotl...
  • runT1ME 10y ago
    Kotlin is missing monadic comprehension I'd say it's less powerful than C#.
• eva1984 10y ago
  Nothing can replace Java for android, unless it can also replace all the libraries current Android application is replying, which is the reason why I believe Google isn't going to switch off Java anytime soon.
  • int_19h 10y ago
    Xamarin already provides what is, in effect, a .NET compatibility layer on top of Android/Java. There's no reason why it can't be reversed, with Xamarin (or something along these lines) becoming the new native high-level API, and Java being a compat layer on top of that.
  • jmfayard 10y ago
    Using kotlin you get a much nicer language right now without any need of Google to switch off its Java API I doubt it will be officially acknowledged by Google, but hey they never acknowledge third party good things, and the official Android developers docs still tech us to do networking with HttpUrlConnection and threading with asynctask, we moved on to okhttp and retrofit and rxjava anyway
• RivieraKid 10y ago
  > I would say "it's simply superior in every imaginable metric other than cross-platform implementations of the compiler/VM" but that's just my opinion. Not by a big margin. Java 8 has lambda functions, which used to be the most painful aspect of the language for me.
  • int_19h 10y ago
    It does them. But it repeats the story with generics, where back-compat (in this case, lack of reified generics) requires hacks for acceptable performance. For example, in Java, you have this: http://docs.oracle.com/javase/8/docs/api/?java/util/function/package-summary.html http://docs.oracle.com/javase/8/docs/api/?java/util/function... Note all the permutations. This is necessary, because there's no way to define a generic interface that would have acceptable perf, due to boxing. So you end up defining separate types for things like int->int, int->int->int, long->long etc. And then if you need e.g. bool->int, well, that's just too bad. Whereas in C#, you just have Func<...> and Action<...>, and they work with all permutations of all primitive and user-defined types.
    • RivieraKid 10y ago
      That doesn't affect me in any way though, from my POV, lambdas work.
      • int_19h 10y ago
        It will affect you as soon as you start writing methods that accept lambdas as arguments.
    • kuschku 10y ago
      > This is necessary, because there's no way to define a generic interface that would have acceptable perf, due to boxing. Actually, that's going away with Java 9 (or 10). Luckily.
      • int_19h 10y ago