Hacker News Reader

Comment by shock | Hacker News Reader

It would be useful to you to recognize that you are letting an emotional reaction stopping you from using useful technology. I understand that Java makes you uncomfortable, but it is a powerful and stable language and you're missing out by avoiding it. It would take much more time to implement a similar project in C, and it would likely have lower stability. Yes, implementing it in C would use a lot less memory and if that's what you're optimizing for going with something else than Java is a wise choice most of the time.

Most technology is useful, depending on what you're optimizing for. I urge you not to optimize for being comfortable.

View on HN

The language isn’t the problem. The runtime is the problem. It’s a dependency mess, a licensing lottery, and a tuning crapshoot. The overhead of simply making it work, and maintaining that status across heterogeneous environments, is more than non-Java shops want to undertake.

Having spent much of the first half of my career writing C and Perl and then Java, I was very happy to set aside the latter two - for completely differing reasons.

You missed one: a constant stream of security patches for the JVM.

OPs points are valid. Filesystem work requires experience with system calls and I/O behavior. Java strives to abstract the underlying system away from the developer. System level tooling written in Java frequently requires twice as much expertise because there are two big systems in play instead of one, hence the unnecessary baggage.

My point was not to this project in particular, but general. I have seen this reaction towards Java often. Java is not familiar, for many people Java is inscrutable. I think this is because of the existence of the JVM and the need for the user to be aware of its existence. Rust is not simpler than Java, but the user just deals with a compiled executable, he doesn't see any complexity. Maybe GraalVM with nativeimage will help Java in this regard.

It's not an emotional reaction they were expressing at all - they even explicitly stated it's because of the need to bring in someone savvy with Java and the JVM to be able to support it. Sometimes there aren't the resources.

Someone not having an emotional reaction would not use expressions like "All the worst and most time-consuming troubleshooting experiences of my life have involved Java" and "the JVM decided to vomit all over my screen".

See sibling comment: https://news.ycombinator.com/item?id=24899595

"All the worst and most time-consuming troubleshooting experiences of my life have involved Java" is simply a statement.

All the worst and most time-consuming troubleshooting experiences of my life have involved dealing with a legacy VB6 app with a truly terrible MSSQL database structure - that's not an emotional statement, it's a fact.

> All the worst and most time-consuming troubleshooting experiences of my life have involved dealing with a legacy VB6 app with a truly terrible MSSQL database structure

Do you feel any powerful emotion when you think about that experience? Would you be indifferent if you would need to do it again?

Yes, dread. But it doesn't make the statement any less true. Myself and every single person maintaining that system felt exactly the same - it was a complete mess.

> it was a complete mess

I'm not doubting that at all. Was it VB6's fault or MSSQL's?

It was the owner of the platform & its developers, neither technology - I think we both understand that.

I was just trying to make the point that it's not necessarily emotional for someone to not want to work with a certain tool without an expert available because of terrible past experiences where that was the case.

I'd say it's almost impossible to imagine any past event someone has present at without having some emotional response.

The emotional raction is the resistance to Java and the assumption that it will break and you will need a Java expert to fix it. I don't know much C and I use MySQL and don't need to worry about C internals at all when using it. Just some configuration stuff, and maybe install some C build tools. I wouldn't expect it to be much different for this project.

I think you've overlooked OPs point a bit. You don't need to understand the C/libc internals to be able to operate MySQL (you do need to know it's quirks though). With a JVM application, you're going to need to understand the application level configs, think of something like spark, and if you're doing anything with large amounts of data or high RPS, you're also going to need to understand the JVM internals. The closest analog might be needing to understand the libc allocator for certain usage patterns, and that happens, but it's far more rare than someone needing to tune garbage collection algorithms and parameters. JVM tuning is just a reality of operating in the java ecosystem.

Java is great, the JVM is hell.

Our shop has about the same Cassandra DBAs, as JVM experts to keep it running.

Every time a node goes down because of JVM shenanigans the ScyllaDB migration discussion pops back.

Java is a significant legal risk. Do not let it into your company.

How so?

Reply on news.ycombinator.com