Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we choose Java instead of a polyglot stack

product.hubspot.com

Post reply on HN
Print view View original

111–120 of 155 posts

Re: Why we choose Java instead of a polyglot stack

#111

Post by Consultant32452 »

vbezhenar wrote: post #76

Java platform and libraries are very mature and good. Java as a language is not. I suggest to take a look at Kotlin. It uses JVM, it uses Java standard library, but it provides much better language, while keeping simplicity and it's close enough to Java to be a drop-in replacement. And IDE support is excellent, if we are talking about Intellij Idea. Kotlin is really Java++. No reason to choose Java over it. Another o…

I have two good reasons not to choose Kotlin. The first is until I started reading this thread on HN I had never heard of Kotlin. The second is I attempted to find kotlin in a job listing on Monster.com in several major cities and managed to only find one single listing in Los Angeles. The job listing says they are transitioning to Java. My argument of course is from the greater view of the business and not a laser focus on Kotlin as a technical decision, but for most projects you should choose a much safer option with insane amounts of support and developers on the market by the boat loads.

Re: Why we choose Java instead of a polyglot stack

#112

Post by amalag »

meddlepal wrote: post #5

If you're not picking the JVM in 2016 to build your core services and web applications then you're making a mistake that is going to cost you time and money either upfront in building things that already exist or later down the road when you start to need more performance and your RoR application isn't cutting it anymore. Say what you will about Java the language (I agree it's not particularly "sexy") but the JVM is…

You can do RoR on Jruby. It won't be as performant as staticly typed languages, but it is often good enough. You do lose the benefits of static typing though with refactoring.

Re: Why we choose Java instead of a polyglot stack

#113

Post by xiaoma »

meddlepal wrote: post #5

If you're not picking the JVM in 2016 to build your core services and web applications then you're making a mistake that is going to cost you time and money either upfront in building things that already exist or later down the road when you start to need more performance and your RoR application isn't cutting it anymore. Say what you will about Java the language (I agree it's not particularly "sexy") but the JVM is…

>"If you're not picking the JVM in 2016 to build your core services and web applications then you're making a mistake that is going to cost you time and money either upfront in building things that already exist or later down the road when you start to need more performance and your RoR application isn't cutting it anymore."

That sounds like a fantastic problem to have. Airbnb, Teespring, (Rap) Genius, Github and many others have run into it and I don't see how one could wish more for a friend building out a new wep app in 2016.

The best part is that if you build quickly and hit scaling problems, you have the resources to invest into making your product performant. The second best part is that if you don't hit scaling problems, at least you haven't wasted time on optimizing something the market didn't want.

Re: Why we choose Java instead of a polyglot stack

#115

Post by eropple »

hackercomplex wrote: post #86
eropple wrote: post #81

Earlier quoted context omitted.

> in order to achieve concurrency they must scale with processes and that consumes an absorbent amount of RAM While the trolling you responded to about Java and RAM is untrue, this also is not really true (I assume you meant exorbitant , not absorbent ). Concurrency happens just fine in MRI in many cases because the blocker is the global interpreter lock; if you're doing I/O, threads operate concurrently in MRI. In a…

exorbitant! quite right The overhead for a unix process is significantly more than a lightweight JVM thread. In some cases this memory overhead can prevent you from utilizing the smaller cloud instance types which are sometimes the most cost efficient. Also with MRI you can't light up all 4 cores, or 8 or 16 without spawning extra processes which burn memory and that can make your server less cost efficient if your a…

I would gently suggest that you are laboring under incorrect assumptions. There is nothing "lightweight" about JVM threads; they are standard native threads on normal platforms and on Linux a thread context switch has roughly the same performance overhead as a process context switch. (There is a difference, and if you study the kernel source I'm sure you can divine it, but you will also quickly realize that it is a rounding error compared to the first cache eviction of the new context.) The memory overhead of a process in Linux is literally measured in tens of kilobytes.

I also suggest you look into preforking and copy-on-write and ensure that you are clear on how Linux works with regards to memory usage; modern Linux systems indeed do not necessitate "burning RAM" to use multiple processes (indeed, the fork paradigm is the standard Unix approach for a reason, it only makes sense to make it performance-friendly). I would also note that while a Ruby or a Python can do this, Java, in standard configurations, cannot, were one to desire the ability to do so (and I've had reasons to run JVM applications in a multiprocess mode before).

I don't dislike Java, don't get me wrong. I write a great deal of Kotlin. But accuracy is important.

Re: Why we choose Java instead of a polyglot stack

#116

Post by hackercomplex »

eropple wrote: post #115
hackercomplex wrote: post #86

Earlier quoted context omitted.

exorbitant! quite right The overhead for a unix process is significantly more than a lightweight JVM thread. In some cases this memory overhead can prevent you from utilizing the smaller cloud instance types which are sometimes the most cost efficient. Also with MRI you can't light up all 4 cores, or 8 or 16 without spawning extra processes which burn memory and that can make your server less cost efficient if your a…

I would gently suggest that you are laboring under incorrect assumptions. There is nothing "lightweight" about JVM threads; they are standard native threads on normal platforms and on Linux a thread context switch has roughly the same performance overhead as a process context switch. (There is a difference, and if you study the kernel source I'm sure you can divine it, but you will also quickly realize that it is a r…

I know they're native threads, they're lightweight compared to unix processes. You're trying to change the subject to CPU performance during context switch when what we were discussing in memory consumption.

The memory overhead of a MRI ruby process running on linux is much higher than the overhead of a native JRuby thread, they are apples and oranges, surely we agree on that point because you can check it via a simple ps aux command.

Perhaps I am mistaken, but from what I've read to run unicorn following their recommended guidelines you need to spawn at least 1 MRI process for every CPU core, but if your application blocks on IO rather than CPU during it's request cycle which is common then you will need more processes than CPU cores in order to handle concurrent HTTP requests. At that point you're wasting many orders of magnitude more memory than JRuby for every "unit of concurrency" so to speak.

by the way Kotlin looks interesting, thanks for pointing it out I was not familiar

Re: Why we choose Java instead of a polyglot stack

#117

Post by meddlepal »

NicoJuicy wrote: post #71
jcrites wrote: post #42

Earlier quoted context omitted.

.NET is a pretty strong contender and provides a lot of the benefits of Java, I agree. C# was ahead of Java language-wise for many years, though Java is catching up, and there are elements of the CLR and model that I'd prefer over Java, such as properties. I also recall the .NET assembly model being clearer than Java equivalents like classloader. await's pretty nice. It's all been focused around Windows though for ye…

I see a trend of more community for .Net ( because of Microsoft's efforts) and less through Java ( because of Oracle's non-efforts)

I feel like the perception that Oracle isn't evolving Java is heavily parroted by people outside the ecosystem. From a Java developers perspective they have done far more in the last two releases than Sun did after 1.5.

Re: Why we choose Java instead of a polyglot stack

#118

Post by eropple »

hackercomplex wrote: post #116
eropple wrote: post #115

Earlier quoted context omitted.

I would gently suggest that you are laboring under incorrect assumptions. There is nothing "lightweight" about JVM threads; they are standard native threads on normal platforms and on Linux a thread context switch has roughly the same performance overhead as a process context switch. (There is a difference, and if you study the kernel source I'm sure you can divine it, but you will also quickly realize that it is a r…

I know they're native threads, they're lightweight compared to unix processes. You're trying to change the subject to CPU performance during context switch when what we were discussing in memory consumption. The memory overhead of a MRI ruby process running on linux is much higher than the overhead of a native JRuby thread, they are apples and oranges, surely we agree on that point because you can check it via a simp…

Attempting to cite `ps`, which includes the unique pages as well as all shared pages used by the process--i.e. pages created by its parent to store such trivialities as the entirety of the Ruby runtime and the classes loaded therein--makes me question your understanding of the Linux process and memory model. Do you understand how fork(2) works on a modern Linux machine with regard to memory page sharing from parent to child? Suffice to say that nobody running a hojillion processes in Unicorn or another forking process worker--and I should point out that I have written one of these in Ruby, this isn't Unicorn magic--is suffering under the tyranny of large amounts of duplicated data. (I'm sure there are people who spin up X of a process from the jump, but they are swimming upstream and are not the norm in my experience.)

The difference in memory usage between a forked process on a shared-page/copy-on-write OS and a thread is infinitesmal. You'd have better luck arguing about having a JIT and better perf (and there you'd be incontrovertibly correct, but I don't think it really matters for 95% of everything).

Re: Why we choose Java instead of a polyglot stack

#119

Post by ajainy »

It's interesting to see shift towards. Always remind of 2005, when everyone was blogging about RoR.. Then 2010, everyone was blogging about scala. Personally, I could never find any good reason to move away from JAVA. Yes, learning multiple languages might give you better perspective on software development but when we talk about some serious enterprise software development (it's not only language but cost of development too), JAVA is good enough.

-=-= Another thing I am realizing, over the period, specially shift in architecture style because spring (aka IOC pattern), it has made programmers better. We can't blame everything on EJBs etc any more. Early JAVA programmers were treating java as magic bean instead of putting good effort on learning & writing programs right away.

Oracle should thank Apache & Spring.. in my opinion.

Re: Why we choose Java instead of a polyglot stack

#120

Post by hackercomplex »

eropple wrote: post #118
hackercomplex wrote: post #116

Earlier quoted context omitted.

I know they're native threads, they're lightweight compared to unix processes. You're trying to change the subject to CPU performance during context switch when what we were discussing in memory consumption. The memory overhead of a MRI ruby process running on linux is much higher than the overhead of a native JRuby thread, they are apples and oranges, surely we agree on that point because you can check it via a simp…

Attempting to cite `ps`, which includes the unique pages as well as all shared pages used by the process--i.e. pages created by its parent to store such trivialities as the entirety of the Ruby runtime and the classes loaded therein--makes me question your understanding of the Linux process and memory model. Do you understand how fork(2) works on a modern Linux machine with regard to memory page sharing from parent t…

Well it looks like you're right I wasn't aware of how efficient COW forking is. I stand corrected
Post reply on HN