.NET would have had a real chance at being the android application platform if it was philosophically in the state that it is today (open sourced toolchain/compilers, open-source friendly MS, Mono/Xamarin in good shape).
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].
Silly idea that will never happen, but imagine Google and Microsoft* working together on Android and it becoming actually open (i.e. not a tool to protect google search on mobile) and easily targetable by Java, C#, Go, etc. apps. From a technical point of view it might sound difficult until you realize modern smartphones are veritable beasts compared to computers 10 years ago, and we've had general purpose OSes for decades now. This is mostly just me shipping Google and Microsoft after their successful recent collaborations like TypeScript.
* - based on the premise that MS might be open to this after failing at mobile over and over again
It's not really so silly from Microsoft's perspective. Given the sorry state of affairs with WP, and company's overall focus on Azure, it would make perfect sense to embrace a popular mobile platform, if this could be translated to more sales of Azure services.
What Google is to get out of it is a more interesting question.
Xamarin is a bit of a hack. What we really need is a cross platform solid (i.e. not javascript) language supported natively.
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.
I've often dreamed of this, especially when it seemed all too obvious for MS to release an Android phone; then again after ubuntu/bash on Windows. But whereas it seems like a golden opportunity for MS, it would essentially be Google handing keys to a mobile realm to MS. Short of a super-deal on desktop I don't see what's in it for Google to enter such a partnership (and Bing vs Gsearch, or countless other frontal rivalries, isn't conducive to a desktop alliance, notwithstanding the predictable end/shift of desktop as a category/paradigm). Nothing beyond scope-limited projects like TS between MS and G, as I see it currently.
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).
Both these platforms, which include a cross-platform UI library including native controls, are Windows, iOS, Android, macOS, and Linux in the next release.
The thing with C++ is that it's a hard language. I understand the power for low level stuff, and it is available already. But for 99% of apps, a higher level language like java or c# is really what we need.
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 wrong with Vue.js/TypeScript/ES6/Weex(native) or React/TypeScript/ES6/Native? It's no C#, but it's modern, performant, crossplatform and can be OS themed.
I'm only familiar with TypeScript. It is adding types to javascript, which is welcomed. But that doesn't make up for a lot of the uglyness of the language. Javascript was never meant to be anything else than a way to open porn popups ads and it shows.
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.
Also, a few years ago Xamarin actually ported Android (then 2.2. IIRC) to Mono/C#, as a test for Java->C# converters, and the result was faster than Android/Java.
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.
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?
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)
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.
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".
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.
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.
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.
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?
> 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.
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.
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.
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.
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.
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".
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.
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
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.
> 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.
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.
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.
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...
It's worth noting that Microsoft is aggressively pledging about patents, open sourcing with very clear and explicit licenses, and making industry-level promises that imply they're serious about making .NET Core an open and usable platform.
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.
OpenJDK remains an Oracle project and all contributors should sign the Oracle Contributor Agreement (OCA). Although, an agreement of this nature exists in some other open source communities. But I feel, hesitant to grant Oracle the following rights :
- License any patents bearing on your contributions to Oracle.
- Assert that you are legally entitled to grant Oracle these rights.
- Oracle have full copyright ownership of all the code in that project.
One possible way out will be something like Swift port to Android made by an open source contributor to Swift. Someone with deep knowledge of C# can take a stab at C# to Android. I'd think Google have very few C# people internally.
There already exists C# for Android, it recently became free too when Microsoft bought up Xamarin (the company formerly maintain Mono and the Xamarin Android and iOS wrappers). Microsoft is really pushing .NET Core and the open .NET platform, really an awesome move for developers.
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.
I agree with most of it. But I personally think .net/C# simply to not bring enough advances over Java to even think of changing core parts. Most advantages that get mentioned are app developer conveniences.
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].
0 https://flutter.io/
1 https://github.com/fuchsia-mirror/