Live data from Hacker News

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

github.com

481–490 of 557 posts

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

#481

Earlier quoted context omitted.

Why write many lines of validation when one line can suffice? @Entity class User { @NotBlank String username; } // Use site public User addUser(@Valid User user) { ... } as opposed to class User { String username; public void validate() throws ValidationException { if (username.isBlank()) throw new ValidationException("username is empty"); } } // Use site public User addUser(User user) { user.validate(); // ... }

Code like this is expected in Spring https://hastebin.com/jevibugiqu.less . Literally all the classes I see are filled with annotations. Can we even write code in pure java without a single annotation ? Theres a lot of magic going on with annotation. It works great while it is running. God forbid there is some issue and we have to figure it out where all the magic is happening.

That is actually a JPA mapping for your persistence layer, which is one of the relatively few things where lots of annotations should be acceptable (except for the inevitable runtime problems due to foreign data mappings): https://en.wikipedia.org/wiki/Jakarta_Persistence

It's not even that bad, when you consider something like myBatis, which can be useful for cases where you need complex dynamic SQL for your models, but can also involve boilerplate if you don't have codegen: https://mybatis.org/mybatis-3/sqlmap-xml.html

Though in regards to service code and such, I agree, it can get out of hand and be a total mess sooner rather than later. Not being able to properly debug this magic is just the cherry on the top.

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

#482
post #285

Earlier quoted context omitted.

> In addition to being memory safe without a GC, the compiler also confirms that your code is threadsafe. No, not at all. Rust verifies that your code has no data-races . That is an absolutely tiny subset of all race conditions, that are simply not verifiable statically.

Data races, in my experience, are not a particularly small subset of practical race conditions, particularly in Rust which tends to shy away from unnecessary mutable aliasing. YMMV of course.

I absolutely love what rust does, and in practice in “ordinary programs” data races probably come up more often than other kinds of race conditions, I just wanted to express that one should still very much pay attention to concurrent code.

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

#483
post #288

Earlier quoted context omitted.

you really dont need redis if you have java. I see zero reasons to offload my datastructures via TCP, instead of have them locally. If need be, replicated them.

Redis has plenty of features your java program hasnt. Starting with reliability :)

>=your= java program hasnt.

Wonder why the jab; Personally I'd trust my own code more than redis'

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

#484

I've used Java my entire career and i'm fortunate for it. I appreciate how readable the code is (unlike my experience with Erlang, Haskell, etc), typically i don't have foundational issues in the web framework (once again had some with Haskell). Everything works, if I need to do low latency, there's great libraries and resources, if i need to build a simple internal tool, it can be done effortlessly. I think python i…

I believe it's unfortunate people judge the JVM ecosystem by Java. Scala and Kotlin are so much more attractive options if you write code for a living. Between this and the devolution from maven to gradle it's not a surprise junior developers are JVM-shy. I see companies downshifting to unmaintainable toys such as Python even in data engineering circles. It's really odd that mobile developers with Kotlin (and front-e…

Out of curiosity, what issues do you see with gradle given your statement about it compared to maven?

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

#485

Earlier quoted context omitted.

> I think it depends a lot on where you work and what sorts of projects you work on. Agreed, even if my experience has been the exact opposite of yours. I've seen Spring be used in my country a lot, although recently Spring Boot. On one hand, I really dislike how code is sometimes exchanged for annotations that cannot be debugged with breakpoints easily (unless you dig in to the code where the breakpoint is defined a…

> comments in Lithuanin As a polish-russian lithuanian I do read Lithuanian, russian and bits of polish but... it really is super surprising to see how people abuse unicode-encoded source code. Linux drivers with comments in Chinese are evil!

Translating foreign languages isn't that hard, thankfully, at least as long as the terms are written clearly enough and the language doesn't get too niche.

However, to me it feels like English should remain the "lingua franca" of working in ICT, since most mainstream programming languages are already geared towards English and most of the popular frameworks/libraries also adopt the language, in addition to most of the actual learning materials and books out there. Otherwise we'd soon run into the problem of lots of fragmentation and missing out on useful information.

Or just what we had in Latvia, where a bunch of scholars tried making "Latvian versions" of various English terms, to mostly confusing and useless results, since everyone knows the English ones but very few actually want to use the Latvian alternatives. For example, "DevOps" became "izstrāddarbināšana", which sounds kind of awkward and needlessly long even in our language.

I'm not sure how doctors would work across borders when there would be localized names for over 200 bones that they'd need to learn in each language. Or at what pace software/libraries would move forwards if even changing a simple message would require translations in thousands of languages (which are oddly an order of magnitude more plentiful than we have countries).

As a counterpoint to my own argument, domain code (for a particular system in a particular country) in the local language might sometimes be more convenient to use, rather than developers with insufficient English knowledge choosing the wrong translated terms or even letting typos sneak in. There was this presentation a while ago where someone from Germany I think talked about how the domain code is in their local language and seeing two languages mixed a lot in the same service/class was actually telling of a separation-of-concerns violation, which I found amusing.

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

#487
post #306

Earlier quoted context omitted.

It's not about turning it off. You just don't allocate on the hot path.

Some people choose to do neither! https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-...

> This is because Zing uses a unique collector called C4 (Continuously Concurrent Compacting Collector) that allows pauseless garbage collection regardless of the Java heap size.

This is incorrect. Firstly, C4 triggers two types of safepoints: thread-local, and jvm-wide. The latter can easily go into the region of ~200 micros for heaps of ~32GB even when running on fast, overclocked servers. Secondly, the design of C4 incurs performance penalty for accessing objects due to memory barriers. This impacts median latency noticeably.

You might not believe me, but ask Gil and he'll openly admit it. This article was written by someone who:

1) doesn't know how C4 works

2) doesn't analyze relevant metrics from their JVMs

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

#488
post #330

Earlier quoted context omitted.

If Java had isolated heaps then C++ would become redundant in every aspect except memory efficiency.

What are the advantages of isolates vs running multiple JVM processes other than avoiding slightly higher memory usage and some small context switch overhead on IPC - which should be negligent as presumably communication between isolated components would be coarse grained?

I can give you an example: in the Bitwig digital audio workstation, you can choose whether external third-party plug-ins (small audio processors) are in the host process or in external processes communicating through shared memory. I just tried with a very simple plug-in (3 band EQ) to see how much I can stack in either case:

- In the "in-process" case I can stack ~1400 plug-ins on a single channel before I hear a crack in the sound.

- In the "shared memory" case I can go up to ~200 at most. And I'm confident that they really did the very best things possible for the implementation to be performant.

So for me the "things isolated in their own process" means literally getting seven times less out of my system than in the host process (and that's frankly unuseable, definitely not "negligent").

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

#489

Earlier quoted context omitted.

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-matchin…

Does it support matching patterns in data structures?

    f [ [1, _]. [3, _] ] = ...

    f [ [], [10, 20] ] = ...

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

#490

Earlier quoted context omitted.

> comments in Lithuanin As a polish-russian lithuanian I do read Lithuanian, russian and bits of polish but... it really is super surprising to see how people abuse unicode-encoded source code. Linux drivers with comments in Chinese are evil!

Translating foreign languages isn't that hard, thankfully, at least as long as the terms are written clearly enough and the language doesn't get too niche. However, to me it feels like English should remain the "lingua franca" of working in ICT, since most mainstream programming languages are already geared towards English and most of the popular frameworks/libraries also adopt the language, in addition to most of th…

Agree!

English is source code lingua franca, and every reasonable dev should understand this point.

It is kind of more complicated with tech literature though.

Post reply on HN