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

131–140 of 155 posts

Re: Why we choose Java instead of a polyglot stack

#131

Post by lmm »

vbezhenar wrote: post #88
lmm wrote: post #17

Earlier quoted context omitted.

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

That's because Kotlin puts the complexity in the language and Scala puts it in the libraries. A lot of things are just a rule of the language in Kotlin but they're implemented in ordinary code in Scala. E.g. extension methods. Which means you can "understand" them quicker in Kotlin, but you can't change how they work or use them to implement a new structure.

Re: Why we choose Java instead of a polyglot stack

#132

Post by lmm »

evacchi wrote: post #80
lmm wrote: post #17

Earlier quoted context omitted.

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.

could you expand further on this? I actually believe Kotlin to be much simpler than Scala

Have replied to sibling, hopefully that makes my views clearer.

Re: Why we choose Java instead of a polyglot stack

#133

Post by evacchi »

lmm wrote: post #131
vbezhenar wrote: post #88

Earlier quoted context omitted.

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

That's because Kotlin puts the complexity in the language and Scala puts it in the libraries. A lot of things are just a rule of the language in Kotlin but they're implemented in ordinary code in Scala. E.g. extension methods. Which means you can "understand" them quicker in Kotlin, but you can't change how they work or use them to implement a new structure.

> 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 avoid implicit conversions per se.

E.g., I'd rather be explicit about a type conversion when that is what I want to achieve: for instance, I'd rather read `javaListMethod(mySeq.asJava)` than `javaListMethod(mySeq.asJava)`. Thus, I'd rather have a first-class construct for extension methods rather than having to write `implicit class RichSeq(val s: Seq) extends AnyVal { def asJava = ... }`

In this case I do prefer Kotlin.

Re: Why we choose Java instead of a polyglot stack

#134

Post by lmm »

evacchi wrote: post #133
lmm wrote: post #131

Earlier quoted context omitted.

That's because Kotlin puts the complexity in the language and Scala puts it in the libraries. A lot of things are just a rule of the language in Kotlin but they're implemented in ordinary code in Scala. E.g. extension methods. Which means you can "understand" them quicker in Kotlin, but you can't change how they work or use them to implement a new structure.

> 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 impossible. I'm hopeful that a simpler underlying abstraction can be found - but Kotlin feels to me like it's just piling on a bunch of special cases without making any effort to be consistent or unified.

Re: Why we choose Java instead of a polyglot stack

#135

Post by lmm »

SiVal wrote: post #99
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 keep wondering how Java compares to Go these days. I'm not advocating Go, just wondering how much of an advantage Java has for server-side "web applications and services" for new businesses that are the usual small to medium scale with a single-digit number of developers and no legacy vs giant enterprise scale. It just sounds as though the advantages of Java help large, complex systems of services and developers mo…

Java and Go are pretty similar at the language level, and you're right that the advantages of both are more applicable in large systems. For a small business situation something like Ruby may well be a better choice.

Java has a more powerful type system (though still poor by modern standards). Both have weaknesses regarding error handling - Go encourages you to err on the side of repetitive code, Java encourages you to err on the side of handling errors only at very high level, I'm not sure which is worse. Java has a much bigger ecosystem and better tool support, though a lot of it is written for pre-C10K days and assumes a "1 thread per connection/request" model - but frankly for a small business type situation that's fine. The go concurrency model is overkill at the low end and not flexible enough at the high end, but if you're in the sweet spot then you can write code more efficiently there than in Java.

Re: Why we choose Java instead of a polyglot stack

#136

Post by lmm »

jcrites wrote: post #48
nv-vn wrote: post #38

Earlier quoted context omitted.

I don't really know how most of these relate to Haskell specifically. For example, you bring up safety and the exception model used in Java, but Haskell puts an even higher priority on safety/correctness than Java does. IDE support may be weaker, but IDEs tend to solve problems very specific to the languages they target, namely Java in this case. Refactoring is seen as much less of a problem, for example, since the l…

These are the kinds of questions I'd be concerned with: Can I easily develop Haskell from any platform (Windows, Mac, Linux) and are good IDEs available on all of them? My team is diverse and I don't want to tell my engineers what platform they have to use for development. Can I meaningfully develop my server software on those platforms and deploy it to another OS (Linux)? I agree that Haskell's type system will catc…

Those are absolutely the correct kind of questions to be asking. I think Haskell has very good answers to most of them, sometimes better than the answer for Java. I actually use Scala pretty much full time these days myself, but I think the original post was overstating the case for the JVM. I agree with the value of a single runtime, good instrumentation, and avoiding non-memorysafe or non-crossplatform code, but the JVM is absolutely not required to accomplish those things.

Re: Why we choose Java instead of a polyglot stack

#137

Post by lmm »

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

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

Re: Why we choose Java instead of a polyglot stack

#138

Post by lmm »

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

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 database access), but it gets out of your way a lot, has a very clean separation between the framework and your code (no magic)); it's probably the best example of good OO I've seen, in any language, with a component model that really works where all your pages are reusable components made of reusable components that are themselves made of reusable components, and there's a really clear separation between markup and logic.

If I'm writing a "web API" I use spray. It has this DSL that lets you write routing definitions which are as clear as a config file but are ordinary code obeying all the rules of the language, so you can safely refactor them the normal way. And it works very nicely with the scala type-system, letting you separate out cross-cutting concerns like logging or database transactions in ways that are low-overhead but visible and safe (and it's natively async, so can be incredibly high performance, not that I've ever needed that). For a "single page application" scenario I've used a TypeScript frontend (in angular) talking to a spray backend (I'd like to try out Scala.js soon).

Re: Why we choose Java instead of a polyglot stack

#139

Post by lmm »

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

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

I think it will fail in the same way as Xtend or (to a certain extent) perl. It puts too much focus on one-off productivity features which results in an inconsistent language with loads of edge cases, and it doesn't have any compelling "you can't do this in Java" selling points, just a bunch of minor syntax sugar.

Ceylon has all the advantages of Kotlin, but put together a lot more coherently, and with a really compelling fundamental feature (union types).

Re: Why we choose Java instead of a polyglot stack

#140

Post by lmm »

edem wrote: post #19
brianpgordon wrote: post #11

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…

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…

Types on the end are very common in many languages, a lot more common (and IMO readable) than lisp-style (+ a b) which you have to learn to use clojure.

An optional type system is almost useless (believe me I spent a lot of time trying to use the checker framework in Java before switching to Scala), because libraries don't have to follow it, and you never know whether the type definitions for a given library are true or not.

Scala is generally immutable by default and has persistent data structures.

STM is great but you can do it fine in Scala. It's just not a language-level feature because it doesn't need to be - Scala is expressive enough that you can write an STM implementation in a library.

Scala's DSL support is great (look at e.g. Spray route definitions) and can usually done in ordinary code without macros, which in turn means you have full IDE and tool support for them. The trouble with lisp DSLs is that your syntax still has to look like lisp - the support for e.g. infix operator syntax is quite limited (you have to use reader macros which are more complicated and harder to work with). But for a lot of business domains the natural language of the domain uses infix operators.

Post reply on HN