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.
Why we choose Java instead of a polyglot stack
61–70 of 155 posts
Re: Why we choose Java instead of a polyglot stack
#62Earlier 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.
Re: Why we choose Java instead of a polyglot stack
#63Earlier 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.
Re: Why we choose Java instead of a polyglot stack
#64Earlier 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…
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
#65Earlier 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…
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
#66Re: Why we choose Java instead of a polyglot stack
#67I 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
#68I 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?
Re: Why we choose Java instead of a polyglot stack
#69Earlier 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?
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
#70Earlier 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…