Hacker News Reader

Comment by mason240 | Hacker News Reader

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.

View on HN

Is that something Google wants? I don't see the advantage for them short of adding on C# devs

C# offers more support for memory friendly coding and performance than Java, which could ultimately improve Android's performance.

Of course, this would only work if they switch languages, which I don't see the Android team doing willingly without upper management "help".

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

That was my point, given the past history to changing language proposals.

Do you have any metrics to prove your baseless assumptions?

They said "has support for", not "is".

This is a natural consequence of having value types (structs). You can even change the bit packing and other layout properties of structs.

Are you replying to the proper comment?

In any case, he stated that an Android C# app would be more performant than an app coded in Java without supplying any metrics to prove his point.

>This is a natural consequence of having value types (structs). You can even change the bit packing and other layout properties of structs.

And yet the JVM still beats the CLR in performance.

> And yet the JVM still beats the CLR in performance.

On mobile memory-constrained devices? Can you share a benchmark demonstrating that?

The JVM reference inferred non mobile.

There are lots of J2ME in use, in spite of Android.

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.

> exactly the problem that this thread pointed out at the beginning

Sure, hence why I started it. :)

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

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.

Easy here are three simple exercises:

1 - define a class in Java and a struct in C# then measure how many bytes it takes.

2 - define an array data structure in Java and C# (with value types), for graph navigation, and check which allows for cache friendly algorithms

3 - try to implement an image codec in Java using vector indexes vs the same algorithm using pointers and SIMD in C#

Why do you think Oracle is adding those features to Java 10? Just to keep themselves busy?

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.

Reply on news.ycombinator.com