>Because development that happened in 1994 is really relevant today.
1994? We still depend on tons of features, infrastructure, and techniques developed in the 60s and 70s.
Heck, most of what the JS world considers "state of the art" was already available in 70s languages.
As for the snark, first, the innovations the parents refers to is not "JavaBeans, Java Server Pages, and Java Server Faces", but stuff like rock-solid GCs, tooling, and so on.
And even techniques on the level of "JavaBeans, Java Server Pages, and Java Server Faces" are only going to be resold to several other languages. The JS worlds keeps on piling Java (or older) techniques and syntax.
Heck, they just re-invented the "private instance variables" (with an ugly hash syntax) on their latest efforts...
The contention was that other languages had a “lot to catch up” with Java because it’s been around for 25 years. So how haven’t other statically typed languages “caught up”?
In fact, Java is so far behind C# with true Generics, LINQ - not the syntax the entire linq expressions -> expression trees -> runtime providers that can parse the trees and translate it to a destination syntax, etc. it’s laughable. Can anyone say honestly that Oracle has been a good steward over Java or that it has improved as fast as any modern popular language?
And the “tooling” around Java is the main reason that when I had a choice between C# and Java in the mid 2000s, I chose C#. Heck, the Visual Studio 97 was better than most Java tooling is today.
Yeah I played around with the early VB like Java IDEs like JBuildsr. Java’s IDE’s have never been strong points. Neither have the XML is king mindset.
Here we go again with "true Generics". Type erasure makes interop easy (for an almost insignificant cost), including with Java prior to generics. But that's also what makes different languages on the Java platform interop so well (contrast with the CLR, where this is not the case; they've baked variance into the runtime and are paying a high price for that decision). If Java had baked their type system into JVM, Scala, Kotlin, Groovy would have to dance around that. Haskell, for example, erases all types, not just type parameters (well, sort of; it does reify the constructor tag/discriminator, which corresponds to type information in Java), and people get fancy with types in Scala, too. The only real annoyance erasure brings is that you cannot overload a method with another that erases to the same type.
All in all, The JVM is leading not only CLR on all fronts, but pretty much any other runtime. C# compilers and GCs are at least a decade behind Java's. You may argue on how important those things are compared to other tradeoffs, but those are the areas where Java was designed to compete at, and those are the areas where it is leading by a wide margin.
Edit: when Java was first introduced, its original designers stated their intention to construct a conservative, low-innovation frontend language, and a high-innovation runtime. In many respects, .NET has the opposite design. You may prefer one or the other and that's OK, but it makes comparing the two on any single aspect very problematic. Of course Java won't keep up on language innovation compared to .NET, and of course .NET won't keep up with Java on runtime innovation -- they each choose to get their competitive advantage in different aspects.
Seeing that generics have been around since 2005 in C#, I think the .Net community has had plenty of time to work around the incompatibilities....
There are other languages that support CLR besides C# and they manage to “work around” generics.
All in all, The JVM is leading not only CLR on all fronts, but pretty much any other runtime. C# compilers and GCs are at least a decade behind Java's. You may argue on how important those things are compared to other tradeoffs, but those are the areas where Java was designed to compete at, and those are the areas where it is leading by a wide margin.
Also, I am very interested to see new benchmark results once AOT SubstrateVM will be more widely adopted in JVM community. Demo: https://youtu.be/MN6jNIwl2FQ?t=1136
RedHat already working on a framework which takes full benefit of that: https://quarkus.io/
All in all, with upcoming value types, SubstrateVM adoption, fibers and nice languages improvements like records, future is brighter than ever for Java.
What exactly in BoyRobot777's comment (which I said I agree to) calls for benchmarks to be proved?
Nowhere are benchmark results taken for granted as faster or anything. Grandparent says: "Also, I am very interested to see new benchmark results once AOT SubstrateVM will be more widely adopted in JVM community."
I simply agree with the statement made: "All in all, with upcoming value types, SubstrateVM adoption, fibers and nice languages improvements like records, future is brighter than ever for Java." -- so, I responded to your comment which seemed to be skeptic of that (and accusing the parent of working for Oracle).
If you were referring to someone else and some other comment, why post your comment as a response directly under BoyRobot777?
>In fact, Java is so far behind C# with true Generics
It's not "true Generics" it's a different generics tradeoff (tradeoff not just for backwards compatibility sake).
And LINQ is not that important in the grand scheme of things. Are Haskell, CL, or Smalltak also "far behind" C# for not having LINQ? It's just another feature. You can most of the same things with a fluent interface, streams, and functional composition, and without straying off the regular syntax of the language into a LINQ DSL.
Besides, last time I've checked, Java still has the performance edge over C#.
LINQ itself is a big deal because of what it enables.
A simple LINQ expression can be passed around an translated on the fly by various providers. The same expressions can be translated to Sql, Mongo, regular IL, etc.
And no LINQ isn’t just syntax.
Last time I checked neither SmallTalk or Haskell are taking the world by storm...
Haven’t Java proponents been claiming Java was going to be fast for over two decades?
>A simple LINQ expression can be passed around an translated on the fly by various providers. The same expressions can be translated to Sql, Mongo, regular IL, etc.
The same can happen with a simple abstract expression in native syntax (in fact tons of tools in all languages that do that). LINQ just gives you a standardized built-in DSL for that -- but nothing you can't build yourself with the language's main syntax. Heck, LISPs have been able to do the same shit for half a century.
>Last time I checked neither SmallTalk or Haskell are taking the world by storm...
Yes, they only made a dent with the smarter developers.
Still, C# isn't taking the Linux world by storm either, and it's nearly irrelevant on mobile too, so there's that.
>Haven’t Java proponents been claiming Java was going to be fast for over two decades?
Java has been fast for over 15 years now, so not sure what you're getting at here. Faster than C# as well, so there's that too.
The same can happen with a simple abstract expression in native syntax (in fact tons of tools in all languages that do that). LINQ just gives you a standardized built-in DSL for that -- but nothing you can't build yourself with the language's main syntax. Heck, LISPs have
Okay so where is it? What language besides some .Net based languages allows me to take the same query expression and have it interpreted differently based on the provider and allows me to switch out an RDMS or Mongo for example without changing the calling code?half a century ago I wasn’t even born (about 5 years later). Saying Lisp did it 50 years ago is about like Mac users bragging in 2019 that they had a GUI before PCs.
As far as LISP, what are the job opportunities like in 2019?
Yes, they only made a dent with the smarter developers.
Can I make money with those languages?
Java has been fast for over 15 years now, so not sure what you're getting at here. Faster than C# as well, so there's that too.
So just in case I want to work for the one anecdotal company that uses Lisp I’ll keep that in mind...
But seeing that I like the optionality of working for any of the dozens of companies that have job openings continuously for JavaScript, C#, C, C++, and even Python, I think I’ll stick with those....
There is a big difference between choosing the less popular but still marketable technology and someone doggedly sticking with a technology that has being put in maintenance mode by the vendor or in the case of Lisp, a minuscule market.
afaik c#'s "true generics" as you call it imposes a runtime cost due to code generation because the compiler doesn't necessarily know all specializations aot. haven't looked into it in a long time though.
as far as ides go, i vastly prefer intellij to visual studio.
Eclipse was slow and had the usual non native Java smell that all cross platform GUIs have - especially on computers back then. But even now, Eclipse is sluggish compared to Visual Studio.
>Eclipse was slow and had the usual non native Java smell that all cross platform GUIs have
Actually Eclipse used a native GUI toolkit (Standard Widget Toolkit), backed by native widgets plus a few custom draw ones (like 100% native apps also resort to for custom stuff).
So, if it smelled "non Native", it wasn't because of Java.
There were no "performance penalties" to speak of related to the GUI layer. IDE UI is not doing anything crazy to be performance bound. And I've (like millions of others) have used it in 2003-era PCs, with spinning platter HDs.
What indeed was, were some penalties of the GC kicking in (unrelated to UI widgets). Still nothing a .NET app wouldn't have (and I've used SharpDevelop as well back in the day).
Considering that we're watching the javascript ecosystem slowly fumble its way through reinventing the technologies of the past, I'd say 1994 is pretty damn relevant.
Types. Clumsy stand-ins for synchronous behavior like async/await. Transaction managers. Threads. I'd add immutability and functional programming but really that's rediscovering technology from the midcentury.
Yes I know they exists. But my definition of “good” is does look and work like a native app? That’s not true for anything Java based or Electron or .Net.
They are far from catching up on compilation, GC and low-overhead observability technology. Those developments didn't happen in 1994; they have been happening continuously over the past 25 year (e.g., in the past few years we've seen ZGC, JFR and Graal), where Java is still far ahead of the pack.
I don't know where you're getting the 1% -- in some of those benchmarks it's much higher (and remember that Scala and Kotlin are also Java -- they rely on the same compilers, GCs and monitoring; they just replace the frontend compiler, which is less than 10% of the JDK). Also, the benchmarks are very simple, and hardly exercise the platform's power. And they don't measure other capabilities at all. For example, Go may not be far behind on performance, but its observability is shit, it doesn't have good dynamic linkage, and other important features.
Again, I am not saying that other platforms may not have advantages elsewhere (e.g. lower memory footprint, no warmup), but when it comes to compilation, GC and observability, Java is about a whole technological generation ahead.
You seem to think Cobol is somehow superseded now. In fact it runs more critical infrastructure, and even sees more lines per year added for those kinds of systems, that JS does.
