[patates]

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

I love Go, but it's not really a suitable language to do UI, or anything that deals with data models.

C#, however, is a perfect replacement for Java, most of the times. 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.

[bitmapbrother]

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]

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.

[mr_overalls]

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]

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]

This is no longer true.

http://arstechnica.com/tech-policy/2016/01/android-n-switche...

[needusername]

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]

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]

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.

[PeCaN]

Generally when referring to the JVM's performance people are talking about IBM J9, Azul Zing, HotSpot, etc, while Android has its own VM.

Additionally, most high-performance JVMs are optimized for long-running server applications, wile the CLR is optimized more for desktop applications (considerably better startup time, is fast without requiring lots of warmup, but doesn't do some of the very advanced optimizations JVMs tend to do). I suspect it would be easier to make the CLR performant on mobile than to make a JVM fast with constrained memory.

So basically, the CLR is probably already competitive on mobile devices. Does anyone know if Windows Phone uses a stock CLR or if they reimplemented it? Seems pretty snappy.

[zigzigzag]

HotSpot at least doesn't have terrible startup time. 50msec for Hello World and about 500msec to get a JavaFX window on the screen with a button in it.

The .NET CLR isn't really "fast without requiring lots of warmup". It's a much simpler design that out of the box simply compiles each method the first time it's used. It doesn't "warm up" because it doesn't do profile guided or speculative optimisations at all. The weakness of the CLR is one reason C# pushes more optimisation complexity onto the developer e.g. having to mark virtual methods explicitly instead of methods being virtual by default. With respect to memory usage I guess it's not much different.

There are JVMs designed for old candybar feature phones (J2ME etc). The issue is not "can you make a mobile JVM" as the answer is clearly yes for any type of phone, even very old ones. The issue is "how much fancy technology can you fit in that space".

[naasking]

> With respect to memory usage I guess it's not much different.

Memory use is quite different due to reified generics and value types.

[PeCaN]

Oh, I'm not saying JVMs can't work on tiny devices (heck, there are JVMs on everything from 2005 feature phones to Intel ME to some random tiny SuperH chip in a car), just that a high-performance JVM has so far not been designed for that particular use case.

[pjmlp]

Windows Phone doesn't use the CLR at all.

.NET is AOT compiled to native code using the same backend (C2) as Visual C++.

[Kipters]

CoreCLR, the same used in .NET Core

[wesamco]

it's happening: CoreRT[0], a .NET Core runtime optimized for AOT (ahead of time compilation) scenarios, with the accompanying .NET Native compiler toolchain. will enable you to compile for any OS/any platform including ARM. compile for every platform, run the AOT compiled Tree-shaken Machine code executable.

[0] https://github.com/dotnet/corert

[dom96]

Why do you consider Go unsuitable for UI development?

[patates]

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]

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]

obviously it is doable, but that does not mean there aren't better solutions today.

[dguaraglia]

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]

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

[millstone]

I don't like UI frameworks that work the way you describe either! I think this is mainly C++-legacy living on in Java and .NET, where they pay a penalty for being static. OO UI frameworks in dynamic languages can be structured very differently.

In Cocoa, you don't have these silly class-specific interfaces ("ButtonClickListener" or whatever). Instead it uses target/action: you give the button an object, and the method name to call on the object. So it does allow you to bind any member of that "world of classes" as-is.

Next, you allow the target to be dynamically determined. For example, say you have a button representing the Copy to Clipboard. You can set its target object to a sentinel representing the keyboard focus. And the button can even use reflection, and disable itself if the focus doesn't support Copy.

In a functional world, functions are opaque: the only thing you can ultimately do with a function is call it. But in an OO world, functions are closer to objects: they have names, they can be inspected, they can be dynamically dispatched. This is part of what makes OO languages excel at UIs.

[unscaled]

The functional programming approach to UI has more advantages than that. In my opinion, its greatest boon is that it allows you to cleanly separate UI logic, UI state and the actual data models, and reason about them in a straightforward way.

For instance, let's say you have a very simple Resize Image dialog, with two fields for desired height and width and a toggle button for keeping the current aspect ratio. Your data model is just (height : int, width : int), but you also have a UI state (keepAspect : bool). Changing the state could affect the actual data model, but it's not part of the final data you get out of the dialog.

In the traditional OOP paradigm, you'll just have to mix data and state, and once the UI gets more complex, you'll often end up with convoluted and bug-prone UpdateWidgets() methods being called after every user action or external data model update, and this function will both read and update the data model, the UI state and the UI view parameters. With the FP paradigm, you can just cleanly implement one function which receives the data model and state and creates the UI View, another function that enforces constraints on the data model and state and a few event handlers for specific user actions. This is essentially what you get nowadays with the more well-conceived workflows in ReactJS.

But while I really like this style of programming, I don't see how you can apply it to go. If there is one thing Go is worse at than OOP, that's FP. Go has no concept of pattern matching or currying, almost no inference, a cumbersome closure syntax and a pathetically weak type system without generics. Yeah, I know, JavaScript also falls short on most of the items in that list, but being dynamically-typed you can still easily write higher-order functions like map, filter, reduce and compose. Try to do that in Go without using reflection.

The Go authors and community seem to favor explicit for loops to functional constructs or comprehensions, and a little bit of copy-paste to function composition. That's OK, since Go's #1 goal is to be 'simple' in the sense that the code you see describes the imperative execution flow as accurately as possible, with very little magic happening behind the scenes. As far as UI design goes though, Go is probably even worse than C in some respects, since it doesn't even have these fancy macros that helped us brave UI programming back in the day. ;)

C# on the other hand, offers not only better-Java-than-Java OOP, but also an array of surprisingly competent functional features which keeps increasing with every language version. It had proper generics and closures since version 2.0 and covariance/contravariance and lambda syntax since version 4.0, expression bodies since version 6.0, pattern matching and tuples since version 7.0 and it will hopefully have proper record types and discriminated unions by version 8.0.

[bsaul]

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.

[PeCaN]

Go is unsuitable for programming, and UI development typically involves some programming.

[geodel]

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]

I wouldn't say that was because of .net/C#. Nor did the iPhone succeed because of ObjectiveC or Android because of Java.

[serge2k]

The transition from Java to C# is pretty easy and pleasant as C# is similar but better.

[bottled_poe]

> C# is similar but better

Oh really? Why?

[naasking]

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]

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

[naasking]

> The async/await API's and their rigid nature was torture

Way better than callback hell. The only awkwardness surrounds streams of tasks.

Operator overloading is a necessity. Matrices, big integers and so on, all require the familiar operators for clear code. Type inference is here to stay, and every new language has it. The fact that every language is also trying to adopt a streaming API like LINQ should also tell you something.

I'm afraid you're on the losing side of history on all of these points. C# does include a lot, and I would certainly prefer a single uniform abstraction to handle many things, ie. generators and async/await can be unified under coroutines or something similar, but the proliferation of "kitchen sink" features is not nearly as bad as you imply.

[Nullabillity]

Just go use Kotlin instead. Much nicer than C#, runs on any JVM.

[m_fayer]

In some ways it's nicely ahead of C#, but it's still missing some extremely desirable language features, namely async/await/yield.

[jmfayard]

kotlin 1.1 will have coroutines which cover generators/yield async/await stack-less continuations

https://github.com/Kotlin/kotlin-coroutines/blob/master/kotl...

[runT1ME]

Kotlin is missing monadic comprehension I'd say it's less powerful than C#.

[xorxornop]

Much nicer? You mean "at parity"

[zigzigzag]

The syntax is a lot lighter and more modern than C#

[eva1984]

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.

[jmfayard]

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

[int_19h]

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.

[RivieraKid]

> 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]

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

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.

[kuschku]

> 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]

This is great to hear, but it also kinda reinforces the point - .NET generics were reified from the get go, back when they were introduced in 2005. Java got generics a few months earlier than .NET, if I remember correctly; but we're still waiting for them to fully catch up. By the time it does, people coming from C# will be asking about things like sequence comprehensions (well, they already do, since those have been around for 8 years) and pattern matching...

[RivieraKid]

That doesn't affect me in any way though, from my POV, lambdas work.

[int_19h]

It will affect you as soon as you start writing methods that accept lambdas as arguments.