Hacker News new | past | comments | ask | show | jobs | submit login

I’ve always admired Java for managing to slowly but surely move the language forward while maintaining backwards compatibility and keeping the community together. When you look at how many other languages have faltered and lost momentum due to transition issues (Perl 6, Python 2/3), it really shows have difficult of a task it is.

Progress can seem glacially slow at times - it’s always disappointing to see your favorite upcoming feature get pushed to a later release - but the current language is undeniably light years better than what we started with.

Respect.




I would add C# to the list of languages with good backward compatibility and progression with every new version. Very similar to Java, and has a lot more feature set with somewhat decent documentation.


One thing I've always admired about C# is that it's an ISO standard. Which I'm not sure if that really means much these days in terms of computer programming languages. It seems like it would be an amazing hedge against a private organization co-opting it in the future.


The catch is that C# standardization lags behind language evolution. At the moment, the most recent edition is ECMA-334:2017 aka ISO/IEC 23270:2018. It corresponds to C# version 5.0, originally released back in 2012 - it was the one that introduced async/await, and it's still missing stuff like null chaining.

(for the curious, here's the complete list of C# language versions: https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csh...)


I’m not sure how true it is, but haven’t been some quite great breaking changes with .NET core, .NET, I don’t even now where they are now.


Yeah, .NET is an odd choice to praise for backwards compatibility.

.NET 1 -> .NET 2 was iirc a total break due to the integration of generics, amongst other things. Source code had to be rewritten.

.NET Framework -> .NET Core was another total break. Lots of .NET code that worked on Framework didn't run on Core at all and had to be ported to different library or required other changes.

The fact is, the .NET world has made moves that obsoleted lots of prior code several times. Java never has, unless you count the various boulders rolled down the hill at people using JVM internal APIs.


A big benefit of the 6-month release cadence (since Java 10) is that if your favorite feature gets pushed, the next release is just around the corner.


Well, kind of. In practice despite the faster release schedule quite a few features have been in incubation for years. Most features that people could identify as favorite have been talked about for nearly 5 years now and are still not targeted to get a stable API yet.


That is true, the cost of mistakes for a platform used so broadly is high which is why folks working on the platform don't rush things that aren't ready or don't feel natural yet.

That said, the faster release cadence has done more than just cut the "wait time for next release" down. For example, the preview/incubator system has allowed the team to get features into releases without being final (see JEP's 11 and 12, or [1]).

And each of the innovation projects like Loom, Panama, and Valhalla, are able to release features incrementally. In fact, it could be said that something like Valhalla wouldn't even be possible without a faster release cadence.

I could go on and on with anecdotal stories about faster pace of innovation, less energy spent on releases, etc....

[1] https://blogs.oracle.com/javamagazine/the-role-of-previews-i...




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: