.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)
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.
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".
> 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.
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.
I don't think that's a relevant distinction. The article you linked to references both and uses wording like this ( mine):
In this spirit of enabling developers and their organizations, Google is pleased to be joining the Technical Steering Group of the .NET Foundation. .NET is a key component in the modern enterprise, and the Google Cloud Platform (GCP) team has worked hard to ensure that .NET has first-class support on Google’s infrastructure, including excellent infrastructure for Windows.
In addition to that it might be a good idea to make Swift a first-class citizen too. This would give developers a good chance to use similar concepts on both iOS and Android.
C ABI is very limiting, though, and it's a pain to implement.
What's really needed is some standard higher-level ABI (that does things like classes in a sane way), but which is made out of the existing C ABI building blocks in a manner that allows any existing language with C FFI use it. We can then add a new FFI layer that maps higher-level concepts better, but everyone can still play regardless.
This is exactly what COM was, and what its current evolution, WinRT, is. Any language that can do C structs and function pointers can ultimately do COM/WinRT, but it establishes things like lifetime semantics (refcounting), runtime metadata API, standardized futures etc on top of that. Then languages take that and map it to things that make sense there.
But it needs to be a shared public spec, preferably standardized.
... so, a C-ABI + per-language wrappers, or perhaps a high-quality cross-platform, multi-language wrapper generator? That effectively accomplishes what you're describing in your second paragraph.
Either way, it'd be great if one could implement efficient GUI's (and full apps more generally) on Android in C/C++/Go/Rust without having to generate JVM bytecode on the fly (or like Xamarin does: at compile time).
A language wrapper generator is about right, although for some languages it makes more sense to wrap things dynamically rather than generate code. .NET does it for WinRT, for example.
The problem with conventional C ABI is that it's just too low-level to produce good wrappers. I mean, all you have are global functions, structs, and data and function pointers. There isn't even a standard string type! (you can say char*, but there's the need to deal with lifetime issues - who deallocates what).
So in practice you need the C ABI, plus all those conventions, like how an "object" looks (i.e. how you do things like method dispatch or type queries), how a callback looks, how strings work etc. And all those conventions are expressed in terms of that basic C ABI - but they also have to be standardized, and they become ABI of their own, like COM and WinRT.
And you also need a convention/standard for metadata, for those wrappers to consume, and for any sort of runtime magic like property bindings - like typelibs for COM and metadata assemblies for WinRT.
This is the only approach that works across a wide variety of languages, and yet I can't help but think that would be a terribly bad idea in terms of user experience. Because you would end up with major apps written in Ruby or Python, draining batteries and stealing all your RAM.
Not that we aren't already headed there with a ton of app frameworks embracing javascript.
ART/Dalvik don't implement it, but Java ways for many languages to interop with each other for a long time already and is pushing the limits on that even further. The C calling convention as the lowest common denominator for language interop has been fading away for some time now already. Targeting the Java ABIs/calling conventions gives you access to both C libraries via things like JNI/JNA and also Python, JavaScript, Scala, Haskell (Frege), etc.
I like C# but making a language a first-class citizen of a platform is an huge task.
And we can already use kotlin without re-engineering the whole stack.
Not attacking you opinion at all but I'm a little shocked that someone would have this opinion, I work at a Java shop (using java 8 but I'm mostly now on the node.js side). Java 8 really doesn't have any features that are better than C#'s. Java 8 is missing some pretty major ones, like type inference, automatic getters/setters, LINQ, function passing support that's not brain dead, and a number of of things that make dev life SO much better.
While I prefer C#'s delegates/lambdas, there has been an occasional time I've wished for the ability to construct a full instanced object in that case - Java's anonymous inner classes are brilliant at this.
Likewise Java's OOP enums (basically singletons) are something I miss too.
That's a few small features I notice missing when I switch to C#.
Plus, in general I find there's a difference in style. C# libraries tend to be more pragmatic, following on Microsoft's heavy use of reflection and stringly-typed stuff. Not much OOP navel-gazing.
Java, on the other hand, celebrates OOP to a ludicrous extreme.
Also on the community, C# has been working very hard to develop the kind of bazaar that Java has, but they're coming from far behind on that front - far more C# developers restrict them to the first-party tools compared to the Java ones.
Maven, Ant, and Gradle are also in a class of their own. They help making building Java apps universally extremely easy. C# has an annoying amount of complexity in this area, with a lot of things being built into Visual Studio, and therefore Windows only. “Visual Studio” isn’t a fun build system if you’re not on Windows. And compiling people’s libraries from random repositories over github, bitbucket, etc., only to find that it won’t compile because it relies on some old version of a library that you can’t find online and the newer versions aren’t compatible.
Nuget solves the dependency issue. MSBuild has switching from part of the framework to VS to framework to open source. On other platforms there was always csc to compile programs (which is dramatically faster), something missing from the new dotnetcore.
There was also nant and a number of build tools, plus good old make.
Ms is working on this, but it's been slowed by politics. There was an alternative msbuild file called json.project that was happening, but it's since been deprecated in favour of strippinh down the old . csproj format to its bare minimum and cleaning it up for sanity.
Given the velocity of adding new features in C# these days, these will come sooner rather than later (indeed, some basic pattern matching is already in C# 7).
TBH c# is not enough of an advantage to do a huge migration to the language from java. Something like kotlin (still jvm) or swift (no gc) makes a lot more sense.
Or Kotlin but that's not his argument. He's arguing for Java 8. I don't agree that Java 8 is really an acceptable modern language for development. IMO it's painful and god awful slow develop in compared to a host of better languages (Swift, Scala, Groovy, and C# all included but not limited to).
> develop in compared to a host of better languages (Swift, Scala, Groovy, and C# all included
Swift, Scala, and C# are statically-typed languages, like Java, whereas Apache Groovy is dynamically-typed originally -- though static typing was added in Groovy 2, virtually no-one uses it. Dynamically typed languages like Groovy are good for glue code, build scripts, and testing, not for developing actual systems.
The ecosystem is an important factor too. I'm excited to use C# in new projects, but I can't move away from Java without replacements for all of the libraries of external code that I use.
I also think Java is fine. Compared to C#, I find Java code easier to read as there is less magic. I also use Groovy for some corner cases like for example JDBC stuff or metaprogramming. I'm also a big fan of Maven and the development tools for Java, and most importantly the eco-system with rich libraries and frameworks. Is there an alternative for JRebel or Spring-loaded for C# yet?
When I started going into C# from Java a bit, there were two things slightly annoying me:
- Class extensions: I saw code examples online that just wouldn't work for me because the compiler told me a certain method of a built-in class wouldn't exist. After I while I found out that the author of that snippet had used class extensions and not bothered to mention.
- The var keyword: While this is sometimes nice for quick scripting or hacking in the debugger console, it opens the door for hard-to-read code.
Those are not necessarily "magic", but potential obscurities that can't happen in Java, simply because Java lacks these features.
> The var keyword: While this is sometimes nice for quick scripting or hacking in the debugger console, it opens the door for hard-to-read code.
I find type inference to be the opposite, generally, because it encourages good naming, and it reduces noise/boilerplate. It also makes writing and refactoring faster (don't have to think about the return types, just the code flow).
The only situation I can even think of where it is a problem is when you are passing something to an overloaded method. For example:
void DoSomething(MySpecialType value);
void DoSomething(string value);
////
var result = GetData();
DoSomething(result);
You can't tell which one is going to be called by just looking at that code. However:
* GetData() is probably badly named in this situation
* If DoSomething() does something very different depending on the type passed, it should have different names, not be overloaded
On top of that, this code can also have the same problem without type inference:
> It also makes writing and refactoring faster (don't have to think about the return types, just the code flow).
I see what you mean, but isn't this one of the advantages of explicitly declaring types? If you refactor a method to return a different (incompatible) type, you'll have to touch all affected code parts, possibly revealing uninteded consequences of the change.
Also, I think remembering that autocompletion in VS had some trouble with correct type inference in some cases. But it's been a couple of years, maybe things are different now.
If you change the return type of a method without using var you would still have the exact same problems. That's not an actual problem.
I've used var since it came out years ago and never had this autocompletion problem you talk about.
You sometimes had to explicitly declare a type in foreach loops, but that had more to do with shitty legacy APIs that used abstract classes as return types. Wasn't really var's fault though.
Now you find out that updating Toilet objects is somehow expensive and decide to wrap it into a Cache<Toilet>. Unfortunately, Cache also has a flush method, so there will be no compile time error, but functionality is broken now.
I agree this problem would also occur when using chained calls (house.getToiled().flush()), but explicit types could cover at least some of the cases.
> Now you find out that updating Toilet objects is somehow expensive and decide to wrap it into a Cache<Toilet>. Unfortunately, Cache also has a flush method, so there will be no compile time error, but functionality is broken now.
This has happened to me exactly 0 times since type inference was introduced in 2007/2008.
> If you refactor a method to return a different (incompatible) type, you'll have to touch all affected code parts, possibly revealing uninteded consequences of the change.
If you can refactor your code such that you change the return type of a method such that it returns an object of a different type, which nonetheless implements all of the methods used by clients of your type that accept and return types which in turn accept and return types that line up with the expectations of their clients, etc, etc, without having to look at or touch any of those clients, and end up with something that happily compiles but gives an unexpected result, you need to have a long and hard look at how you're using the language's type system, and why it isn't encoding your assumptions in a sane way.
Your code shouldn't be compatible with a different type unless it makes sense for your code to be compatible with that type. That's what the type system is for.
One single common method is enough if that's the only one used in said context.
Sure, different types shouldn't use the same method name for different functionality, but it happens. And when such a scenario happens, I imagine it will be quite nasty to debug.
Dictionary<string, Tuple<int, List<string>>> foo = new Dictionary<string, Tuple<int, List<string>>>();
Is prefferable to:
var foo = new Dictionary<string, Tuple<int, List<string>>>();
What do you get from the former that makes the eye-pain worth it?
Also, the var keyword is necessary for anonymous types if you want to hold a reference to one. And this is a language feature I sorely miss in Java-land.
I have a lot of respect for the Monodevelop team, because writing IDEs is really hard, but it is really not an awesome tool for writing C#. (The XS modifications were never great, either. I'd rather write code in Sublime Text because Sublime won't randomly lose lines in its text widget.)
VS on macOS is Xamarin Studio rebranded, which Xamarin has never wanted to port for Linux (despite being a fork of MonoDevelop). I don't see MS changing that.
Project Rider is still extremely green and is not FOSS, nor free as in free beer.
VS Code is extremely limited and the little support it has is for .NET Core only.
I'm right now working on an MVC 5 project on Linux and I have to jump around MonoDevelop and Rider to have a workable dev environment; with the occasional jump to a Windows VM and Visual Studio to make sure everything works over there (it often doesn't).
.NET IS NOT a viable stack for developing on Linux and it's an inferior one in macOS. If you want to do real work with it you have to eat, breathe and live Windows and VS.
If I didn't absolutely have to work with .NET in this particular situation I would've laughed all my way back to a real cross-platform stack.
> .NET IS NOT a viable stack for developing on Linux and it's an inferior one in macOS.
.NET isn't, and wasn't officially meant to be. That's your problem.
I've been working on a .net core web app on my mac exclusively now for the last 8 weeks and have had no problems with it. I do check to make sure it works in full VS/Windows occasionally and every single time its worked without fail, and without a single change. Just pull the code and go. I haven't needed to touch windows but its nice to know it still works over there anyway.
Using VS Code as my main editor. Tried Rider a little yesterday and I'll probably switch to that once its more stable as it has a few more tools for refactoring etc.
So .NET core is clearly what's intended to be used cross platform, and it works great.
Most developers use Windows, where VS Professional (under the badge of VS Community) is free. The set of developers who use Linux and OS X (and I mean, I am one) is not representative of developers of a whole.
I mean most developers, period, use Windows, on a worldwide basis. Most web developers use Windows. Most C/C++ developers use Windows. Most Android developers use Windows. Almost all .NET developers use Windows--but most developers, period, use Windows.
Windows is the de facto standard in most places that aren't chasing the leading edge.
Sure! Unless you have ever, even once, stopped to glance at the overwhelming majority of line-of-business programmers that outnumber your notion of "developers" five to one or more.
But good job with the warrantless and wrong contempt.
> Class extensions: I saw code examples online that just wouldn't work for me because the compiler told me a certain method of a built-in class wouldn't exist.
One thing that VS can now do (as of VS 2015) is tell you where exactly the "missing" extension method is, and offer to add a corresponding `using` declaration for you.
Not sure if VSCode or VS/Mac support that, though. But they are all built on the same code analysis engine, so there's no reason why they couldn't.
I'm not saying it's a bad thing, I actually like both. It just takes more time to get up to speed and there is more surface of attack for devs to screw things up. That's also what I don't like e.g. about JS: It's so unrestrictive you can do a lot of wild things with it - which is sometimes good but often bad.
both of these are great tools, but as with many you have tradeoffs. Extension methods give you a way to produce very clean reusable code to extend behaviour of classes. Downside is you do need to bring in the extension method class (not a big deal).
Java is a shitty language exactly because they don't put in things like these out of fear that people don't know how to use them.
Java has default methods on interfaces instead. It's their take on the same issue, in a way. They considered the fact that with C#'s extension methods types not owned by the developer can be extended (as well as platform types) a problem and opted instead for a solution where someone who owns a type also controls its extensions. Default methods in Java are purely a way of adding stuff to interfaces in your API without breaking existing implementations (but also allowing future implementations to override those methods). C# on the other hand is merely a bit of syntactic sugar which can be confusing at times. (I have to admit not to be a fan of various libraries that add extension methods to integers and similar. It's not a good way of exposing an API in my eyes.)
TL;DR: Java has something similar, it just came from a different view of how the problem should be solved. Both approaches have advantages and drawbacks.
In my experience, C# can be coded almost exactly like Java 8; just ignore the extra features C# has. (I don't know why you would, but it's certainly possible.) Do you have more specific complaints?
Plumtree Portal / BEA Aqualogic Interaction / Oracle WebCenter documentation is/was a perfect example of this. When I was working on it, all of their code samples had a footnote that said something like "all code examples work in Java or C# unless otherwise noted". I don't recall ever coming across a language specific example.
Why would someone down vote an opinion that they are okay with Java? It added to the conversation. Personally I prefer C# and Swift to Java but others idea are just as valid.
Imho people are just expressing their disagreement. I know downvote is not meant for that, but I think HN is to blame here. If you have two arrows, one up and one down, why is up for agreement while down is not for disagreement, but for "this doesn't add to conversation"? The actions should be opposite, or they should use different icons.
The implication is "I have no interest in this because I'm happy with what I have". Okay, that's fine, please enjoy your Java and build wonderful things. Oh, BTW, why are you typing into a reply box on a thread you have no interest in? And the implication there is because your tool is a poopy head and I wanted to subtly point that out by expressing my lack of interest.
So, yeah, go away because that's not contributing to the conversation.
> So, yeah, go away because that's not contributing to the conversation.
Well, maybe there’s another implication.
Google switching to C# would lead to them neglecting and deprecating the Java ecosystem on Android. That’s gonna be real ugly for app devs, ending up having to rewrite everything.
So, maybe, there is a real contribution in the comment, which you just haven’t seen yet?
Yet, that’s what’d happen. Google hasn’t even managed to support C++ alongside of Java as first class citizen, adding yet another one would make the situation even worse.
> Why would someone down vote an opinion that they are okay with Java?
Paul Graham once said [1]:
I think it's ok to use the up and down
arrows to express agreement. Obviously
the uparrows aren't only for applauding
politeness, so it seems reasonable that
the downarrows aren't only for booing
rudeness.
It only becomes abuse when people resort
to karma bombing: downvoting a lot of
comments by one user without reading
them in order to subtract maximum karma.
Fortunately we now have several levels
of software to protect against that.
Many have taken this to mean that down voting a comment when they disagree with the opinion therein, no matter how well it argues that opinion and no matter how much it contributes to the conversation, is fine.
This is the number one reason why I looked for a different place and was hoping lobst.er would have taken off.
The down vote causes the comment to be dimmed and seen as a rejection to the comment. It is very frustrating when the top right side is your name and your "Hacker News Points" so I don't get why the down vote if you disagree. A down vote kills the conversation.
A useful opinion is the result of some thought process and set of inputs. By not explaining that thought process or its set of inputs, it is impossible for others to validate whether an opinion is reasonable and/or useful.
C# and java are very similar except C# has a bunch of extra features. Instead of creating anonymous classes and overriding methods you use event handlers. Plus you have linq,lambdas, operator overloading etc.
> Operator overloading is probably the worst feature ever invented, same with Class Extensions, reducing readability of code
or greatly enhancing it. Depending on how you use it.
That's why Java is a language for idiots. I'm not saying everyone who uses it or likes it is an idiot, it's a reasonable language to like. I'm saying it's designed to be usable by idiots. Can't have operator overloading, it might be abused. Can't have unsigned types, no one ever should use those. etc...
Every language is usable by idiots and some are even copied by idiots (C#). The constant security problems we face today were all created by idiots that didn't fully understand the language and the implications of what they were doing.
There are reasonable applications for goto. But I think there are more reasonable applications for operator overloading. (like Complex, BigInteger, or dimensional types)
Class extensions can be fantastic and really enable design elements in elegant ways, any advanced feature could be argued that it reduces readability if used poorly.
Yeah, I was thinking about that when I wrote the comment. They were most useful for `Observable` objects for event handling in swing; you don't really need that with C# events.
There are still uses though. Lambdas are the future, but there are lots of OO-first libraries that are still quite popular. It'd be nice to create e.g. `new Newtonsoft.JsonConverter() { ReadJson() {...} WriteJson() {...}}` etc on the fly sometimes without needing separate classes.
It's possible in F# though, so nothing dotnet specific is preventing it.
I doubt it's going to be a first-class citizen like Java anytime soon.
there is a lot of Innovation going on, with the new open source .NET.
the CoreRT[1] project compiles C#->C++->Machine code
for any platform, including ARM. and Samsung has been a big contributor to make that happen.
and today during the Connect() event, they announced that every Xamarin forms app will run on Tizen[2].
Where did you get that they compile C# to C++? I thought .NET Native was compiling to machine code, maybe with IL in between, but certainly not via another high-level language.
Ah, thanks. Didn't notice that part. So it's more an option, among others, while the "normal" .NET Native toolchain directly goes the IL → machine code route via RyuJIT.
Android is deeply dependent on a runtime with Java semantics. The only realistic hope for an implementation language other than Java would be a VM language like Scala or Kotlin. Kotlin is a semi-official alternative, since it is supported by the IDE technology provider.
C# is close enough that ART could likely be extended to encompass it. But it would be somewhat more work than supporting an actual JVM language.
BUT the real question is, with modern IDEs, does it matter? How much do you need a prettier and/or more concise language? And if you do, why not Kotlin?
WPF is a lot more than just a markup language for object graphs. Heck, the features I consider most essential and important to WPF (data binding, templating, and the idea that controls only encapsulate behaviour) have nothing to do with XAML at all.
No more problems with Oracle, C# features that Java is missing, such as type inference, proper generics, built in concurrency, operator overloading, first class optionals, ...
No more problems with Oracle, but what about Microsoft? Today we have the "cool" CEO, but that may change in the future. Remember Android started when Java was in Sun Microsystems' hands.
Apart from that, C# and Java are not very different from each other. You can get many of that "features" from other Java languages, no need to move away from the JVM, so you can still benefit from the largest community.
Better support for mixed managed/native code for one. There's P/Invoke, and .NET's byte code includes instructions for low level pointer manipulation (which C# exposes).
You could even compile C/C++ to CIL and obviate the need for some architecture specific binaries.
Actually, with the JNA (not JNI), one can invoke native code from Java even easier than in C# – you just define a Java Interface containing the relevant C functions, bind the library, and get an Object implementing it.
But that C/C++ code you're calling still needs to be compiled to native code. The GP was referring to .NET CIL (bytecode) supporting (by design) a large subset of C/C++ semantics.
The GP wants to avoid shipping N different binaries for N platforms in cases where the C/C++ code being called isn't already on the platforms.
I haven't used Managed C++ and I'm fuzzy on the details, but my understanding is that a fairly large subset of C/C++ can be efficiently compiled to .NET CIL. (Of course, the class loader for untrusted security contexts will refuse to load classes that use the type-unsafe/memory-unsafe portions of .NET CIL, just like the Java classloader for untrusted applets won't load classes making arbitrary JNI calls.)
Based on what I know about CIL and C++, the entirety of C and C++ can be compiled to [unverifiable] CIL. The sole exception is setjmp/longjmp - this might be doable on top of CLI exceptions, but I'm not sure.
And, indeed, VC++ lets you do just that. There are some bits of the standard library, mostly new stuff like threads and atomic, that had some issues, as I recall. But it's more about the amount of effort that's needed to target what's essentially a completely different platform.
The thing to know about CIL is that it has:
- structs;
- unions;
- raw data pointers, with pointer arithmetic;
- raw function pointers;
- dynamic stack allocation (like alloca in C);
- tail calls;
- exceptions with exception filters (arbitrary expression evaluation when deciding whether to transfer to a given catch-block or not) and finally blocks.
I'm actually curious if there's any language that cannot be compiled down to this efficiently.
Dynamic languages typically aren't compiled, though. So either a language would have some kind of VM of its own (which is typically implemented in C, and hence can be implemented in CIL), or else they have some form of JIT compilation, which can use CIL as a target.
If you bothered to read why DLR was created, you will see why CIL wasn't enough.
Or why Java following the same linr of thought had to follow DLR changes to the CLR and introduce invokedynamic byte code and its related infrastructure.
I know why DLR was created. I work on a team that has one of the guys who was working on it, and specifically on IronPython.
My point is that they are two different layers in the stack. CIL and JVM are lower level. DLR is a higher level layer. Said higher level can be implemented on any kind of lower level that's powerful enough - for example, you could have a kind of DLR directly on top of native code. All that matters for the lower level is that it's flexible enough to permit something like DLR to be implemented on top of it. CIL is undeniably flexible enough for that.
I remember reading some articles that justified DLR as CIL not having enough semantics that allowed to properly implement optimization algorithms commonly used in dynamic languages, like method lookup and call site caches.
Then again, maybe I understood it wrongly back then and I surely don't have the knowledge of your team.
Yes, that's right. But it's kinda what I meant. CIL is really roughly the level of C, plus some strongly typed object oriented stuff on top. It doesn't really offer anything useful for a dynamic language directly. But you can use it to implement a dynamic language VM with all those optimizations - just like C was used to write Parrot VM. DLR is to CLR as Parrot is to native code.
With C#, you can implement an IUnknown-derived interface completely in C++ (with `class` etc), and then define it in C#, and it transparently does all the mapping of members for you.
Yes, it's COM. People assume that makes it non-cross-platform, but there's nothing Windows-specific about COM, it's just a slightly higher-level ABI than C. So Mono supports it on Linux in the same manner. Not sure what the story is in .NET Core.
LINQ and Lambda expressions had me liking C# a lot back when I used it for an Entity Framework project I was on(well java got Lambda expression not too long ago though)
the Stream API is nice, but it is not extensible. I guess you have mistaken LINQ with the SQL style LINQ queryes, but it is actually a pack of feautures, the basis of all is the Extension Methods. Every LINQ query is just syntactic sugar for composed of some extension methods to IEnumerable<T>. Without that LINQ is a bunch of extension methods giving an extensible fluent API much like the Streams API, but with true extensibility.
How do you extend the the java Stream API? for LINQ you just drop in a few extra extension methods for IEnumerable<T>, IOrederedEmumerable<T>, IQueryable<T>, etc.
How do you reverse a stream in java? (I know you need to evaluate the whole stream for that) You can write a utility method, but that will break the fluent readable logic. In C# you can do the very same thing, with the same method usable as an extension method keeping the readable fluent expression.
Starting a stream is a PITA itself, as it differs for Iterables, Arrays, Collections... Been there, done that. Not that with some utilities these could not be overcome, but it was an inferior experience to LINQ.
Personally I would much much more prefer a switch to Kotlin than to C#. And I bet, after the collaboration for android studio, Google and JetBrains are already working on it
The technical steering groups is currently formed out of: Microsoft, Red Hat (so input from the main Linux distro), JetBrains (input from the makers of great tools for developers), Unity (one of the leading game engine makers), Samsung (one of the leading mobile device makers) and now Google.
.NET should have a bright future. And hopefully this should push a few buttons over at Oracle HQ so that Java catches up faster to C#.
I'm not sure where you would've heard the opposite. "Java the ecosystem" has clear advantages over "C# the ecosystem", but I've never heard anyone claim that Java is a better language. Things C# has that Java got years later or not at all include lambdas, LINQ, value types, reified generics, and async/await.
Kotlin fixes some of Java issues but it still can't fix JVM design decisions such as lack of value types (coming to JVM in what 5 years from now ?) and messy native interop.
Java has some really fancy JIT compilers designed for servers but .NET is much more AoT/native interop friendly with value types and reified generics, you can get a lot closer to C++ like code with C# than with Java (avoiding GC with structs, controlling memory layouts in collections, etc.)
The thing I find really interesting here is that Microsoft is pulling down the walls to it's garden and building bridges instead. It will be fascinating to see how this plays out, because this is a tectonic shift in the development landscape.
Props to Satya Nadella for having the gumption to lean into this strategy. I was expecting a few token open-sourcish libraries as a giant marketing campaign, but it looks like they're really committed to the idea.
I like the laptop with a bunch of lovely Microsoft technologies, and then WiX.
Please, please die WiX. Imperative XML + non-deterministic execution order + the worst error messages of the entire stack. I love C# and the CLR, but damn WiX sucks.
I suspect the real problem is the underlying horrible mess that is MSI. MSI is perhaps the most unintuitive technology I've ever used. Much of WiX is simply a bunch of leaky abstractions from MSI.
I haven't done a lot of 'Windows exclusive' development for a while, but something like 6-8 years ago, I was making an installer for a small company that up to that moment, they had to send someone over to spend a whole day installing the software on client's machines.
I was strongly suggested to use WiX. I spent 2 months trying to get something to work, but I wasn't able to get nothing truly useful to run. I remember explicitly that something as simple as writing to the registry was proving problematic. To make it worse, documentation was poor, and there wasn't much of a community around it cause it was brand spanking new.
Two months in, without telling anyone, I decided to ditch it and use NSIS. That day I had something that actually worked! Within 2 weeks I had something that was running end to end, installing the software on the machine. The next month was polishing, and testing/fixing for different versions of Windows.
I have no idea how things may have changed now, but if I tasked with making a Windows installer today, I wouldn't even think twice about using anything other than NSIS.
Can NSIS by now roll-back partially failed installations? That's to me the biggest gripe I have as a user of such installers – whenever something weird goes wrong you end up with a half-installed application of which you don't know how to get rid of the pieces.
Good question. It's honestly been too many years for me to remember. But, with a bit of a biased view on it because of having such a good experience with it so long ago, I imagine it either does, or provides the mechanism for the developer to implement it.
Assuming it hasn't done a bunch of other stuff yet. While Microsoft recommends that the install directory is the application bundle and programs should confine themselves to it, that's hardly what many applications are doing.
It depends on who and how you want to deploy it, but chocalatey may be a good option. You distribute apps as nuget packages (which are just zip files).
For the server side there's octopus, which I've been very impressed by, also done via nuget packages.
Rob Mensching the creator of WIX was on dot net rocks recently. Might give you a bit of a perspective from the other side :) http://www.dotnetrocks.com/?show=1367
I can't believe WiX hasn't already died. I tried using it 7 or 8 years ago. What a terrible idea to use XML like that. But, that was back when XML was ... the ... bees ... knees! I mean everyone was gaga over using XML for everything.
I stopped doing .NET dev almost 7 years ago. At the time, WiX was terrible, but then so were a lot of things. .NET didn't even have a deployment story back in those days.
As a Java developer using Linux and Mac, I couldn't be happier. I would love to see C# and .NET on Android. I'd be equally thrilled to use Microsoft tools (so long as they're on Unix) to develop for it too.
Semantics improves expressiveness which provides conciseness, which leads to less code. Less code is generally less bugs (sure...arguable). But definitely expressiveness is also often correlated to programmer happiness, which is important in itself.
Swift is very similar to C#.
I am just thinking the tooling and the huge .net community who are already building ios with c# in visual studio. If it became core it would be hugely beneficial
Tizen supporting .NET is the interesting thing in this article to me. If Microsoft got so far as getting UWP apps running on Tizen, Microsoft and Samsung could potentially offer a pretty compelling offering against Android.
Windows Phone had UWP no? Where developers were concerned it didn't offer them anything compelling enough for that platform it seems. I think it would be even less so on Tizen even.
UWP was introduced in Windows (Phone) 10. Prior to that, apps could share backend code between Windows 8 and Windows Phone 8, but the UI had to be developed separately for each.
The Windows Phone 8 to 10 transition lost a lot of people, myself being one of them. There are very few Windows Phone 10 handsets being produced, especially if you are looking for "flagship" quality.
Tizen has other traits that might be more appealing, like the fact that it's open source. (And arguably, more open source than Android by far.) And if Samsung chose to start pushing Tizen phones over Android phones... bear in mind, Samsung is pretty much THE Android manufacturer, everyone else rides their coattails. Samsung is maybe the only company that can upset the apple cart as far as Google's concerned.
In the west maybe not tho the Samsung store has tons of stuff.
FYI many if not most android phones are sold without the google store today in emerging markets if you buy a <50$ in Africa you are not getting Google's App Store.
To be honest, everyone sideloads the Play Store anyways. Heck, they sell it pre-sideloaded here in South America (and with pirated apps if you want them).
I disagree, while some may buy samsung as they see it as the top 'android' choice, I buy them because the displays look the nicest to me. I could care less what OS it was running, and I can't be the only one.
(Why do you think people can iOS <-> android but not android <-> 3rd party? The adjustment is the same and not everyone buys a phone to play games with their friends)
You are only saying this because you have all the same apps on Google Play Store as you do on the Apple App Store(basically).
You would begin to care what OS you have real quick when it doesn't serve you very well and no one is talking about games here(Banking apps etc)
It definitely didn't start that way. For a very long time, Android didn't have most of the apps iPhone users wanted, especially not back in 2009 when I got my Android. It took time, but it happened. Especially in the case of Tizen, where it could run Android apps, they'd really just need to convince the top 200 apps or so to port over to their store, and that'd get them started pretty well.
The challenge is not getting the apps ported, the challenge is making devs want to port the apps. Sometimes that comes because everyone is talking about a new phone, but where Android started, was the developers of those apps themselves getting excited about it. But Android no longer caters to developers, so a platform like Tizen has a great opening there. As Windows Phone is closed source, it couldn't capitalize on this nearly as well.
This was 2009 and the smartphone was not a mature platform. People still used their computers on an everyday basis and didn't rely on their phones as much.
This is not the case anymore. I work at a university where I have network statics for all devices connected and can tell how they are used and what they are used for.
People expect certain things from their phones now and if they cant have it they would go somewhere else. You're in denial.
"But Android no longer caters to developers" Can you explain what you mean by this?
Since Android debuted, it has gotten rid of SD card slots, keyboard layout options, removable batteries, and replaced most of it's open source apps with proprietary Google Apps. Android has gone from being generally unlocked to where even Google's own Pixel had to essentially get jailbroken with an exploit. UI design catered to power users has been replaced with large simplified UIs with excessive animations and bright colors.
Android of today is basically the iPhone. Really would like to see a phone for power users again.
Android is the operating system, how did it get rid of a removable battery? SD cards can very well be used with Android still so that was never removed from the OS. what Google did was hardened it so that apps don't have full reign over everything on there compromising security.
People are once again using their phones for a lot more than casually surfing the web and playing games.
Access to someone's phone now can give you access to their entire life hence the tougher security.
I guess Google can't satisfy everyone and there are options for now with Tizen right?
I completely disagree. Most people buying Samsung phones are buying "Galaxy" not "Android". If Samsung can attract the app developers, people will come with.
Tizen also already can run Android apps, and if they add .NET support, could probably run UWP apps potentially as well. Many of us have left Android or are looking to leave Android, and an open source competitor with wide application support from a good hardware manufacturer would be a compelling reason to jump. Personally I carry an old Windows Phone to escape the Google monopoly, but obviously for many moving to a closed platform is less ideal.
Not yet - but it does run Xamarin Forms apps, and I'd be _very_ surprised if the syntax for Xamarin Forms and UWP isn't integrated at some point soon... They're both XAML based.
At one time, the JVM had superior configurability - many more runtime options for aggressive garbage collection, profiling, optimization, and debugging.
But maybe you're right - it's been a few years since I made a looked at the comparison.
> At one time, the JVM had superior configurability - many more runtime options for aggressive garbage collection, profiling, optimization, and debugging.
I'm not sure that this actually implies it was a more robust and production ready system. The JVM seems to be on a similar path of reducing somewhat how much tuning is expected of operators. Certainly we do less of it now on Java 8 (although some of the defaults it sets are truly boneheaded).
The JVM is still a more performant VM. And it does still have a lot more options for varying use cases with a big selection of GCs as well as custom VMs that let's you do real time programming.
But as others pointed out, Android is not built on the JVM, but on Java. Java != JVM.
And the CLR is a pretty great VM too. It's performance isn't as great as the JVM, but it's darn close, while also offering a lot of ease of use over the JVM.
The JVM initially targeted more diverse systems than the CLR (desktop only) so perhaps the JVM needed more configuration options.
As far as I understand it, it was a design goal for the CLR to not require those configuration options.
In fact, a lot of the design of both the CLR and C# can be easily traced to various shortcomings and pain points of Java (type erasure, value types, versioned modules, exceptions in method signatures etc).
I've used Java since it was first launched and I've used it as a primary language since 2003 (it took a while before it was usable for the stuff I was doing). Although I like Java, I don't trust Oracle. They are not a well-behaved citizen of the software world. So for the last few years I've been eager to migrate away from Java.
I really hope Microsoft understand that if we made the move to C# they have a brilliant opportunity to set the standard for how to behave.
(Meanwhile, I'm in the process of using Go for projects)
Jon Skeet (C# guru who works at Google, for those unfamiliar with C# rock stars) was interviewed on Software Engineering Daily, and his response to this question was basically, "uh, no." Google isn't shifting their focus away from Java/C++ any time in the foreseeable future. (You might see improved support for .NET Core in Google Compute Engine, though.)
That would be huge win for Microsoft, presumably if Android apps are written in C# they will be easy to port or have shared libraries with windows apps.
I don't think they have to switch languages. With official support/talent working on Xamarin.Android (which is already great) coming from both MS and Google, that'd be enough to make C# on android a sure thing.
Other than some hypothetical legal advantage in Oracle vs Google case. C# in place of Java would be as likely supported by management as MS Exchange/Outlook in place of Gmail
I'm not actually sure which comment I'd intended to reply to anymore (wrote it quickly on a lunch break!) - but, anyway: I'd agree the JVM is a bit faster than the CLR currently, but this is arguably because the CLR is more heavily tuned towards startup time (the reduction of), rather than throughput. They've invested more heavily into AOT compilation support (also in service of this goal) and compiler-as-a-service tech (Roslyn) rather than performance... perhaps this might change? Certainly the community additions to the CLR and the larger ecosystem eg ASP.NET Core have produced some notable performance improvements.
Also I'd say the CLR has more potential insofar as performance due to its design than the JVM does, but the JVM has received more attention in this area historically, so it's 'winning' currently despite this.
> And yet the JVM still beats the CLR in performance.
Which CLR and which JVM?
Languages are not implementations, I remember when junior Assembly coders could easily write code better than any C compiler, and look how C is regarded nowadays!
As for the CLR code, if you know about compilers and watched Channel 9 and MS blogs, than you would know that Microsoft only made the CLR good enough.
Only now they are sharing the backend with Visual C++.
Yes, and it has always had horrible perf, especially when it came to memory. Standard techniques to reduce memory pressure included never ever instantiating your classes. So basically everything is a static method, and the only data types you can use are primitives, since Java doesn't have structs (exactly the problem that this thread pointed out at the beginning). So people would instead preallocate global arrays of primitives, and referenced their elements by index, if they needed to pass something like a record or an object around.
It's a mighty good option to have when you are negotiating with Microsoft. Imagine Google offering to Microsoft that they would adopt Microsoft development tools and technologies iff Microsoft kills Windows Phone.
Why on earth would Google care enough right now about MS' phone efforts for that to be something they're actively seeking?
I think it's far more likely that any movement towards C# on Android would be motivated by: 1) perhaps enough devs are asking for it, and 2) it would give them extra leverage in negotiations with Oracle about Java.
Google would be foolish to think Microsoft is down for good in the phone market. If this is something they would ever consider negotiating for, they wouldn't wait until Microsoft is strong. You do it when they are weak.
Plus, if they make a deal with Microsoft, Samsung can't come along and make the same deal with Microsoft for Tizen tools.
The only foolish company would be Microsoft for thinking they still have a chance in mobile. Besides, they've already capitulated as their marketshare is below 1% and continuing to decline.
It's all about the mobile ecosystems and it's something that Microsoft and Samsung will ever have.
So you want Google to let Microsoft control their mobile development strategy if Microsoft promises to shut down their, less than 1% market share, mobile OS? Right.
IF Microsoft makes another run at phones, the should use Tizen with .NET. That would be very much in the spirit of Android. Every Android OEM/ODM would know how to port it, so it might pull along some 3rd party hardware makers. Most importantly it would lose all the complexity of being Windows Everywhere while still running key MS apps.
They say Tizen TVs with .NET support will come in 2017. Does that mean older devices will never support .NET? I couldn't find any information about that.
Now please make C# a first-class citizen in Android and start to migrate from Java to C#.