Hacker News Reader

Comment by pjmlp | Hacker News Reader

Looking around the office and my phone, Java is anything but "legacy".

As for alternative JVM languages, while they are cool and have brought many fresh ideas into the platform, they remain a very tiny portion of the Java developers' market.

Java takes a very long time, because backwards compatibility and cooperation among giant companies takes years.

C# has basically Microsoft deciding how the roadmap looks like and rebooting the platform multiple times.

C# 8 won't even be fully supported on the .NET Framework.

View on HN

And yet Google is investing into Kotlin.

Yes, Java takes it slow because its target market - enterprises - want it, and they have good reason to. There's nothing wrong with that. All I'm saying is that there are many other niches where developers find lagging too far behind other available options, and there's a noticeable decline in its use because of that.

And so the analogy with PostgreSQL in this case isn't working well.

Google is investing into Kotlin due to politcs with Oracle, and JetBrains (makers of InteliJ which powers Android Studio) pushing Kotlin everywhere they can.

They even separate Kotlin/Native graphical debugging from InteliJ, so that developers get to shell out for Clion license as well.

The only variant where InteliJ and Clion come together is on Android Studio, thanks to us NDK users being vocal how 3rd class it felt versus Eclipse CDT.

On platforms where developers can make use of standard Java there is less pressure to adotpt alternative JVM languages.

Just like F# will always be a shadow of C#, never getting to play with all toys, with C# slowly picking up all features that matter.

Runtimes are different from languages. The C# language has never been rebooted and is fully backwards compatible, and there's no better example of long-term support than Microsoft. You can still run apps from the MSDOS era, and even upgrade MSDOS through to Windows 10 if you have all the CDs today.

Runtimes and languages go hand-in-hand, a runtime that doesn't support everything that one expects from the standard library breaks compatibility.

Code starts getting full of #ifdefs

Siverlight, .NET Core, WinRT, UWP just to give three reboots.

No support for dynamic APIs, appdomains, IL generation on the fly, reflection APIs done in a different way, ...

Actually C# is not fully backwards compatible, variables declared on foreach statements changed their semantics in C# 5.

https://blogs.msdn.microsoft.com/ericlippert/2009/11/12/clos...

MS-DOS is only supported in 32 bit variants, a species in extinsion.

> The C# language has never been rebooted and is fully backwards compatible

This is not true - there have been several breaking changes in C#-the-language since 1.0. For example:

https://davefancher.com/2012/11/03/c-5-0-breaking-changes/

So, like DOS 3.3 to 5 to 6.2, and Windows 3 to 3.1, to 95 to 98 to 98SE, to ME, to XP, to 7, to 8 to 8.1, to 10?

I think I was using floppies until Win 98?

Here's a 10 hour video from DOS to Win10: https://www.youtube.com/watch?v=l60HHWWo9z4

Reply on news.ycombinator.com