>The Java strategy of being very conservative about what you add to the frontend would have done C++ a lot of good after C++11 (or even before that).
Java lost a lot of mindshare to C# and Kotlin due to that "strategy".
Java lost a lot of mindshare to C# and Kotlin due to that "strategy".
C# still doesn't deliver on all platforms where there is a JVM available, and has yet to even offer something as portable as Swing across all those platforms.
Kotlin really only matters on Android.
In fact right now we are having issues with .NET RFPs, because everything that comes through the door are Java related RFPs.
There was a 8 year gap where C# users could use stuff like enumerable operators while Java users were stuck in the stone age of writing loops for collection manipulation in a high level language ...
I have been working with Java, .NET and C++ since they exist, and C# being more feature rich than Java doesn't help if the libraries or OS support that a customer needs isn't there.
I think you'll find many people outside the HN crowd also appreciate their approach over trying to appease the kinds of customer needs that involve keeping 25 year old binary only jars running.
To me .NET Core is a shining example of that
To this day there are plenty of libraries that are yet to run on either Core or outside UNIX.
Plus not everyone is happy how the whole Core, .NET 5, .NET Native, Reunion, UWP, CoreRT, Xamarin, MAUI, Blazor is being managed.
A language alone isn't enough.
And to your second point.. I mean you're comparing concepts at very different levels of a stack. Your list includes a language runtime, a web framework, an OS specific application format/framework?
It's like saying "Java, HotspotVM, JavaFX, Tomcat, Android APK, Vert.X"...
In reality it's ".NET Core and .NET Framework".
And while there have been some growing pains as the term .NET became overloaded, it's always been clear .NET Core is where they want people to be, .NET Framework exists because migration to a new platform wasn't going to happen overnight.
Every year there's more and more .NET Core compatibility, they've done a good job with .NET Core so more people are willing to use it (and port packages to it)
https://docs.microsoft.com/en-us/dotnet/standard/choosing-co...
Yes, the future is .NET Core, however pretending that outside Windows it can match Java offerings just reveals a complete lack of knowledge of all kinds of platforms that have Java support available for them.
Guys like PTC, Aicas, Gemalto, microEJ doing embedded real time Java, selling M2M devices, IBM and Unisys mainframes, 80% of the mobile world (even if it is an adulterated flavour of coffee), smartcards, blue ray players, healthcare and TV settop boxes, kiosks and plenty of other use cases.
.NET is catching up with 25 years of Java doing cross platform development, while anything that came out of Redmond has been mostly Windows only for 20 years.
.NET Core only supports the three major mainstream OSes, zero support for anything else, and has the growing pains of a platform where plenty of third parties are yet to release anything on Core.
Sitecore just released their first version on .NET Core earlier this month, and I don't see anyone rushing to upgrade.
Doing WPF, Forms? Good luck with many GUI component libraries.
Apparently the designers are going to miss .NET 5 for full stability.
The beautiful thing with being a polyglot consultant is that I don't have to convince myself that I am using the best stuff as "Developer X", I just use whatever stack the customer asks for and then move on.
This is true, but this level is support for the majority of use cases. I do personally find it very annoying that refuse to support 32-bit Linux tho.
> has the growing pains of a platform where plenty of third parties are yet to release anything on Core
This was true a few years ago, but certainly isn't now. I honestly can't even remember when I last tried to use a library that didn't have dotnet Core support.
Also worth noting that anything built for dotnet framework 4.6.2+ (4.6.2 was released in 2016) will run just fine under Core CLR.
Here is another example, Oracle drivers for .NET Core only support a subset of their capabilities on Core.
I can keep feeding examples of stuff that is actually relevant for Fortune 500's, which Microsoft keeps out of their .NET Core marketing or just hand waves as yet another porting effort, as if we didn't had better ways to spend our money.
But yeah, why compete with the rest of the Fortune 500 that hire top talent to build out new systems...
when you can pay a "fixer" who prides themselves on self-flagellation keeping legacy systems with no source targeting platforms designed for computing as it existed decades ago (that only exist because of gross mismanagement and a general view of development as a cost center)?
What's interesting to me is someone would actually try to hold this up this dance as something the rest of the tech industry should aspire to uphold lol. Maybe because it makes for less "war stories" deep in the bowels of decade old systems with no documentation successfully migrated to the latest Jenga block in their leaning towers?
Imagine if other fields worked like this
"Our materials science company prides itself on only releasing plastics that can be molded using what was state of the art 20 years ago"
"Our competitor Macrohard insists on occasionally releasing new plastics that are stronger and cheaper to develop with, but we cater to those shops that refuse to invest in techs who know newer processes!"
I have no idea what on earth you're on about... you didn't bring up anything I didn't know as far as places where various JVMs live.
This just reads like another distraction from the topic of language direction just like your last comment trying to confuse web frameworks and language runtimes...
Why is .NET Core supposed to be blindly chase platform parity with JVM down, especially down to embedded devices?
You realize the JVMs used on embedded devices aren't the same ones used on desktop right?
Like there are C# frameworks for embedded development on microcontrollers, why on earth would that be .NET Core's domain? Do you think HotspotVM is running on those smartcard microcontrollers?
-
Your entire comment you seem to be under the impression .NET Core exists to be a drop-in replacement for the JVM for every usage.
Which is especially strange because you're using JVM as a generic term for every JVM in parts of your comment, which would maybe be comparable to the CLR at best (but still be an odd comparison to make)
If anything you're speaking to the strength of C# and a product like .NET Core, they're not chasing the same goals that skewered the development pace of Java.
The C# team is not worried that their language standard changes might be hard on people embedded runtimes in smart cards or 25 year old binary only jars
The same mentality is why C# paid the price to break backwards compatibility on generics back in the 2.0 days, and enjoyed a much more powerful implementation going forward in perpetuity.
You're free to feel one approach is better than the other, but it's non-sequitur at best (and disingenuous at worst) to start spouting off about how the JVM runs on smartcards and so that means .NET Core is supposed to be matching that in a conversation about language growth...
Yes, C# the language is better designed than Java the language, while .NET the ecosystem is is tiny spot of Java the ecosystem.
When I mention JVM, I mean any implementation, I don't mix Java with Hotspot.
And yes PTC and Aicas sell full Java SE compliant implementations for embedded development.
The only embedded options for .NET are Netduino, hardly market relevant, and Wilderness Labs, which doesn't cover at all the kind of industrial deployments PTC, Aicas, microEJ and Gemalto are doing.
I work with Java and .NET alongside each other since they exist, so I know pretty well the pros and cons of each platform, specifically outside the implementations that people mix with the language.
C# doesn’t break too many things while it evolves. Example: https://docs.microsoft.com/en-us/dotnet/api/system.collectio... That class was introduced in .NET 1.1 way before generic, still present in the most recent .NET Core 3.1.
They sometimes deprecate higher-level stuff, but very conservatively so. E.g. asp.net web forms (2002) is deprecated, while windows forms (also 2002) is still supported.
Forms designer is still broken on .NET 5, and it might not make it to the final release.
Yup, for better or for worse, Java will be the COBOL of the 21st century.
Aside from that, the average 21st century developer would have a meltdown trying to use C.
Java is stable, and evolves with a huge amount of thought (they employ theorists to model the impact of changes to the Java language even.)
The benefit of this is a long-term platform, and an excellent implementation. Due to this Java has become the platform where the majority VM research is done, which means Java has many excellent state-of-the-art garbage collectors and a JIT a level beyond that of C#.
Unfortunately this isn't enough to make up for the latency hit from not being able to directly stack allocate things like C# allows (especially with its recent addition of Span<T>).
Java does better than direct stack allocation - it does automatic scalar replacement instead.
To be fair, Java has a lot to recommend it. For one, there are, of course, an incredible number of packages available to build off of. But I find it incredible that the language that replaced finalizers with phantom references still says pointers are too dangerous for programmers.
JVM is not the best in all areas.
I guess that this is a question of taste.
What for you is "less verbose" for me is more confusing to read. I like to see the types as they complement variable naming. To avoid typing a few letters the code will for ever require me to double check the types with help of the IDE.
I have worked in medium sized corporate companies. The code base is quite big and one of the 20+ development teams may get transferred a project from another team (does not happens super-often, but it happens) or they may create pull-requests for bug fixes (this is more common).
Clear and easy to understand code is life saving. In one of the companies I worked for a Javascript team send a -1 instead of a "-1" the cost ramped up the hundreds of thousands of dollars and our clients were not happy about it. Rollback mechanisms were used as fast as our clients detected revenue problems on their own customers.
And the tests did not got the error as the values is used at the integration layer between our clients and us.
I see safety an increasing value as our programs control more and more money and more and more services. And, I have to admit, I feel more comfortable with more verbose code.
I have no experience with it at the corporate level. There, I have seen, it mixes a lot with .NET. So, I guess that the corporate equivalent to Java is "C#/.NET".
I spend some time several years ago with C# in Unity3D, thou.
I really liked the C# language. I found the Auto-Implemented Properties a neat compromise between encapsulation and verbosity (Verbosity has no value if does not add information).
Java is trying to be everything to everyone and that is a mistake. I liked Java more in the past, and I would have added just a few things from the past iterations of the language (e.g. Modules is a good idea that actually simplifies the language and moves much code to "frameworks" instead of being part of the core language).
C# seemed more focused on its initial style were Java is stretching all over the place.
var a = new ArrayList<T>();
not:
var a = o.getThings();
That is a very good point. I find the diamond operator more of my taste as it requires you to think if you want to expose ArrayList or List.
List<String> list = new ArrayList();
But, as you point, the second example removes information that will require to spend time to check types each time that someone reads the code. I do not like that.
I use auto-complete and I type quite fast, so, I do not see to write code as a problem. I spend most of my time understanding the functional needs, looking for better patterns or algorithms to implement performance-critical sections or finding names for exposed APIs that state clearly its function when I "write code". But, most of the time, I am just reading my old or other people's code to just change a few lines or decide on a local refactoring.
Here, the first is much less verbose, but still clear:
var x = new Dictionary<string, MyComplexType>();
Dictionary<string, MyComplexType> x = new Dictionary<string, MyComplexType>();
var x = y.GetStuff();Java type declarations can be 20+ characers - just scanning through the code and having to skip all that junk makes my eyes more tired reading through. Types are implicitly deducible when you know the codebase 90% of the time (and should be added when they are not), and if you don't know the context you will be slow no matter what.
Yes. When I was younger I worked in solo projects. I knew my code almost line by line.
In my last decade, in middle sized companies, nobody knows all the hundreds of micro-services code. And code changes while on vacation, that can be 6 weeks of the team working without you. That is not ideal, but in such a big code base it is difficult to have everyone reviewing all the changes on a single micro-service, impossible to have all 20+ teams reviewing all of each others code.
Different problems need different solutions and code styles, I guess.
Why do I mention? Because until now .NET Core still doesn't have anything like Swing across all supported platforms.
MAUI might do it (Xamarin renamed), or you might just get Blazor running on WebWidgets.
I rather have Swing if the alternative is running Blazor that way.
Not counting community toolkits here, just what is available out of the box.
- No checked exceptions
- Properties (I wish Java would add this to the core language instead of relying on things like Lombok as it shouldn't change the IR and really is just syntactic sugar)
- Partial classes. This really isn't in contrast to Java because Java has nothing like it. But it is a neat feature for partial code generation;
- LINQ. Java eventually added streams but last I checked it still had performance issues and IMHO LINQ is just cleaner;
- Conditional compilation. This is really a huge oversight. One of the huge benefits of the preprocessor in C/C++ was conditional compilation. It's great than C# included it. It's bizarre to me that Java hasn't.
- Async/await. Honestly I still find C#'s version of this more awkward than Hack's. Experience has taught me that whenever you spawn a thread, you've probably made a mistake as subtle mutlithreading bugs are the devil and cooperative multitasking like you have in Go, C# and Hack is usually far safer and sufficient most of the time. Still, C# is still better than Java here.
- C#'s reified generics vs Java's type erasure. I think it was the right decision to break backwards compatibility here (and I don't usually say this). This was pretty early too (IIRC generics were added in C# 2.0).
But all that being said, I still think Java has a large mindshare and install base than C# by a mile. it's not sexy so it gets less attention on HN but Java is still massive.
As for Kotlin? Much like Scala I see this as nothing more than a curiosity. Android developers seem to like it but I think it's a tiny fraction of Java still.
Java is massive for legacy reasons, but would be nice to have some statistics regarding new projects. The last two companies I've worked for had backend teams using Kotlin so I've been assuming this is also preferred by backend people. Could well be that this has was an anomaly though.
I mostly develop for Android so my own perception is obviously biased, as Java is pretty thoroughly erased from this world now.
Anything else on the JVM is nice to have, but isn't where all the goodies are.
Google has a special interest in getting rid of Java, hence Kotlin.
In fact, it is going to be fun to watch how they will keep up with the pace of the JVM, because when the majority of key libraries move to modern Java, many of them will stop being compatible with D8/R8, forcing Android developers to use pure Kotlin libraries.
Then JetBrains needs to think how to make use of Java libraries that use the new FFI, virtual threads, inline classes, generics, SIMD vector types, while keeping the language compatible with what ART is capable of.
See virtual threads vs async/await. Java's version is going to be better.
You can block the caller thread waiting for the task. Deadlocks are possible with this approach due to synchronization context shenanigans, but they’re easy to fix, VS debugger is quite good at multithreading.
Another method, you can run whatever dispatcher on your main thread, in modern .NET that’s usually Dispatcher.PushFrame.
Also, if the async method returns no values, you don’t need to change the call chain, you just need to catch and handle exceptions.
I feel like a lot of languages these days trend towards "kitchen sink" languages that toss in everything and the kitchen sink in the name of clean looking code. IMHO this tends to sacrifice language elegance. This is probably why I tend to like languages like Java/Go/Clojure.
The C preprocessor can make it way to easy to break code, for example when it is used for feature flags and/or multi-platform support. If you have N feature flags, you have to compile 2^N different programs. Multiply by M for supporting M platforms.
It also makes it impossible to check whether source code can be compiled. The text inside a
#ifdef FOO
...
#endif
Dependency injection can be made messy, too, but that takes more of an effort. You can also test injected code in isolation. That may take some effort, but those preprocessor messes only could be tested as part of the entire product.
As I said, I can see why they wanted to get rid of that. Not adding a same replacement may not have been the best choice, but I am not sure of that. Programming culture also had to change, and that sometimes requires drastic action. Apple also did that in the Mac by not providing any text mode (forces programmers to make windowed applications) and by removing cursor keys from the first keyboard (forces programmers to provide a good mouse interface)
I rely miss checked exceptions on .NET, specially with libraries that provide zero documentation about their exceptions.
Most things shouldn't even have getters and setters apart from your @Entity classes.
If we look at programming languages as tools, it makes sense for them to get out of date and new ones taking their place, with all the lessons learned.
So its possible that programming languages like C++ that keeps extending their own life through adding features (while keeping weaknesses), will ultimately cost the community/industry more in the long run.
They did add those features eventually (Java 8) - about 8 years behind C# (since C# 3.0)
Part of me thinks that this is how it should be. Extending a language constantly while providing backwards compatibility can lead to some awkward syntax too.
Just gonna drop this here: Nicolai Josuttis “The Nightmare of Initialization in C++” [0]
But of course, I'm sure Oracle is a big reason too.
People put scare quotes in seemingly at random these days - are you suggesting it's possibly not their strategy and actually they're lying? What do these scare quotes mean?