Hacker News Reader

To mention another benefit of JVM: flexibility.

We had a very complex application that would take care of hundreds of events per second, doing all sorts of calculations on top of that. It would get stuck frequently in GC cycles due to huge number of objects processed in memory and developers unconstrained resource usage.

We switched it to ZGC, only by changing startup options, and the application was like a brand new thing. Very responsive and zero GC issues.

Rewriting it in C++/Rust would take many months and even more $$$, and no one could guarantee it would work better.

With some variations, this setup describes my entire career as software engineer so far. Reading Hackernews, for the longest time, I had this lingering feeling of knowing nothing or not the right things.

Now, I know that my experience isn't just the norm for a great number of developers, at least in Europe, but also a reasonable choice. If there is no need to do something fancy, don't do something fancy. Not in a professionell business environment. There are zero upsides for the business.

Yep, if you need to get shit done in time without a need to pad your CV with fancy tech, it's really hard to go wrong with Java or C#.

You'll be done in time and on budget. You'll also be a bit bored, but you can go rock climbing or something during the time you saved by using tried and true, boring, tech. =)

> You'll also be a bit bored

I don't understand. Am I the only one around here who gets a kick out of watching my software perform like a well-oiled machine?

Heh not the only one. Writing software that never wakes me up at night is what keeps me honing my craft. I take it as a point of pride that my software only receives attention for runtime/library updates or the rare feature request.

I've come to think of it as the Instagram Effect.

If you use Instagram as your indicator of what other people are doing in almost any domain, there's a good chance you'll end up with an incredibly skewed sense of how to go about life in general. You'll feel like you need to spend hours in the kitchen preparing elaborate food that's optimized for looking good in photographs rather than tasting good. Your kids' memories of the holidays will be dominated by all the time you spent trying to assemble overly fiddly and elaborate homemade decorations and whatnot, rather than the time you spent letting them get themselves transform perfectly good cookies into horrible dribbly icing covered messes, and have a great time doing it. You'll worry that the only good vacation is an expensive vacation. And so on and so forth.

Which. . . I shouldn't be so negative. Plenty of people enjoy fancy elaborate things, and love to talk about what they're doing and share it with others. And that's great. But it's really easy to look at the Internet and get the impression that what everyone is snapping photos of for Instagram is an accurate cross-section of what people are typically doing, and develop a serious case of FOMO anxiety.

The JVM is vastly underestimated. I think the root cause is an image problem, stemming from a combination of bad programming practices in the past (getter/setter bloat, Factories for everything and unnecessary object orientation) and heavy and outdated frameworks such as Spring, JSF and others.

How is Spring outdated? Spring Boot seems to be a good option.

And what is the alternative in the JVM environment? But I have to say, I'd like something less verbose. Springs stack trace looks ridiculously bloated. Still, other than that, you hardly notice the framework once everything is setup.

I'd recommend looking at Quarkus for new JVM-based microservices, especially Kubernetes-based ones.

https://quarkus.io/

Cool, I'll check Quarkus out.

There are many alternatives to Spring if you prefer a more DIY approach. Namely Javalin, Micronaut, KTor (for Kotlin folk) and many more (Quarkus was already mentioned).

Spring however is the way to go if you come from a Rails/Django/ASP.NET background and want the framework that everything works with out of the box.

These days I’d go with a JAX Rest backend. The frontend is pure HTML+JS (so no server side templates unless they make sense). No dependency injection but „hand-wired“ dependencies at the top level. I also don’t use ORMs anymore. This means a slower start in the beginning, but later in the project you’re not caught up in a net of a dozen intertwined frameworks.

Lightbend offers a couple good options. Play for web applications: https://www.playframework.com/

Lagom for microservices (which is based on Play): https://www.lagomframework.com/

I highly recommend Play as well.

I agree and I doubt anyone starts new projects with JSF anymore. But it’s still very much on my mind when I think about Java web apps. As I said, it’s an image problem, not a technical one. the comment I replied to laid down why the JVM is more viable than ever and I hypothesized why people don’t go for it yet.

I wouldn't say Spring entirely is outdated. Hibernate and EntityManager are--they were made for the time of Enterprise JavaBeans and their lifecycle.

For me, one reason I avoid Java is because it’s what I used in college when I was a much less proficient programmer. I remember it being confusing and a lot of hard work. That association probably has more to do with learning programming than it has to do with Java but it has stuck, in my mind, somewhat.

Give Kotlin a go. Fresh perspective on the JVM goes a long way to dispelling that feeling.

> with Project Loom and Valhalla on the horizon I don't see anything beating JVM in the next few years

Don't forget the low-latency GCs, like ZGC:

https://wiki.openjdk.java.net/display/zgc/Main

Yeah for sure, I sort of mentioned this with latency vs throughput tuned GCs being available but I guess it's worth pointing out just how insanely good ZGC and Shenandoah are.

Somehow missed that part :)

Would just like to toss in CLR for folks who like .NET. You get C# which is great (but I'm biased), and F# if you have a functional paradigm. Both EF and Dapper can pretty easily hook into Postgres. I'm also partial to Azure over AWS so there's obviously a bias toward C# over something like Java there. There are similarly great ES/CQRS libraries for .NET - I'm not sure about CDC on the Postgres side but they exist for SQL Server if you're using that.

Just to chip in here. We deploy C# to Kubernetes on Linux, AWS with Postgres as datastore. Everything works great. AWS for .NET API support is good, typically better documented than the Azure libraries.

C# is a hugely underrated ecosystem. I have experience with Java, Python, Go, C/C++ node and Rust - and C# is my tool of choice.

I also like C#/CLR a lot. If JVM wasn't fulfilling my needs it would be the main alternative I would consider.

Unfortunately all programming languages are flawed. It's kind of funny how we still have no programming language that does everything to a satisfying degree instead of having one major wart that always means that a different problem requires a different programming language.

There are not many languages with a lean runtime. The JVM needs a lot of memory even if you have 0 bytes of heap usage. Javascript applications are often tied to electron.

There are not many fast languages that do not cause security issues or cause hard to debug segfaults. The two obvious choices are Rust, Java (or C#) and maybe Go. I personally set the cutoff point for fast enough to be Javascript with v8. Not everything needs to be fast enough to be used for a game engine but at the same time I don't want to CPU or user time on gross inefficiencies.

There are not many modern languages that everyone agrees to use. Javascript is the pinnacle of this because people are forced to use it. The JVM suffers from having too many languages. Kotlin is the only winner but I am still bitter about that one JVM language that died. I don't know why but Rust is one of the most hated languages on HN.

There are not many easy to learn languages. C++, Rust, Haskell, Scala all tend to suffer from the ability to write convoluted code bases that nobody understands. People become experts within their own small islands. Java EE also had a phase where everything was done with impenetrable xml files that were getting closer and closer to turing completeness. Java and Go are both a direct response to C++ being too complex.

All easy to use languages (primarily JVM languages but also many interpreted languages) fail because they are not fast and lean and nobody uses them.

All fast and lean (=low level) languages fail because they are too complicated or suffer from security problems.

The answer? I don't know. I thought graalvm was going to solve this with it's native image mode but my preferred JVM language doesn't run on it. I'm hoping that Java will be good enough if I'm going with a slightly non standard setup (immutables). The lack of reflection means that you have to avoid a lot of libraries. Ecosystem advantages are disappearing if you go down this route.

While this is true JVM disadvantages are only a problem in very niche domains like embedded or kernel development. (and where you are forced to use JS like web ofc)

Overall it's definitely in contention for "universal" runtime and Kotlin/Java are definitely close to fully general purpose languages that do all things sufficiently well.

IMO the reason why they win the general purpose category is because they have the least hard limitations.

CLR is in a similar quality class to JVM, C# is a very good language. I think if you are not on the JVM that is where you should be for general purpose programming.

JS/Ruby/Python/etc are all single threaded, this is a hard limitation that I can't look past. It's a needlessly painful constraint when you just need something CPU intensive to be done quickly. Additionally lack of static typing isn't something I am willing to compromise on anymore. I'm older now, I don't have time for the sort of defensive programming required to make these languages produce programs with as few bugs as a statically typed equivalent. I still use Ruby for scripts but it's not a tool I pick up for anything but the quickest of hacks anymore.

C/C++ are too unsafe to use without too much brain space dedicated to making sure you are managing memory correctly. Also lacking centralised repository and package management ala Maven.

Functional languages are too polarising, I can use them and appreciate them but rallying a team around them is too hard. Haskell and it's ecosystem taught me a great many things and it's definitely what most good languages steal from these days. Bright spot of JVM/CLR is you can mix a bit of them in when you need to with compatibility with the rest of your code with F# and Clojure/Scala.

Rust is getting there but isn't there yet. I think it's the most promising besides JVM/CLR. Really high quality type system, tooling is coming along, great quality ecosystem, async getting worked out. As it's borrow checker gets smarter and perhaps an easy GC library is introduced (atleast easier than Rc/Arc/Cell/friends) then it's got great things in it's future.

For me it's Kotlin for now. It's the right mixture of modern, easy to learn and built on solid proven tech without any severe limitations.

If you had to write a Rails style web application on the JVM today, which framework would you use? Spring Boot? Play? Something completely different?

Spring Boot if I needed similar bells and whistles to Rails.

This really is the exact same conclusion I have came to quite recently. All your point are strongly inline with mine.

I personally love how pragmatic Ruby is but its billion dollar null mistake + lack of typing + single threaded issues are glaring. But I still love the language and especially the community, my problem with switching over to Kotlin + SpringBoot is that lack of rails ecosystem web mindset. The SaaS web focused mindset doesn't really exist in Kotlin e.g no Phoneix LiveView/StimulusReflex competitors. Also while SpringBoot is suppose to be the like the Rails competitor I don't have access to my `rails routes` or `rails new` or `rails generate..`, the rails guys really focus on happiness.

Having said that with Project Loom coming and other JVM goodies it feels really good to be in the JVM ecosystem. It is very much the 'good enough for 95% cases' ecosystem.

Crystal is a bit like ruby, but with static types and multi treading is being worked on.

Had a look there but its very far from reaching boring tech with regards to libraries also why Elixir is mostly a no go at the moment for me too. Love the look of Crystal though, basically ruby with all issues I mentioned fixed. Kotlin gets its pass on being boring with the great JVM compatibility imo.

Almost every language has a killer application though. If you do machine learning, for example, Python is the obvious choice.

I would prefer Python or Node over JVM for a light weight microservice.

I would choose a NoSQL store for something that needs to scale.

Both SQL and NoSQL will scale fine for 99% of apps (and let's be honest, ~90% of apps don't need any scale).

Your data schema/format should be dictated by the data itself more than some handwavey "we might need to scale" requirement that isn't true the majority of the time.

K but what if you your service needs to scale.

Python and Node both have highly fragmented ecosystems, low quality packages, poor tooling and neither are statically typed, capable of multi-threading in a meaningful way and other then their niches (data science for Python and client-side web for JS) are worse at everything than JVM or CLR.

I understand their attraction, they are "simple" and "easy" languages. But they are not boring. If anything they create a ton of distinctly un-boring problems like build chains, packaging, framework of the week is no longer supported (or has a new incompatible version).

Engineers may like these for whatever reasons, especially before they have tried the higher quality tooling provided by real boring tech but inevitably they lead to projects that either run behind time because of technical issues not related to business problems and/or rot after development is paused and are hard to resuscitate and maintain afterwards.

Also NoSQL doesn't "scale" better than SQL. NoSQL stores can scale better in certain data access patterns but if your data model is inherently relational and you implement it on top of NoSQL all you have done is reinvented a relational store in your application model and likely crippled integrity, scalability and performance in one fell swoop.

I disagree with pretty much everything in your comment.

> NoSQL stores can scale better in certain data access patterns

Exactly.

And that's where folks go wrong. NoSQL is not boring tech. As soon as you need to scale, it is MORE likely, not less, that you will end up in a weird state in your app, user enrollment flow etc. NoSQL makes scaling MUCH harder in my view. SQL tools give you a common interface many folks can engage with, and many tools.

I really want to talk to people building piles of spaghetti on noSQL because "it scales". At some point you've just go to start tearing your hair out.

Postgresql can do 1.5M queries (read/write) per second on OLTP loads on one box just to get started. If you really need more you can get extremely high with replicas. Then application design comes into play.

I'm tired of folks picking "noSQL" so things can scale. Dealing with all the edges cases as these things scale is a nightmare (plug mongodb and friends seem to fall over MUCH more often, recovery is miserable with them etc).

How do you load balance across replicas? How do you shard across replicas?

Load balancing across read replicas is usually handled by your connection bouncer, say pgBouncer/pgPool/etc though you may also do some amount of more complex both L3 and L7 balancing if you get really big.

Sharding is usually a matter of actually splitting the masters. There are many techniques for achieving this. If you want the database to do all the work you will probably want to use something like Citus for PostgreSQL or Vitess for MySQL.

You can also build bespoke topologies using PostgreSQL logical or MySQL binlog replication.

Failing that you can do application level sharding if you don't want the database doing anything fancy for you and manage each shard as an independent database cluster.

By the time you actually need to do this you will be able to afford one of these options. :)

In the meantime you will save a ton of CPU, storage and development time vs a "NoSQL" store as databases like PostgreSQL are inherently more efficient for all but the simplest of KV access patterns.

> By the time you actually need to do this you will be able to afford one of these options. :)

What if I need to do this now? Why would I build a distributed postgres snowflake that takes 10 hours to spin up a new replica, requires that I implement my own sharding, instead of using a datastore that is designed to handle all of these things at scale?

Comes down to your data model. If its inherently relational it's still the best play. Scale and performance are much more tractable problems than integrity and consistency. One you can measure and be sure of, the other you need a Phd to fully understand all the edge conditions that need covering.

There are some pretty decent NoSQL stores now for simpler access patterns. As long as you stay away from nonsense like MongoDB and stick to real databases like Cassandra/ScyllaDB/BigTable/etc you will do fine.

These stores are a fraction as flexible as PostgreSQL/MySQL but do allow scale-out storage and fast primary key lookups and scans. Good for when the size of your data is well in excess of 1TB+ and you don't need anything complex or consistency.

Reality - these folks don't need to "do this now".

Yes, Visa may need this. Guess what, 1TB+ of transaction data paying 30 center + 2% PER LINE - you'll be able to afford to do something reliable and scalable.

Folks don't realize, noSQL is not actually that scalable except in very narrow ways. And you can spin up pretty good scale SQL stuff with things look AWS RDS, including backups, replicas, snapshots to go back in time etc (noSQL doesn't support a lot of this).

A lot of folks underestimate what one box can do. Memory / core counts have gone crazy on just one box. Local storage also has gone crazy. 4TB memory on a single node dual CPU machine, CPU's with 32 cores per CPU+?

Read only replicas are pretty trivial as well.

A lot of people underestimate what a high scale workload means.

And even more people talk about high scale workloads with no clue what they actually look like. :)

I routinely work with 10TB+ PostgreSQL clusters, 10TB+ BigTable clusters and 500TB+ BigQuery projects all in my current day job. I'm in Data Infra btw so this is sort of my bread and butter.

In the past I have worked with 100TB+ Cassandra clusters, 50TB+ MySQL+Vitess and countless other stores like MongoDB, RethinkDB, Voldemort, TokyoCabinet and probably tons I have forgotten.

It's highly unlikely one actually works with and manipulates these volumes of data on a regular basis and doesn't respect SQL stores and the JVM (the literal king of Big Data).

I don't understand the point you are trying to make.

All of the issues with SQL, including strong consistency, data normalization, table JOINs, etc., mean that any RDBMS is going to inherently going to be limited in its viability to scale compared to a properly architected NoSQL database.

Disclaimer: I work at ScyllaDB. A LOT of our migrations are from people who got started on MongoDB, and then it fell over. Another group come from DynamoDB, and then they see their monthly bill.

There are also people who have moved to Scylla from PostgreSQL because it fell over, or those who blanched at their Oracle bill.

Scalability is not inherent to SQL or NoSQL. It requires both technical features as well as economical offerings. It is a quality of a product made with users and real-world workloads in mind.

As in all DB work, YMMV.