Hacker News Reader

Hacker News

Comment by scarface74 | Hacker News Reader

Parent Full thread

scarface74

Because development that happened in 1994 is really relevant today.

How will these languages ever catch up with innovations like JavaBeans, Java Server Pages, and Java Server Faces?

View on HN

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

By what measurement? Have any specifics?

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

https://www.degruyter.com/downloadpdf/j/acss.2018.23.issue-1...

And Java still doesn’t have anything equivalent to LINQ.

F# does not have higher kinded types, because of CLR. So no, they don't manage "work around" generics.

Regarding measurements: https://www.techempower.com/benchmarks/

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.

Edit. Regarding JVM vs CLR https://news.ycombinator.com/item?id=15955685

And the only person who is saying that is so (with a lot of people disagreeing) is someone who “work[s] at Oracle on VM research”

Well, I agree, and I don't work at Oracle. So? Any other conspiracy theories?

Care to post benchmarks?

Benchmarks of what?

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?

> Also, I am very interested to see new benchmark results once AOT SubstrateVM …

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

In some cases, the faster program with OpenJDK does not seem to be the faster program with Substrate VM.

In other cases, the faster program with OpenJDK seems to fail with Substrate VM - maybe it needs something different on the command line?

Otherwise, the same program is shown for both.

Good luck running C# on the 100% OSes and hardware that runs Java

VS97 better than Eclipse, without additional plugins?

Alternative universe.

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.

Visual Studio doesn't run on UNIX, nor mainframes.

Even Visual Studio Code is more performant than Eclipse and you can create a Linux distributable of .Net and deploy to Linux from Visual Studio.

And before you say there are non Linux mainframes. Yeah I know - another dead end technology along with .Net framework and C++/CLI.

An Electron app! Only as joke.

And that not forgetting that VSCode doesn't do even 10% of what Eclipse or VS do.

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

And I guess neither were the performance penalties of both Java and the Interop layer compared to native C++ code?

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

There is always a penalty for JNI. Also Visual Studio has never been written in C#. But why ever Eclipse was dog slow - it was.

Visual Studio is mostly written in C# since the WPF rewrite with VS2010.

You should learn the history of tools that you so agressively argue for.

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

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.

Benchmarks?

Lisp work isn't common, but the YC founders did pretty well. I hope you're aware HN is a Lisp testbed.

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

So better keep up with Java, given the amount of job offers across the globe.

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.

Most benchmarks I follow show C# as faster than Java, or at worst tied, these days:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://www.techempower.com/benchmarks/#section=data-r17&hw=...

Disclaimers:

Microsoft employee

Nazgûl

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.

It’s a one time cost the first time you instantiate the type

https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

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.

We really are doomed to repeat history.

There is the little language called C# that’s been around for a minute.

It has such a wonderful cross-platform GUI.

There are no “wonderful” cross platform GUIs and that been true for over two decades.

I assume you're trolling at this point but if that's not the case then the Qt company would like a word with you.

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.

Now I am confused, after all isn't .NET the best for everything?!?

Might be, but that is surely one area where .NET loses hand down to Java.

Not to mention the fact that WP failed on the market, while Android strives.

Tell that to all of the Android OEMs that are losing money...

Even Google has only made less than $30 billion in profit on Android....(https://www.theverge.com/2016/1/21/10810834/android-generate...)

But yes there are cross platform GUIs for .Net.

https://www.hanselman.com/blog/CrossplatformGUIsWithOpenSour...

https://github.com/AvaloniaUI/Avalonia/blob/master/readme.md

Yeah they probably suck and don’t look are behave like native apps - but no cross platform framework does.

It is more money than .NET ever done on mobile.

Electron

I don’t think I’ve ever heard anyone say Electron is “wonderful”. Unless you like running battery draining, memory hogging, non native apps.

Running Electron apps anywhere is like running iTunes on Windows.

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.

Benchmarks?

https://www.techempower.com/benchmarks/

So 1% with a “25 year head start”?

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.

I was going by his posted benchmark. But correction,I had never heard of Vertx. It was 14% faster.

Reply on news.ycombinator.com