8 ms·

JVM + PostgreSQL IMO. It's fast enough for almost everything, you get choice of Java/Kotlin/Scala/Clojure depending on taste. PostgreSQL can represent almost a

by jpgvm 6y ago

JVM + PostgreSQL IMO. It's fast enough for almost everything, you get choice of Java/Kotlin/Scala/Clojure depending on taste. PostgreSQL can represent almost any storage paradigm you want from traditional relational schemas, to graph like structures with recursive CTEs and even NoSQL JSON document style with jsonb. Everything is super well supported with consistent release cycles, minimal regressions and runs on almost any platform. Tooling support is superb ofcourse - IntelliJ makes working with the platform a breeze. You get all of the JVM debugging and profiling capabilities and PostgreSQL has EXPLAIN ANALYZE making getting to the bottom of performance problems simple. If you want to take on fancier paradigms like ES/CQRS/CDC you have best in class libraries and tools all built on the JVM. Debezium + Kafka being one example. Need faster OLAP queries than a PostgreSQL replica can provide, Druid is JVM based and can be integrated with Debezium + Kafka + Avro for streaming ETL. These sorts of tools are ideal because they are already best in class but can also be easily extended with any JVM language. Want to do big data processing? If you are already on JVM it's easy to plug in Hadoop/Spark or one of the Apache Beam runners like Google Dataflow. List goes on, there are literally hundreds of fields where JVM beats all other platforms out as it's the most general purpose platform available. It has real threads so it's not limited where single threaded languages are. It has multiple best in class GCs (latency or throughput tuned as you please). Best JIT by far with reasonable SIMD optimisations (annotations coming soon for guaranteed SIMD on supported platforms). JVM might be old but it's 2020s most promising platform. Rust and .NET are up for contention too but with Project Loom and Valhalla on the horizon I don't see anything beating JVM in the next few years.

dmos62 6y ago
> 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 https://wiki.openjdk.java.net/display/zgc/Main
- jpgvm 6y ago
  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.
  - dmos62 6y ago
    Somehow missed that part :)
emsy 6y ago
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.
- eecks 6y ago
  How is Spring outdated? Spring Boot seems to be a good option.
  - kharak 6y ago
    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.
    - kitd 6y ago
      I'd recommend looking at Quarkus for new JVM-based microservices, especially Kubernetes-based ones. https://quarkus.io/ https://quarkus.io/
      - eecks 6y ago
        Cool, I'll check Quarkus out.
    - jpgvm 6y ago
      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.
    - emsy 6y ago
      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.
dig1 6y ago
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.
kharak 6y ago
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.
- theshrike79 6y ago
  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. =)
  - majewsky 6y ago
    > 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?
    - jpgvm 6y ago
      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.
- mumblemumble 6y ago
  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.
LordHumungous 6y ago
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.
- pc86 6y ago
  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.
  - LordHumungous 6y ago
    K but what if you your service needs to scale.
- jpgvm 6y ago
  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.
  - LordHumungous 6y ago
pc86 6y ago
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.
- cameronh90 6y ago
  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.
  - jpgvm 6y ago
    I also like C#/CLR a lot. If JVM wasn't fulfilling my needs it would be the main alternative I would consider.
imtringued 6y ago
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.
- jpgvm 6y ago
  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.

by jpgvm 6y ago

dmos62 6y ago

> 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 https://wiki.openjdk.java.net/display/zgc/Main

jpgvm 6y ago
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.
- dmos62 6y ago
  Somehow missed that part :)

emsy 6y ago

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.

eecks 6y ago
How is Spring outdated? Spring Boot seems to be a good option.
- kharak 6y ago
  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.
  - kitd 6y ago
    I'd recommend looking at Quarkus for new JVM-based microservices, especially Kubernetes-based ones. https://quarkus.io/ https://quarkus.io/
    - eecks 6y ago
      Cool, I'll check Quarkus out.
  - jpgvm 6y ago
    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.
  - emsy 6y ago
    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.

dig1 6y ago

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.

kharak 6y ago

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.

theshrike79 6y ago
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. =)
- majewsky 6y ago
  > 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?
  - jpgvm 6y ago
    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.
mumblemumble 6y ago
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.

LordHumungous 6y ago

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.

pc86 6y ago
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.
- LordHumungous 6y ago
  K but what if you your service needs to scale.
jpgvm 6y ago
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.
- LordHumungous 6y ago

pc86 6y ago

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.

cameronh90 6y ago
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.
- jpgvm 6y ago
  I also like C#/CLR a lot. If JVM wasn't fulfilling my needs it would be the main alternative I would consider.

imtringued 6y ago

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.

jpgvm 6y ago
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.