Google have not made their own languages Dart/Go official to Android. Why would they make languages other than Java a priority now?
Moving android away from Java is going to be a big undertaking and I doubt Google will undertake such a huge project only to move away from Oracle and closer to MS.
If they ever try to replace Java, it'll be Dart or another language they acquire in future. Dart has good chances.
They already have an early stage framework to make Android (and iOS) apps with Dart[0]. It's also the main GUI toolkit for their Fuchsia OS [1].
* - based on the premise that MS might be open to this after failing at mobile over and over again
What Google is to get out of it is a more interesting question.
What would be ideal would be that Apple, Google and Microsoft sit together and agree on a common language and GUI API that would work on Android, iOS, Windows, MacOS and Linux natively.
Or for something more like C#, Delphi? https://www.embarcadero.com/products/delphi
Both these platforms, which include a cross-platform UI library including native controls, are Windows, iOS, Android, macOS, and Linux in the next release.
Even C# is starting to show its age. Perhaps it's the occasion to reboot it. Start from scratch based on modern concepts with a truly cross-platform language.
With support from Microsoft + Google + Apple, and cross platform across Windows, MacOS, Linux, iOS and Android, adoption would go to 100% (or 11!) on month 1.
What's more likely these days is Google entering the desktop space (x86) by merging it with mobile (e.g. Andromeda). Pretty sure that OS could grab 30% of new laptops in a heartbeat (think: almost free for manufacturers: no Win license).
Meanwhile, I'm pretty sure Apple will do its thing (did they fix Gmail on Mail yet?) Though I think Swift, if it were in "the state of C#/.NET" as worded above, would eventually become a great candidate for a high level common language. Somehow I don't think Apple is trying, their open-sourcing seems to end at "reassurance" (stacks can't die if you can maintain the packages, b/c oss, yay).
But even C# is starting to show its age and would deserved a reboot. If we agree on a truly cross platform language, we might as well make it modern and simple, with great tooling. That does mean breaking backward compatibility with older languages but the benefits of having a common language way offset the cost of retraining developers.
http://www.investors.com/news/technology/microsoft-alphabet-...
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.
Oh really? Why?
Java has anonymous classes and static interface members as the only real advantages over C#.
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".
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.
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...
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?
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.
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.
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.
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.
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.
http://arstechnica.com/tech-policy/2016/01/android-n-switche...
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.
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.
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".
Memory use is quite different due to reified generics and value types.
.NET is AOT compiled to native code using the same backend (C2) as Visual C++.
After Google own teams decided to go Typescript, the Dart team seems to keep searching for reasons to keep the project alive.
https://github.com/Kotlin/kotlin-coroutines/blob/master/kotl...
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.
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
Not by a big margin. Java 8 has lambda functions, which used to be the most painful aspect of the language for me.
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.
Actually, that's going away with Java 9 (or 10). Luckily.
* It has an enormous user base
* It's not owned by Oracle
Not saying they will but those are real possible reasons for Google to do this.
What the parent wanted was official support from Google for Xamarin's Android API wrapper or a complete rewrite of core parts of the OS in .NET instead of Java. It seems fairly unlikely because of all the effort Google has invested in their Java VM and JIT/AOT compilers, but maybe that'll change.
So you replace one lawsuit-happy DB company with... another lawsuit-happy DB company.
It would be nicer if there was a managed langauge platform that was not tied to an entity with a history of patent litigation, but let's not lose our sense of scale here. The degree to which Oracle has betrayed our community and tried to undermine the bearable status quo of the software industry to milk the Android ecosystem is as unforgivable as anything Microsoft has done in the darkest depths of the Balmer era.
I'm not convinced Microsoft is as lawsuit-happy as Oracle.
Maybe Google could decide that putting resources on Dalvik and related tool development does not make sense.
Maybe they would like to see one language to cover both the client and cloud development.
Because mentat asked please.
In other words, it might have less to do with the merit of the language than with the politics of the organization.