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

141–150 of 155 posts

Re: Why we choose Java instead of a polyglot stack

#141

Post by lmm »

zmmmmm wrote: post #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…

Groovy feels like it's dying as far as I can see - partly because you can write almost word-for-word the same code in Scala and not have to sacrifice type safety.

Re: Why we choose Java instead of a polyglot stack

#142

Post by conventionalmem »

lmm wrote: post #137
conventionalmem wrote: post #77

Earlier quoted context omitted.

Agreed, it's crazy that there are engineers in this world that can make blanket statements like this, especially on a site like HN. There are a lot of great languages/frameworks, and it depends on the needs you have and your team. (I'm so fatigued by this view I hear so regularly expressed in web dev that "X is the solution to everything" - no, it's very rarely the case)

I'm more fatigued by the constant "use the right tool for the job" - impossible to argue with, and utterly useless advice for actually making decisions. Some tools really are better than others, and there is a lot of value in standardizing on a single platform. http://www.teamten.com/lawrence/writings/java-for-everything...

Sure, but let's have that debate, and set down a philosophy around that. What you're arguing is not that Java is everything - but that a polyglot stack has dangers, that certain tools are often unobjectably better than others, and that we shouldn't sugar coat that. I agree, as would many of our friends in the space.

But if you're saying that everyone who is in Javascript, Ruby, Python, Go, PHP (and others) should all refactor into Java because it's the one and only ideal web backend in 2016 (or design new apps exclusively in Java) - I could pick a 1000 holes in that argument. The original comment I reacted to was:

> If you're not picking the JVM in 2016 to build your core services and web applications then you're making a mistake

My apologies if this comes across negatively (which I don't intend, as this is a respectful debate among people who care deeply about their craft) - but I'm just not convinced that you're really a full supporter of the original commenter. Your blog seems to show a fair degree of pragmatism (you consider other languages/frameworks, might use them, are ok if your friends are not using Java). I'm totally fine with "I think the majority of people should use Java" (I don't fully agree with that, but in a world where many people knew that ecosystem, I think it's a great choice) - but the commenter went much further. If s/he is looking to start a debate, then I'm fine; if that person would join any company and religiously uphold that viewpoint, I don't think they'd be the right person for many companies.

P.S. If I'm wrong, and if Java is the ecosystem that for the next few years the rules them all, I really want to make a Lord of the Rings-inspired meme about it

Re: Why we choose Java instead of a polyglot stack

#143

Post by Mikeb85 »

lmm wrote: post #138
seivan wrote: 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.

Kotlin is pretty immature (and overhyped, IMO). Some people like Play and that's probably the closest JVM equivalent to Rails. I find the monolithic "batteries included" frameworks are part of the problem with large projects and it's better to have small well-encapsulated libraries that you can put together yourself. I work in Scala and I use Wicket for HTML pages (technically a framework (though decoupled from any d…

Just curious, how do you figure Kotlin is over-hyped? Seems to me it has good tooling support, incredibly easy Java interop, and seems to produce more or less the same JVM code as Java (so good performance). All the while being slightly more pleasant to work with.

Re: Why we choose Java instead of a polyglot stack

#144

Post by swah »

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…

Some people will always go with lighter systems, see how big Go is getting. And then integrate the subsystems with RPC.

That said, Clojure + Java is a sweet combination, they are pretty complementary IMO.

Re: Why we choose Java instead of a polyglot stack

#145

Post by lmm »

Mikeb85 wrote: post #143
lmm wrote: post #138

Earlier quoted context omitted.

Kotlin is pretty immature (and overhyped, IMO). Some people like Play and that's probably the closest JVM equivalent to Rails. I find the monolithic "batteries included" frameworks are part of the problem with large projects and it's better to have small well-encapsulated libraries that you can put together yourself. I work in Scala and I use Wicket for HTML pages (technically a framework (though decoupled from any d…

Just curious, how do you figure Kotlin is over-hyped? Seems to me it has good tooling support, incredibly easy Java interop, and seems to produce more or less the same JVM code as Java (so good performance). All the while being slightly more pleasant to work with.

I think it's strictly worse than Ceylon - less mature, less featureful, and a lot less well designed.[1] And JetBrains have a bad habit of advertising features long before they're actually implemented, as well as talking up Kotlin for about a year and a half before it had any kind of stable release.

[1] And frankly if there's nothing it can do that Scala can't and the design isn't any cleaner than Scala (arguable, but I feel Kotlin is very ad-hoc and will look worse than Scala by the time it reaches the same age) then I'll just stick with Scala - whereas Ceylon can make at least some case for migrating from Scala.

Re: Why we choose Java instead of a polyglot stack

#146

Post by anthonybsd »

nv-vn wrote: post #32
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…

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…

I agree with you - generalizations are never a good thing. I did however, have negative experiences with .NET in the enterprise space. I worked in C# for a few years improving some web services for a Finance company. This was long before Java 7 even, so as a language C# 4.0 seemed amazing to me at the time. Lambdas, LINQ etc, - I was blown away. Microsoft ecosystem, however was not really wowing me in any way. There wasn't for example any sort of equivalent to JMS in Microsoft land - MSMQ was simply pathetic in terms of functionality. Apache Active MQ for .NET wasn't really mature at that point. Then, there is the Microsoft SQL server which, again is not really good at any particular thing.

Re: Why we choose Java instead of a polyglot stack

#147

Post by evacchi »

lmm wrote: post #134
evacchi wrote: post #133

Earlier quoted context omitted.

> you can "understand" them quicker in Kotlin, but you can't change how they work or use them to implement a new structure. I'm not sure that extension methods are a particularly fitting example here. Scala adds a lot of boilerplate for — in my view — very little gain. Of course, Scala's extension methods are actually a special case for implicit conversions; yet, the Scala we write today in my experience tends to avo…

Boilerplate is a problem but doesn't make a language harder to understand. Language-level shortcuts to reduce boilerplate generally make the language harder to understand, IME (I'm thinking of e.g. Perl's $_). I actually agree that implicit conversions are to be minimized. But you do need a way of doing the equivalent of the magnet pattern - which in Kotlin is either a different language-level feature, or simply impo…

You won't be able to implement type classes. There might be something in that direction after 1.0; still, Kotlin is not supposed to be a contender with Scala w.r.t. expressive power. It is just Java with more concise syntax, and with most design patterns turned into language features: singleton, delegates, lambdas/sam, "utils" classes (extension methods).

Re: Why we choose Java instead of a polyglot stack

#148

Post by autoreleasepool »

autoreleasepool wrote: post #85
scott_s wrote: post #28

Earlier quoted context omitted.

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 }

Correction: Function name.

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

Re: Why we choose Java instead of a polyglot stack

#149

Post by chipgap98 »

karmapolice wrote: post #129
champion wrote: post #96

Earlier quoted context omitted.

This is a good place to start: https://github.com/cxxr/better-java

So, is the idea to avoid ORM, JSF, JavaBeans, CDI Beans and all JavaEE in general? How is web application development done? I guess the back-end is made in Java with an API, and another language is used for the front-end.

Yeah we're using javascript with react/flux on the front end

Re: Why we choose Java instead of a polyglot stack

#150

Post by Bjartr »

paulddraper wrote: post #106
Bjartr wrote: post #92

Earlier quoted context omitted.

Tell that to the 4.5GB of RAM my Eclipse instance is sucking down at the moment.

Try Atom.

I prefer VIM, but I still need Eclipse to do my job effectively due to circumstance.

Like Eclipse only plugins whose functionality I would have to take time I can't justify to duplicate. Plus the additional maintenance cost of the dev team no longer having a homogeneous environment. All to allow me to be able to... do what I already do.

Don't get me wrong, I'd really enjoy taking a week to explore the options and put together a better development environment for myself and my team. I do make improvements where I can already. But we're already an effective team despite Eclipse's flaws, the RoI just isn't there from a business perspective.

Post reply on HN