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

81–90 of 155 posts

Re: Why we choose Java instead of a polyglot stack

#81

Post by eropple »

hackercomplex wrote: post #31
nemik wrote: post #4

I also advocate for Java, but mostly because I invested in companies that manufacture RAM.

in the Ruby world people end up consuming more RAM when using the C based ruby (MRI) because in order to achieve concurrency they must scale with processes and that consumes an absorbent amount of RAM. With JRuby you can scale concurrency with native threads that have minimal memory overhead.

> 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 addition, the overhead of a process in Ruby isn't all that much, and in the rare case where it is (typically a web application) you've got tools such as Unicorn that will prefork and allow you to share/COW that overhead.

Re: Why we choose Java instead of a polyglot stack

#82

Post by eropple »

buckbova wrote: post #26
mercurial wrote: post #14

Earlier quoted context omitted.

I've done a lot of Java, and I'd say the stereotypes didn't come from nowhere (XML is great! Enjoy using XML for dependency injection and configuration!). Not to mention the lack of expressivity of the language causing the proliferation of FactoryBeans. The other issue is that the "IE effect": the language stopped evolving for years. In the meantime, Microsoft launched C#, and Java is only catching up now in terms of…

> Of course, compared to C#, it still benefits from a considerably larger and IMHO higher-quality ecosystem . . . Maybe so, it's been over a decade since I've coded in Java back in the days of java servlets. But what MS has done with C# is great. It's turned out to be an awesome language with lambda, linq, async features that's really hard to beat. edit: Looks like java 8 has lambda now. http://www.oracle.com/webfold…

C# the language is fine, but C# the ecosystem is kind of a mess. There are multiple approaches that attempt to solve the same problem (PCLs versus shared libraries; both have their place but they overlap uncomfortably) and cross-platform development is an abject disaster (CoreCLR may eventually get to a good place but I wouldn't use Mono in production for long-running services). NuGet--itself a problem in many ways, it's very poor the second you get off the happy path--exists but in my experience its usage is spotty, whereas even the jankiest Ant projects I've ever worked with at least used Ivy. Libraries in NuGet are also, I think, a lot more hit-or-miss than I'm used to either in Ruby or on the JVM. Some stuff is real good (JSON.NET!). Some stuff is real, real bad (the bajillion competing and differently defective YAML tools), and there isn't the same sort of cultural focus on pushing the good to the forefront.

This isn't a strong defense of Java, because I think the JVM and its ecosystem isn't super great either. I really like C# and I pay for ReSharper despite not doing C# professionally (I've been using it for about a decade but never taken a job in it). But while C#-the-language has greatly improved, the ecosystem still feels five-plus years behind.

Re: Why we choose Java instead of a polyglot stack

#83

Post by edem »

davidw wrote: post #79

So, Java guys, what do you recommend if someone wants to have a Rails-like experience where programmer time is more valuable than 'web scale' performance? Say, also that I don't want to have to pay oodles of money for some server with a terabyte of memory to hold the application. Honest question - I haven't kept up with what's happening in Java land, and am curious what you'd recommend for that kind of side-project t…

There is [Grails](https://grails.org/) which I honestly did not use so I can't comment on it but people seem to like it. It is Groovy based though. The most common framework nowadays is Spring and its ilk (including Spring MVC and its friends). BUT there is Spring Boot which is basically a meta framework which takes an opinionated "sensible defaults for all the stuff" approach and you can get a project working with 5 clicks basically. Try out the [Spring Boot initializr](https://start.spring.io/). The biggest problem with these frameworks is the magic. While you are fine with the defaults it works. You can check the config files and tinker with them but there are a lot of layers to peel away if you are presented with some exotic Exception which will happen sooner or later. I'm also interested in what other options I have in Javaland currently because I'm steering away from it to Clojure islands and even the Node archipelago...

Re: Why we choose Java instead of a polyglot stack

#84

Post by davidw »

edem wrote: post #83
davidw wrote: post #79

So, Java guys, what do you recommend if someone wants to have a Rails-like experience where programmer time is more valuable than 'web scale' performance? Say, also that I don't want to have to pay oodles of money for some server with a terabyte of memory to hold the application. Honest question - I haven't kept up with what's happening in Java land, and am curious what you'd recommend for that kind of side-project t…

There is [Grails]( https://grails.org/ ) which I honestly did not use so I can't comment on it but people seem to like it. It is Groovy based though. The most common framework nowadays is Spring and its ilk (including Spring MVC and its friends). BUT there is Spring Boot which is basically a meta framework which takes an opinionated "sensible defaults for all the stuff" approach and you can get a project working with…

My question is pretty open-ended, so 'use XYZ in Clojure' works too.

Re: Why we choose Java instead of a polyglot stack

#85

Post by autoreleasepool »

scott_s wrote: post #28
edem wrote: post #19

Earlier quoted context omitted.

On the contrary Scala is baroque, its syntax is not following any known pattern. For example if I want to write a recursive function I have to indicate my return parameter type otherwise not. It doesn't matter whether you come from a C background or a Java background...or any background because of this: > def addInt( a:Int, b:Int ) : Int = { > var sum:Int = 0 > sum = a + b > return sum > } You have to relearn how a f…

Function declaration syntax where the return type is last is very common in functional languages. It's even allowed in C++11, because it allows one to define return types that depend on parameter types. An example taken from http://en.cppreference.com/w/cpp/language/auto , template auto add(T t, U u) -> decltype(t + u) // return type is type of operator+(T, U) { return t + u; } It's quite a sensible approach, and har…

I agree the syntax is sensible. I quite like it in Swift:

    protocol Numeric {
        func +(lhs: Self, rhs: Self) -> Self
    }

    func(a: T, b: T) -> T {
        return a + b
    }

Re: Why we choose Java instead of a polyglot stack

#86

Post by hackercomplex »

eropple wrote: post #81
hackercomplex wrote: post #31

Earlier quoted context omitted.

in the Ruby world people end up consuming more RAM when using the C based ruby (MRI) because in order to achieve concurrency they must scale with processes and that consumes an absorbent amount of RAM. With JRuby you can scale concurrency with native threads that have minimal memory overhead.

> 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 app can use the RAM.

Re: Why we choose Java instead of a polyglot stack

#87

Post by Yhippa »

davidw wrote: post #79

So, Java guys, what do you recommend if someone wants to have a Rails-like experience where programmer time is more valuable than 'web scale' performance? Say, also that I don't want to have to pay oodles of money for some server with a terabyte of memory to hold the application. Honest question - I haven't kept up with what's happening in Java land, and am curious what you'd recommend for that kind of side-project t…

Take a look at JHipster: https://jhipster.github.io.

Re: Why we choose Java instead of a polyglot stack

#88

Post by vbezhenar »

lmm wrote: post #17
burntcookie90 wrote: post #12

Earlier quoted context omitted.

I'd suggest taking a look at kotlin as well

Kotlin has most of the complexity of Scala, and very little of the power. If you want a clean language that offers Scala-like functionality, Ceylon is the one to watch.

I spent literally one evening reading Kotlin reference and I understood an entire language. It's just a Java with slightly altered syntax and a lot of simple yet useful batteries included. I immediately was able to start coding and reading standard library. On the other side in the past I spent around week reading book about Scala. Yet I couldn't read Scala library, it was just too complex. So I don't agree that their complexities are even comparable.

Scala is like a Haskell. It's very powerfull, but to understand and use the entire language, one should make a serious investment.

Re: Why we choose Java instead of a polyglot stack

#89

Post by keypusher »

throwaway437812 wrote: post #60
Freak_NL wrote: post #49

Earlier quoted context omitted.

Could you elaborate on that? With OpenJDK at least the software side of things is pretty much stable and open (in a FOSS sense), so I take you are referring to possible legal ramifications of Oracle's actions?

I never really managed to figure out the OpenJDK story apart from that it is what gets included in Linux distros and it sort of works. Read not too great stories about its performance in the past, am not exactly sure about its compatibility (it seems to lag behind a bit), Windows support is a whole complicated story of its own... Call me ignorant, but at first glance it doesn't look attractive. On top of all that, in…

We have shipped high-traffic production web applications using OpenJDK for years.

Re: Why we choose Java instead of a polyglot stack

#90

Post by fweespeech »

discreteevent wrote: post #78
fweespeech wrote: post #53

Earlier quoted context omitted.

> 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. Honestly, unless you are operating on thin margins due to your business structure ... this isn…

Good for you that you are in that kind of business. I've never worked on anything where we didn't need more performance in the end. And when you do need it you need it quick. Having an environment and tools (e.g. top class profilers) that make that possible is often the only way to get it done in time.

The OP's one-size fits all approach is simply wrong.

Simply because it is correct for a subset of organizations does not make it true for all organizations as the OP implied.

Post reply on HN