Live data from Hacker News

Why we choose Java instead of a polyglot stack

product.hubspot.com

61–70 of 155 posts

Re: Why we choose Java instead of a polyglot stack

#61
post #34

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…

Does Kotlin offer anything Rails like with batteries included? I'm steering away from Ruby. I love Rails but ruby becomes a monster when a project gets larger. I've looked at TypeScript and Express.js but I'm worried I gotta deal with type definitions a lot.

Take a look at the Play Framework or Ninja Framework.

Re: Why we choose Java instead of a polyglot stack

#62
post #58

Earlier quoted context omitted.

Express isn't like Rails. It's more like Sinatra, but has probably even less stuff. There's no official or popular Rails for Node yet. People have made stuff like Sails but not many use it.

It's rails like through its middleware pipeline design. That's a requirement for me. That allows Express third party middleware to add missing parts like Strong Params and easier HTTP Caching. It would be nice to have batteries included but not at the cost of a giant box still design that I suspect Sails and other have. Pipeline design is important and Express does that really good.

Gotcha, thought you meant something else. Thanks for clearing it up. Have you looked into koa[1]?

[1] https://github.com/koajs/koa

Re: Why we choose Java instead of a polyglot stack

#63

Earlier quoted context omitted.

Express isn't like Rails. It's more like Sinatra, but has probably even less stuff. There's no official or popular Rails for Node yet. People have made stuff like Sails but not many use it.

Keep in mind Sails has stagnated and there's a fork called TrailJS now. The NodeJS 3rd-party ecosystem is really really fragile at the moment.

Yeah that's what I meant. The Node ecosystem doesn't really care for Rails-like frameworks so they stagnate. Most Ruby companies run Rails. Most Node companies run Express, Hapi, or Koa. Not Sails.

Re: Why we choose Java instead of a polyglot stack

#64

Earlier quoted context omitted.

Yep. I've used a variety of different languages, and it always struck me as odd that Java was considered some uncool cumbersome language, and enterprise-y in some sort of bad way. It's not a dream to code in, but it is highly practical and in no way limits what you can do or makes anything particularly hard. I see now that I joined the Java party in better days.

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…

That's why I think Kotlin is going to clean up. It's a language specifically designed to be commercially successful by providing you with a better Java. For instance this line of code:

  data class Person(var name: String, val age: Int)
compiles down to a JavaBean with getName/setName type methods, a getAge but no setAge (val is immutable), an equals, a hashCode, a toString and a few other useful methods as well like copy() which lets you create clones of the object with any fields modified.

So with Kotlin you get many of the benefits of C# and some features that C# is only just introducing now, or in its next versions, but it all interops seamlessly with Java.

Re: Why we choose Java instead of a polyglot stack

#65

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…

OpenJDK performance has been closing the gap with the Oracle JRE over time. One big gap was different graphics renderers but this is being fixed in Java 9 (possibly earlier).

Java 8+ has a "javapackager" tool that makes native installers/packages for each platform which contain a bundled JRE. So your users no longer need one installed themselves. And finally SWT lets you use native widgets if you want them.

Re: Why we choose Java instead of a polyglot stack

#66
It did not seem to really address the issue of polyglot very much (given it is in the HN title) rather than just promoting the virtues of Java. One of the strengths of the JVM is the ecosystem of JVM languages that has evolved. You can stick with the JVM and get many of the benefits mentioned while still being polyglot. In particular you can throw in a dynamic language (Groovy, JRuby, Jython) alongside the Java core and get the benefits of a dynamic language for parts of the code where that is suitable, without losing many of the other benefits. Groovy, in particular, is 100% bidirectionally compatible with Java and has close enough syntax that a developer team well versed in Java will pick it up quickly. Perhaps Kotlin qualifies in this regard as well. To me the optimal setup is a strong Java core defining the APIs and core services, while the less core code can benefit from using more expressive dynamic languages. For example, the drudgery of writing unit tests is hugely alleviated by doing in something like Groovy rather than straight Java.

Re: Why we choose Java instead of a polyglot stack

#67
I will say, Java performance always impresses me. Trying a few benchmarks relating to economics, OpenJDK 1.8 somehow beats C++ and Fortran on my machine (!!!). And of course, there's plenty of nice, high performance JVM languages (Kotlin, Scala, Clojure), and you can tune the JVM a number of ways.

I can certainly imagine a future where Java is the top performing language for any application.

Re: Why we choose Java instead of a polyglot stack

#68
post #9
post #2

I work at HubSpot, and was among the initially skeptical from having had bad experiences in Java in the distant past and spent more time in Ruby in the years prior which I mostly enjoyed. The Java ecosystem truly saved itself from its own enterprise madness. Libraries and frameworks today look nothing like they did in the past. I think that is somewhat due to language features (annotations, lambdas, etc) but also due…

The blog post mentioned "modern java frameworks", can you specify which ones you're using?

Is there a guide to modern java frameworks and their use? I left java a while back when "EE" was full of shit.

Re: Why we choose Java instead of a polyglot stack

#69

Earlier quoted context omitted.

The post mentions a few: Dropwizard for RESTful APIs ( http://www.dropwizard.io which includes a bunch of good libraries), Guava, Guice, Hysterix, etc. We use Kafka for stream processing, Hadoop for batch processing.

Does that mean that you use JDBI for DB access?

SQL is just one type of DB language we use, but yes we use JDBI with some extensions we've built (such as https://github.com/HubSpot/Rosetta and other non-opensource) for our SQL database of choice, MySQL.

But we also use a number of other databases with native java clients, such as HBase and ElasticSearch.

Re: Why we choose Java instead of a polyglot stack

#70
post #42
post #32

Earlier quoted context omitted.

I'm really not a fan of these kinds of blanket statements where you lump everything into "JVM" or "failure". The JVM is a good platform for performance, stability, etc. but it's not the only one. The .NET ecosystem is pretty high up there for performance (and gives you a bit more room for fine tuning) and it easily has some of the best support in the industry (both 1st and 3rd party). And we've all seen success stori…

.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…

As a side note, Kotlin does properties very much like C# - take a look at it the next time you're doing Java and have a choice in the language.
Post reply on HN