Hacker News Reader

Comment by exabrial | Hacker News Reader

The JVM itself is incredible, all the advantages of a fully native language with nearly none of the downsides, while being basically "third place" in speed behind C/CPP, and maintaining a gap in performance between the next closest competitors. The JVM also can do party tricks that no other language can with instrumentation and runtime class definitions.

I certainly appreciate the amount of R&D Oracle is investing into the Java Virtual Machine. While I use the open source version of the JVMs, I also wouldn't mind also kicking some cash into the back into the devpool. Business with Oracle does seem to be a bit of a poison pill unfortunately. Leaves us "small budget" firms in a pickle. We know the ecosystem needs funding, but the option to engage Big Red is not enticing.

View on HN

I really wish Java had been like 5 years ahead on its modernizing push. That 10 year gap between 5 and 8 where the language __barely__ changed, while competitor languages were blasting, were just killer. Some might argue the reason the 8+ renaissance has been so successful is because it let other languages beta test, and Java took the winning ideas. Maybe so. But it gave Golang time to get big, which I like a lot less than Java. Especially when people try to use it as anything but a scripting language for grpc and a runtime for protobuf.

But I think with virtual threads, esp when they work with synchronized right, will finally put Java back on top of Go. People complain about Java, but imo Java's problems are mostly accidental and acknowledged, and they do often get improved or fixed. Whereas Go seems to mostly be happy with how it is exactly right now, and are loathe to improve the many pain points. So much gocode is needlessly obtuse, and it's not like the obtuseness actually accomplishes their goal. I've still seen just god-awful Gocode, with layers and layers of interfaces in between you and getting anything done. Very java-esque, despite their OOP resistance being specifically targeting not falling prey to Java's propensity for towering class hierarchies.

Well there was also like 10-15 year period where Java was taken over by enterprise factoryClassFactoryFactoryClassFizzBuzz architectural cancer that really made things suck as a want to be user of the language.

If you just stuck to the core language and the JVM, it's kind of always been a nice place to code even if the language was changing glacially.

Where can I learn about modern Java like you describe? I only remember Java from the days of "enterprise factoryClassFactoryFactoryClassFizzBuzz architectural cancer" and I hate the language due to that old memory, but I'm willing to try again. A lot of companies are using it in the industry I'm in, and it would be worthwhile to learn, but searching Google for Java resources is as much cancer as the enterprise stuff is.

Your question seems odd to me. You had to learn to write AbstractFactoryFactoryService. Just forget it? You don't need a book.

If you're used to writing nice concise code in other languages, just keep doing that, but in Java.

Exactly. I've been using Java since 2000, and I haven't once written an AbstractFactoryFactoryService. To be fair, I skipped over early versions of Spring.

The ecosystem rewards inheritance and patterns. The language is and always was highly opinionated about OOP which is a flawed paradigm.

The Java ecosystem is vast and there is very little you can say about it generally.

It's trivially easy to write Java programs without (ab)using inheritance. It's trivially easy to write Java programs in a functional style. There are countless libraries that will provide just about any programming interface you like, the only hard part is picking.

This is the classic example: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

I've tried to follow along with it, but man I just can't - it's that crazy. It does work though

I haven't used it myself, but I've heard good things about Spring Boot.

For other stuff I usually just write in a dialect I like to use, and be very selective about libraries and other bits I use. It's fortunate that the standard library isn't very ClassFactory and is pretty batteries included so you can get a lot done without too much fuss.

In many ways it's not terribly dissimilar to how one might approach using C++ or Perl or any other big language with lots of different ways to do things that you can pick and choose from.

Good things eh? The simplest Spring Boot program (assuming you can handle maven after this). The fact that Spring Boot is the end result of lot of de-FactoryFactoryization of Java shows how god awful standard programming in Java is.

  package com.example.hello;

  import org.springframework.boot.SpringApplication;
  import org.springframework.boot.autoconfigure.SpringBootApplication;

  @SpringBootApplication
  public class MainApplication {
      public static void main(String[] args) {
          SpringApplication.run(MainApplication.class, args);
      }
  }

  //controller file
  package com.example.hello;

  import org.springframework.web.bind.annotation.GetMapping;
  import org.springframework.web.bind.annotation.RequestMapping;
  import org.springframework.web.bind.annotation.RestController;

  @RestController
  @RequestMapping("/api")
  public class HelloController {
  
      @GetMapping("/hello")
      public String sayHello() {
          return "Hello, World!";
      }
  }

Even C++ is better than this!!

  #include "crow.h"

  int main() {
      crow::SimpleApp app;

      CROW_ROUTE(app, "/api/hello")
      ([]() {
          return "Hello, World!";
      });
  
      app.port(8080).multithreaded().run();
  }

Peanut gallery comment is C# because while you can do the old "enterprise factoryClassFactoryFactoryClassFizzBuzz architectural cancer" it doesn't fight you when you try not to.

Want to pass a pure function that takes structs as arguments around, sure.

The JVM does not have ‘all the advantages of a fully native language’: fully native code does not need a runtime, or a garbage collector.

Some would say a garbage collector is an advantage a fully native language doesn't have.

??? There are lots of examples of this.

D, Common Lisp, Go. All natively compiled (or can be in the CL case) with garbage collection.

You can bolt a conservative GC onto things compiled by an ordinary C compiler.

https://en.wikipedia.org/wiki/Boehm_garbage_collector

I know HN is not the place for this (because Microsoft), but I really like C#.

The ecosystem has been MIT since 2016, and the last few releases have been solidifying the AOT proposition.

It just has so many features that allow it to compete with C/C++ on the low level, but it also provides exceptional high level niceties (which admittedly can be slow, some LINQ for example).

I know it's not fashionable, especially in a Linux-centric world, but I have used it extensively for many years (on essentially every platform), and it's lightweight (in most instances) and has the features and tooling to make development less stressful.

Every time I use Java, it just feels overwhelming and slow.

I like C# too, but both languages seem to perform pretty similarly in my experience. The biggest difference seems to come from third party libraries being more optimized in one framework than the other.

Once Project Loom receives some more love (I believe that's scheduled for the next LTS, Java 25) I'll be very interested to see how Java's green threads will compare to C#'s async/await. I think Java's model may help programmers write more optimal code easier, but only if they can pull off their scheduling improvements.

C# does have massive advantages when calling native code, though. Java FFI is always just kind of a pain and C# FFI is pretty much trivial.

Garbage collection is orthogonal to "native", by which I take you to mean compiled to native machine code as opposed to something like Java's bytecode compilation or an interpreted language.

Go, D, Common Lisp (implementation dependent), and others offer GC and native compilation.

If you count automatic reference counting like Objective-C's ARC, you can add it and Swift to the list of natively compiled languages with GC.

I don’t disagree, but I was responding to a claim that the JVM has _all_ the advantages of fully native languages. Fully native allows you to choose to have no runtime, or a garbage collector, and in some environments (realtime, OS kernel, AAA games) that is overwhelmingly the preferred option.

in Java you can turn off the GC completely

and you can also compile to native code

You can in theory turn off gc but in practice no one does this because nearly everything is written with the assumption that allocations will be cleaned up by the gc. The compiler has no switches to help you run in a non-gc’d state. At best you can control when you run the gc.

> nearly everything is written with the assumption that allocations will be cleaned up by the gc

zero garbage Java it is relatively common in algorithmic trading

> but in practice no one does this

that's funny, I could swear we do

> Fully native allows you to choose to have no runtime, or a garbage collector,

Are you quite sure of that? I think you're getting stuff mixed up here. AFAICS, a native-compiled language might very well have mandatory garbage collection. Not that any such language immediately springs to mind, and I'm not even sure any do actually exist, but surely they could exist. The concepts "native compilation" and "garbage collection" are, AIUI, orthogonal.

There were/are a bunch of Java to native compilers.

About the GC we can agree to disagree. But about the runtime check out GraalVM which compiles Java to fully native standalone executables.

The funny thing about GraalVM is that some workloads are actually slower because of some of the dynamic optimisations the JVM applies. Picking the right garbage collector can make a Java program execute faster than when precompiled to native instructions.

I'm sure the same would happen when writing C for the JVM. Tricks like dynamically rearranging/compressing pointers and altering structs to better suit the cache lines and data locality properties of the system code is running on can probably boost any major C program, but that's an incredibly complex change to a C program that the JVM just gives you for free.

Lots of languages that compile to fully native code still have a runtime and a garbage collector as a part of that.

I haven't used it, but does GraalVM Native Image take care of that?

https://www.graalvm.org/latest/reference-manual/native-image...

Java is 3-5x slower than compiled languages, with horrible and uncontrollable tail latencies due to garbage collection. The bytecode thrashes the icache and the language is overly abstracted and too verbose. You have to install a huge runtime to use it. Many frameworks abuse the language to make things monkey patched/non-obvious. There's a reason many projects are rewritten in native languages.

Java does have a place, however, for I/O bound workloads where developer productivity matters more than performance. You can write a lot of horrible code in Java very quickly.

> Java does have a place

in fact, most projects don't have the kind of performance requirements that would make native a necessity. I say, java should be the default, and native have a place.

Reply on news.ycombinator.com