Live data from Hacker News

Java 21 makes me like Java again

wscp.dev

601–610 of 777 posts

Re: Java 21 makes me like Java again

#601

The biggest problem with Java is... the walled garden, the snob society, the elitist, exclusive culture. Go isn't like that, or at least wasn't when G+ was still around. Nowadays I don't get in touch much with people, but when I create issues Go people are usually not as unfriendly as Java/JVM people.

Imo problem with Java is... JVM because it's quite a resource intensive application itself, memory usage is orders of time magnitude worse than most of the language I've used.

Interesting. A Spring Boot webapp (with the runtime dependency injection framework, etc. etc.) serving some static content and exposing some REST endpoints works fine with 32 MB RAM. Is it really orders of magnitude more than other languages, e.g. will a Go-based webapp consume less than 300 kBytes of RAM?

Re: Java 21 makes me like Java again

#602
道生一,一生二,二生三,三生萬物。萬物負陰而抱陽,沖氣以為和。

The Function gives birth to the Unit type. The Unit type gives birth to the Boolean. The Boolean gives birth to the Value type. The Value type gives birth to the Top type. Each Top type contains 0s and 1s, thereby bringing harmony to the computation.

Re: Java 21 makes me like Java again

#603
post #547

Earlier quoted context omitted.

This is code with async/await: async fn read_file(filename): f = await os.open(filename) let data = f.read() await f.close() return data this is equivalent code with green threads: fn read_file(filename): f = os.open(filename) let data = f.read() f.close() return data As you can see, async/await is pure syntactic noise, it doesn't convey any important meaning.

Async enables clear contract for a type that represents a delayed result. Better implementations offer eager execution and allow to easily interleave multiple concurrent futures/tasks, like C#. Green threads on the other hand are a workaround to deal with blocking for the most trivial case of cooperative multi-tasking, offering little beyond that.

with green threads, every result is "delayed" and available exactly when you want it (i.e. as indicated by naive reading of the control flow in code)

> eager execution, interleave multiple concurrent tasks

green threads give you that for free

> deal with blocking

blocking is an implementation detail; both async/await and green threads can be implemented on top of either traditional blocking IO, or callback/non-blocking IO

I'd be even happier to discuss concrete code blocks / examples, that's where the superiority of green threads truly shines

Re: Java 21 makes me like Java again

#604

The title of the blog post is IMO a poor choice. The (hidden) subtitle of the post is "Algebraic data types in Java" which is much more descriptive of the content. A better title would have been "Algebraic data types in Java 21". Perhaps because of the title, many/most of the comments here are off-topic. I was hoping to see more discussion about algebraic data types, strengths and weaknesses of the Java implementatio…

I did title it that way at first but ended up changing it at the last second, ended up shunting it off course.

Re: Java 21 makes me like Java again

#605

Earlier quoted context omitted.

golang is a simplistic language which lacks the modeling capability of Java, so it won't do well in large business code.

TIL that projects like terraform are - apparently - not "large business code".

You can write basically anything in any Turing complete language, doesn't mean it's a good idea.

Re: Java 21 makes me like Java again

#606

The title of the blog post is IMO a poor choice. The (hidden) subtitle of the post is "Algebraic data types in Java" which is much more descriptive of the content. A better title would have been "Algebraic data types in Java 21". Perhaps because of the title, many/most of the comments here are off-topic. I was hoping to see more discussion about algebraic data types, strengths and weaknesses of the Java implementatio…

Yes, I'm also not really sure I want to see algebraic types in Java even though I would prefer if a language that focused on algebraic types was more popular. All the existing Java code doesn't go away, so is it really going to be nicer to have code like this mixed randomly into that?

Of all the features most Java devs (and ex-Java devs) desire, algebraic types are near the bottom.

How about intersection and union types? (NO, sealed classes are not a substitute for unions).

But, yeah, in my view JDK 21 is a a disappointment. I rarely want pattern matching, but I would like properties please and records are nice, but actual tuples are more useful. Etc.

Re: Java 21 makes me like Java again

#607
post #506

Earlier quoted context omitted.

I've seen this response before, but why on earth would we be using C# if not for its included batteries? I can't imagine a world where we would have chosen C# to write an API unless there were some specific benefits, and while I may be wrong to assume this, I don't think I've ever met someone who would. Not so much because there is anything wrong with C# or .Net for that matter, it's okish, it's just well... Honestly…

I agree with you that the choice of language should not be based solely on the language itself, but also on the ecosystem it provides for the task you need to complete. I was just pointing out that your critique was about the included batteries, not the language. Every language has some bad libraries in its ecosystem.

The point I was trying to make was that C# has nothing but bad libraries in it's ecosystem. I've worked with quite a lot of languages and I've never experienced anything like it. Well, obviously Node has an "interesting" environment, but the flip-side is that it's very easy to work with what isn't there. C#'s libraries are like half-charged batteries that you won't realize are only half-charged until it's too late.

Re: Java 21 makes me like Java again

#608
post #519

Earlier quoted context omitted.

I understand what you're recommending, and I've seen Bob Martin talk about it extensively (polymorphic dispatch instead of instanceof), but it's something I disagree with. To do this kind of polymorphic dispatch, objects have to deal with multiple concerns within themselves . In a video game, a Car might have .render(), .collide(), .playSound(). Later on you can add a Dog, which also has those three methods, and you…

The OO solution is to have a PhysicalObject class that dog and car both inherit from (or use via composition).

Then there's even more scattering around of the logic.

Good way:

  PhysicsEngine {
    List entities;
    doCollisions() {
      // Logic involving instanceof
    }
  }
Bad way:

  PhysicsEngine {
    List entities;
    doCollisions() {
      // Delegate to whomever.
      entities.forEach(e -> e.collide());
    }
  }

  Dog {
    collide() {
      // What the hell can I do here?
      // I don't know about the rest of the world
    }
  }

  Car {
    collide() {
      // What the hell can I do here?
      // I don't know about the rest of the world
    }
  }

Worse way:

  PhysicsEngine {
    List entities;
    doCollisions() {
      // Delegate to whomever.
      entities.forEach(e -> e.collide());
    }
  }

  Dog : PhysicalObject {
    collide() {
      super.collide();
    }
  }

  Car : PhysicalObject {
    collide() {
      super.collide();
    }
  }

  PhysicalObject  {
    collide() {
      // Not only do I not know about the rest of the world
      // I don't even know how *I* collide, because what am I?
    }
  }

Re: Java 21 makes me like Java again

#609

The biggest feature in Java 21 is the release of Virtual Threads: https://openjdk.org/jeps/444 For some reason, this is missing from the article. If there was any feature that would sway existing Golang developers to switch to Java, it would be this. It would perhaps also convince the haters of the reactive-style concurrency patterns.

[deleted]

Re: Java 21 makes me like Java again

#610
post #424

Earlier quoted context omitted.

I'm not sure if your question is rhetorical, but Go doesn't have the concept of compiled library that you can link to another binary. So in Go you make available the library's source code, and the end-user will download it at build time, or vendor it in the source tree.

Which is a non starter for businesses that don't ship source code.

Businesses that want to sell libraries without a source code license can ship APIs.
Post reply on HN