Hacker News Reader

Comment by onebot | Hacker News Reader

Nice to see stuff like this. But won't use it since built on Java. I try to avoid the JVM as much possible.

That's very harsh. If it were a bunch of cobbled together perl and bash scripts I could understand poopooing the software stack, but java for enterprise accounting software is a super common stack and arguably one of the most suitable solution for this type of software.

It is just my preference. But your right, java is very "enterprise" hence my trepidation. I think there are much better enterprise worthy languages now, like Go. Which are far easier to develop and maintain.

Or Kotlin. People usually complain about JVM but lots of enterprise software runs on it. Spring boot ecosystem provides lots ready to use libraries. Kotlin can be much easier to use compared to Java. Yes Go can be better language now, but still lacks lots of library and API support. And Rust, I'd rather code in jvm language fast and ship it fast than building up whole infrastructure that takes way more time to implement.

In my main gig we run on kotlin (fintech/accounting saas) and I absolutely despise it, the overhead is massive. But I wouldn't want to write it in golang, we really need proper OOP. It's also so unbearably slow, it's actually impressive. But it is what it is ¯\_(ツ)_/¯

what would you say is a fast language then?

Golang, Rust, etc.

Also, to be fair, a big part of the slowness is also the tooling, Spring Boot, Hibernate etc. You can mitigate that by using micronaut or exposed/krush, but we only have a microservice running on that. The main business logic is the classic java web stack. Tests, running the app, building takes forever.

A significant amount of the worlds software runs fine on JVM

I hear 3 billion devices run Java.

As an alternative you can use: getlago.com, which isn't built on Java

Lago is AGPL so no go.

Beggars can't be choosers. If you're going to reject every open source solution, you might as well just sign up for Stripe.

I'm not too familiar with the problems of AGPL - what's the specific issues I should be concerned with Lago being AGPL?

https://opensource.google/documentation/reference/using/agpl...

If you are not modifying it, this is the same as MIT in every practical way.

Same here. It really is a headache and slow compared to a nice Go, Rust or C program.

Care to explain why?

Oracle / licensing

edit: IIRC the official Java runtime auto-update happily upgraded to not-even-free-as-in-beer pretty nonchalantly.

https://news.ycombinator.com/item?id=28543265 (2021)

https://news.ycombinator.com/item?id=20799424 (2019)

I don't understand this complaint anymore. Hotspot and OpenJDK are all GPL, licensing and Oracle aren't worries at this point

It's GPL with the 'classpath exception' so that you're even exempt from the GPL the you link. Seems pretty good licensing? Do you prefer even more permissive than that?

This is no longer a real reason. It's licensed as GPL with a "classpath exception." That's pretty permissive and this article[0] does a pretty good job of explaining some questions you may have.

[0]: https://www.mend.io/resources/blog/top-9-gpl-with-the-classp...

Java was great at the time it was created. But now, I think there are several better languages that are more suited for today. Like Go as an example. Easy to develop and easy to maintain. You get very good performance for little effort. It is just my personal preference, but I don't care to maintain Java or JVM anymore. FWIW, I was at the very first every Java One conference. Have used it for many years.

It might make sense to revisit your stance given the most recent JEPs that have been introduced. Java 19 introduced virtual threads and structured concurrency, which will arguably make Java + the JVM a great alternative to Go, etc. Especially since it's very backward compatible.

W/ Graal as well, the AOT compilation comes 90% of JIT performance.

I really think the JVM is an exciting eco-system that has a very bright future if it keeps going the way it is. Brian Goetz' "Paving the on-ramp" discusses how to reduce the boilerplate even further. So these things are definitely a priority for the Java/JVM team[0].

[0]: https://openjdk.org/projects/amber/design-notes/on-ramp

I haven’t seen a single business app written in Go

I'm not the OP, but generally JVM applications are very resource hungry under small loads, although I will concede this matters less as load increases, and the extreme OOP style of programming that Java encourages, in my opinion, leads to a lot of faults that require more operational babysitting than I'm ok with.

I don't have any empirical evidence, just experience. As such I'm very biased against it.

Reply on news.ycombinator.com