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