Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don’t call it a comeback: Java is still champ

github.com

Post reply on HN
Print view View original

341–350 of 557 posts

Re: Don’t call it a comeback: Java is still champ

#341

Post by nick__m »

pwinnski wrote: post #291
ralmidani wrote: post #260

Java was actually not bad for me in class when learning software design and data structures, but soul-crushing to work with in the real world. Mindless, unnecessary use of getters/setters, interfaces, and AbstractFactoryImpls. Hiding almost every piece of functionality behind 10+ layers of indirection. Dependency Injection with Spring. They all make it feel like Java draws folks who actually __enjoy__ writing bloated…

I don't think this is an issue with Java, it's an issue with Spring. I'm baffled by the popularity of Spring.

Old school xml based Spring is horrible and if that was your only exposure, I understand your aversion.

But spring-boot has an almost zen like quality once you get that it favor convention over configuration. When I was a Java developer, I'd usually use spring-boot with the following dependencies to make the experience better:

- lombok: to generate the boilerplate: constructors, getters, setters, equals, hashcode...

- mybatis-spring-boot-starter: mybatis is a sql resultset mapper, you write the sql and it maps the results. I find that ORM like Hibernate or Eclipselink are a complexity trap: easy things are really easy but hard things are incredibly complicated, mybatis avoid that.

Re: Don’t call it a comeback: Java is still champ

#342

Post by geodel »

i386 wrote: post #271
ralmidani wrote: post #260

Java was actually not bad for me in class when learning software design and data structures, but soul-crushing to work with in the real world. Mindless, unnecessary use of getters/setters, interfaces, and AbstractFactoryImpls. Hiding almost every piece of functionality behind 10+ layers of indirection. Dependency Injection with Spring. They all make it feel like Java draws folks who actually __enjoy__ writing bloated…

All my new Java projects don’t use spring for that very reason. Nothing wrong with the new keyword.

Excellent!. Its good to hear about places where Spring nincompoops do not shove their crap framework down everyone's throat.

Re: Don’t call it a comeback: Java is still champ

#343

Post by dwaite »

falcolas wrote: post #34
throwawaymaths wrote: post #23

Earlier quoted context omitted.

Corollas don't come with all sorts of weird (now aging) buzzword-driven preferences like nudging you towards xml, factories, etc.

Personal rant: I've never understood the hate towards XML. It's a practical and flexible markup language that does not depend on whitespace or quoting every bloody thing. Plus, every markup language invented since has had to re-invent XML things that, surprise surprise were actually needed. Paths, schemas, comments, etc. I get frustrated with JSON because of things I could do in XML that I can't do in JSON without br…

Formats are designed for a purpose.

XML was built for a very limited set of purposes - to create a common base markup for various document formats. It was almost purpose-built to create something like XHTML - a mixed content system where you can do semantic decoration of textual media content, and extend it with things like SVG and MathML.

The problem is that it was _not_ built as a cross-platform data structure interchange format, but it wound up being used for that way more than its intended purpose. This was partially because of the extensibility story - companies could agree on a common base format, and define their own extensions to add additional data. However this was a pain - the XML tooling was often generic to support both kinds of usage, and the language itself was ambiguous because the expectation that the underlying document being described would have document-specific clarifications on use and tooling.

JSON is an object notation - it is a way to transmit hierarchal data. It has limited extensibility in the sense that you can define rules for data processing, such as 'ignore things you don't understand' or 'name things which are not agreed upon with URI rather than short names'.

Trying to use JSON to represent the content model of HTML will just cause pain, because thats not what it was built for. It isn't even re-inventing things from XML, it is just cramming a square peg in a round hole.

Neither format was built to be a configuration file format for users to hand-edit config. As a result, they suffer limitations in their syntax and features (closing elements in XML, quoted property names and lack of comments in JSON being the most commonly cited). TOML is one popular choice for this sort of use case.

Re: Don’t call it a comeback: Java is still champ

#344

Post by tejinderss »

babypuncher wrote: post #327
runevault wrote: post #278

Earlier quoted context omitted.

I thought Anders was full time on Typescript these days? Certainly his fingerprints are all over c# from being in charge for a long time though.

He still acts as the lead architect on C#, in addition to working as the core developer on TypeScript.

Nope, Mads Torgersen is lead architect on c# nowadays, Anders is 100% on Typescript's typechecker.

Re: Don’t call it a comeback: Java is still champ

#345

Post by SlipperySlope »

plainnoodles wrote: post #177
sushisource wrote: post #139

Earlier quoted context omitted.

> This combined with the fact that Java doesn't crash Huh? Doesn't crash in what way vs. C? I can still deref a null pointer and blow up. Java's perfectly fine, and I have no idea why you'd write C any more, but if you care about (extreme) performance and not crashing, Rust seems the obvious modern choice here.

One of the weird things about Java is that there's a big low-latency/high-performance Java community around that stems from Island (now owned by NASDAQ) using Java as the platform/language for their matching engine. Then, talent flow from that team resulted in lots of proprietary trading shops using Java to low-latency trading/order execution.

No post body was provided.

Re: Don’t call it a comeback: Java is still champ

#346

Post by discreteevent »

kentonv wrote: post #274
bullen wrote: post #27

The only problem Java has is experienced C programmers don't build servers from scratch with it yet. Once they take that responsibility, the debate will be over because: "While I'm on the topic of concurrency I should mention my far too brief chat with Doug Lea. He commented that multi-threaded Java these days far outperforms C, due to the memory management and a garbage collector. If I recall correctly he said "only…

Oh, please. I once worked on a Java-based server at Google that had to answer requests with millisecond latency. In order to achieve this, the server had to block garbage collection most of the time. Periodically, each instance of the server would ask the load balancers to stop sending requests to it, so that it could then safely run the garbage collector, and then ask for traffic to return. We likely would not have…

> requests with millisecond latency

You're getting into hard real time territory there. That's a different universe and will require special considerations even in C. I think it's fair enough for people to discuss server performance and assume that the context is our normal programming universe.

Re: Don’t call it a comeback: Java is still champ

#347

Post by gavinray »

kaashif wrote: post #338
gavinray wrote: post #240

Earlier quoted context omitted.

Modern Java has first-class functions, pattern matching with structural binding, records/pure immutable data classes, the whole 9 yards: static void main() { BiFunction add = (Integer x, Integer y) -> x + y + 5; Integer result = addTo(10, add); Integer result2 = addTo(10, (x, y) -> x + y + 5); } static Integer addTo(Integer acc, BiFunction addFn) { return addFn.apply(acc, 5); } Integer eval(Expression e) { return swi…

> records/pure immutable data classes Example? As far as I know, Java has final, which means that particular reference can't be re-assigned, but the object referred to remains mutable. You have to resort to e.g. having separate immutable and mutable interfaces or whatever to restrict a someone from mutating your object. If you want an immutable data class more than one level deep, I don't know if there's a convenient…

JDK 17 record classes:

  record User(String name, Integer age, Boolean isActive) {}
https://docs.oracle.com/en/java/javase/18/language/records.h...

Re: Don’t call it a comeback: Java is still champ

#348

Post by gavinray »

dunefox wrote: post #302
gavinray wrote: post #240

Earlier quoted context omitted.

Modern Java has first-class functions, pattern matching with structural binding, records/pure immutable data classes, the whole 9 yards: static void main() { BiFunction add = (Integer x, Integer y) -> x + y + 5; Integer result = addTo(10, add); Integer result2 = addTo(10, (x, y) -> x + y + 5); } static Integer addTo(Integer acc, BiFunction addFn) { return addFn.apply(acc, 5); } Integer eval(Expression e) { return swi…

This is destructuring but not pattern matching.

How is this not pattern matching?

In Scala, I would write:

  enum Expr:
    case INT(value: Int)
    case ADD(left: Expr, right: Expr)
    case MULT(left, Expr, right: Expr)
  
  def eval(e: Expr): Int = e match
    case INT(value) => value
    case ADD(l, r) => eval(l) + eval(r)
    case MULT(l, r) => eval(l) + eval(r)
This "match" syntax is the example given in the Scala docs for Pattern Matching:

https://docs.scala-lang.org/tour/pattern-matching.html

The fact that Java happens to use "switch" instead of "match" is one of syntax, not semantics.

JDK 17/18 introduces Sealed Types, which allow you to create ADT's

  sealed interface Expr {
    record INT(Integer value) implements Expr {}
    record ADD(Expr l, Expr r) implements Expr {}
    // etc
  }
When you "switch" over sealed types, the switch expression is exhaustive if all members have branches and requires no default case + is typesound.

Re: Don’t call it a comeback: Java is still champ

#349

Post by kentonv »

kelnos wrote: post #332
kentonv wrote: post #274

Earlier quoted context omitted.

Oh, please. I once worked on a Java-based server at Google that had to answer requests with millisecond latency. In order to achieve this, the server had to block garbage collection most of the time. Periodically, each instance of the server would ask the load balancers to stop sending requests to it, so that it could then safely run the garbage collector, and then ask for traffic to return. We likely would not have…

> I once worked on a Java-based server at Google that had to answer requests with millisecond latency. That's... not really normal, though, and sounds like the exception that proves the rule. For the vast majority of applications, Java will perform better, be easier to develop, and be safer to run, than an equivalent server written in C or C++. At my previous job we used to run realtime audio through a Java server (R…

> But I would not call writing distributed network servers "systems engineering",

I would agree that a web application server is usually application engineering even if you are running 1000 replicas of it. I would not write these in C++. (Well that's a lie, I probably would but I would admit it was a terrible idea.)

On the other hand, the container engine that orchestrates the web app server is systems engineering, as is the database it talks to for storage.

Re: Don’t call it a comeback: Java is still champ

#350

Post by kentonv »

discreteevent wrote: post #346
kentonv wrote: post #274

Earlier quoted context omitted.

Oh, please. I once worked on a Java-based server at Google that had to answer requests with millisecond latency. In order to achieve this, the server had to block garbage collection most of the time. Periodically, each instance of the server would ask the load balancers to stop sending requests to it, so that it could then safely run the garbage collector, and then ask for traffic to return. We likely would not have…

> requests with millisecond latency You're getting into hard real time territory there. That's a different universe and will require special considerations even in C. I think it's fair enough for people to discuss server performance and assume that the context is our normal programming universe.

Of course! There are plenty of use cases, including server use cases, where Java is a great choice.

But I was reacting to bullen's assertion that "To use anything else on the server is madness.", and to the rather exaggerated performance claims.

Post reply on HN