Live data from Hacker News

Why we choose Java instead of a polyglot stack

product.hubspot.com

51–60 of 155 posts

Re: Why we choose Java instead of a polyglot stack

#51
post #34

Earlier quoted context omitted.

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.

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

#52
Maybe for the backend, but for the frontend Java has messed up really bad. Some of the worst aberrations ever created in the history of software development are Java frontend frameworks: think JSF to start.

There is nothing like Javascript for the frontend, and if its for developing micro-services and not monoliths I think Javascript is also a pretty good choice for the backend as well. There are some good solid libraries like express, sequelize, passport.js that be used to build solid micro-service backends, in every way comparable in functionality and performance to Java.

Re: Why we choose Java instead of a polyglot stack

#53

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.

Honestly, unless you are operating on thin margins due to your business structure ... this isn't really an issue.

Pretty much anyone with well padded margins that the primary cost is engineering time or product costs [e.g. Physical products to ship] this is a complete non-issue as long as the datastore/service architecture is designed for horizontal scaling.

I'm constantly amazed by the tribalism of developers and the delusion that language performance is in any way relevant.

The reality is you need to just stick with one language so you can keep your engineering talent, tooling, etc. consistent due to the economies of scale of avoiding duplication of effort [libraries, learning time, tooling, etc]. The gain is in terms of engineering costs, not hardware costs.

The language, honestly, just does not matter when we can have a 10 man IT team with ~$50k/year in hardware handling a $100mil/year in business with good margins. It just doesn't even register.

Re: Why we choose Java instead of a polyglot stack

#54
post #52

Maybe for the backend, but for the frontend Java has messed up really bad. Some of the worst aberrations ever created in the history of software development are Java frontend frameworks: think JSF to start. There is nothing like Javascript for the frontend, and if its for developing micro-services and not monoliths I think Javascript is also a pretty good choice for the backend as well. There are some good solid libr…

> I think Javascript is also a pretty good choice for the backend as well.

Definitely not for me and for a few of my buddies who happened to use NodeJS already. NodeJS is a good "glue" appserver for gateway to other microservices I give kudos that far but not more.

Re: Why we choose Java instead of a polyglot stack

#55
post #4

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

the 90s called and they want their comment back

I remember the same comments about Smalltalk. Now the average jpeg or js file the browser downloads is larger than most Smalltalk images.

Re: Why we choose Java instead of a polyglot stack

#56
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.

All the Java frameworks are usable in Kotlin. I don't know any specific that covers all the bases Rails does - what I usually see are patchworks and a lot of SpringCore/JPA/Hibernate.

Personally, my go-to choice is always something simpler (eg Netty, Vertx, Spark etc - those are more like Express.js or Sinatra than Rails).

There's also JavaLite, which explicitly tries to look like Rails (including database migrations, an ActiveRecord-style ORM, etc)

Re: Why we choose Java instead of a polyglot stack

#58
post #34

Earlier quoted context omitted.

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.

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

#59

I agree that Java is the best programming language to write web services in right now. But I have to admit that the most threatening counter-argument to using Java in 2016 is that Scala is, to all appearances, a strictly better language. It's similar to Java and does everything Java does, but better- it has type inference, it does away with primitive types and arrays, it has compiler-checked string interpolation, it…

> When you find that you need to use a small class from a library, you pray that it's written in Java, because most of the time you can just go to its source in your IDE

I have to say, this is the big plus for Java for me. I find myself in the weird position that while I dislike writing Java, I love reading it. The simplicity and constrained nature of the language, the incredible IDE support, the JVM features (connect to a running VM and start setting breakpoints to answer questions like "when does this method get invoked"), etc. It's hard to escape the logic that if I want people to like reading my code, I ought to be writing it in Java.

Re: Why we choose Java instead of a polyglot stack

#60

Much of this makes sense, but the main thing that keeps me from using Java is the dark cloud hanging over it, called Oracle.

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, indeed Oracle being involved with development at all, together with their reputation of being a legal hothead.

Not mentioned in my initial post, but I also like to keep my code portable between server and client. Firstly, there's no way I'm going to require clients to have Java installed. Secondly, a truly native GUI is practically impossible, so I would already corner myself into needing a second language anyway.

Post reply on HN