Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rise and fall of JVM languages

blog.frankel.ch

Post reply on HN
Print view View original

221–230 of 233 posts

Re: Rise and fall of JVM languages

#221

Post by cutler »

vram22 wrote: post #216
cutler wrote: post #194

Earlier quoted context omitted.

I believe Kotlin code runs close to Java speed which is another reason it might catch on.

Good point. Looking a bit like Kotlin is worth checking out, based on the comments in this thread, and also that other one some days ago, which was triggered by Steve Yegge's post about it. The only one drawback I can think of as of now, is that it is only being developed by one company - JetBrains (unless it is open source and allows and has contributors, which I have not checked). Update: I checked, it is open sour…

These days a new language which isn't open source wouldn't have much of a chance, I reckon.

Re: Rise and fall of JVM languages

#222

Post by bogomipz »

vbezhenar wrote: post #77
bogomipz wrote: post #54

Earlier quoted context omitted.

>"Kotlin is more complex, than Java, but its complexity is just enough to cover major Java pain points." Would you mind elaborating on what those Java pain points are that Kotlin smoothes over? Also are people deploying Kotlin on the server side or do you see that being a thing in the future? For some reason I have this(perhaps incorrect) association Kotlin only in the context of Android. But maybe that's incorrect?

> Would you mind elaborating on what those Java pain points are that Kotlin smoothes over? 1. Explicit semantics for nullable variables. It helps to convey information whether this function can accept or return null and compiler checks that your code won't throw NullPointerException. It's not ideal when you're dealing with Java code, but it works. 2. Explicit and convenient semantics for mutable and immutable variabl…

Thank you for the detailed response. Cheers.

Re: Rise and fall of JVM languages

#223

Post by AzzieElbab »

collyw wrote: post #220
AzzieElbab wrote: post #183

Earlier quoted context omitted.

Then don't. I couldn't think of two more different languages.

Whats so bad about Scala? It does seem to get a similar "either you love it or you hate it" response from people.

I think the audience is the problem. Java devs prefer Java and Haskell devs prefer Haskell. Aside from some rare open minded individuals and people who have to write java, but would prefer to work with Haskell, Scala is up against a tough crowd.

Re: Rise and fall of JVM languages

#224

Post by lmm »

cutler wrote: post #219
lmm wrote: post #215

Earlier quoted context omitted.

Huh? Everything worth bothering with is in maven central, the same place as all the Java libraries worth bothering with.

Ask yourself why Clojure, which is also a JVM language, has Clojars. What happens if I want to browse Scala libs I don't already know about?

I don't think I've ever browsed through any language's set of libraries - for any serious language there are far too many libraries for that to be useful. The only reason I've ever used e.g. PyPI is to look for a library for doing something specific, and I've never had trouble finding libraries for doing a given thing in Scala.

Re: Rise and fall of JVM languages

#225

Post by lmm »

edem wrote: post #176
lmm wrote: post #87

Earlier quoted context omitted.

> Higher kinded types in themselves don't have any business value They make it much easier to fulfil business requirements in a clear, maintainable way (and mean there's a huge space of libraries available to help with that), which is what programming is all about. > I like how Clojure works much more (you can opt-in to any extra features Clojure has to offer and they are not forced on you) compared to Scala. What ex…

> They make it much easier to fulfil business requirements in a clear, maintainable way Same stands for dsls, macros, multimethods, I can mean any feature in any language. HKTs are just one tool of many. > What exactly is "forced on you" in Scala? Any built-in language feature. For example no matter what I do `implicit` will be a reserved keyword and the language will make use of it. I can't opt out. In Clojure on th…

> Same stands for dsls, macros, multimethods, I can mean any feature in any language. HKTs are just one tool of many.

Would you say those features have no business value then? I've met enough business problems that were best modelled with HKT that I don't believe a language without an equivalent feature could be as effective.

> Any built-in language feature. For example no matter what I do `implicit` will be a reserved keyword and the language will make use of it. I can't opt out.

Almost all languages have some keywords. But yeah, implicit is a language-level feature. It's got a very high power-to-weight ratio though; it has valuable use cases (typeclasses, extension methods, the magnet pattern) that couldn't otherwise be done in plain old code, unless all those things were their own language-level features.

> In Clojure on the other hand there is [spec](https://clojure.org/guides/spec) for example. If I want it I import it and all of its features are defined in terms of Clojure itself. The whole language feature is a library. I can add [the language itself](https://mvnrepository.com/artifact/org.clojure/clojure/1.8.0) as a library to my project (which is what I do with Kotlin) and use all of its features like the STM, or persistent data structures. Can you do the same with scala? I doubt it.

Plenty of Scala things are libraries, you absolutely can import the scala standard library and use its collections, its async implementation or the like from another JVM language (though they may not be terribly idiomatic there). I don't really see the distinction you're drawing?

> Name some special cases in Kotlin which are problematic. I can't name a single one from the top off my head despite the fact that I use the language for more than a year.

Nullable types are a special case that doesn't compose properly (null is expected to be used for errors but if you write generic code that does that and then one of the values you pass in is null then you've got a bug), and a special case in the syntax (can't write your own type that allows ?. if you want to e.g. include a reason-for-failure message). Platform types for Java interop are a special case (you can't always pull out repeated calls to a Java method into a utility method without changing the meaning). Extension methods are a special case (can't use them to implement an interface). Operators are a special case (can't have an interface that requires them).

Re: Rise and fall of JVM languages

#226

Post by le-mark »

gaius wrote: post #205
le-mark wrote: post #168

Earlier quoted context omitted.

None of these examples are especially illuminating here. In my opinion, two things really exhibit this "code over the network" nature; the class URLClassloader that's been in Java forever and the JVM SecurityManager system. URLClassLoader will load bytecode from any url; give it a url to a jar at some domain and it'll load it. The JVM security model was intended to let app developers define exactly what code could be…

software agents running on arbitrary machines on the network" never took off, seems kind of foolhardy in hindsight We call software agents "containers" now and arbitrary machines on the network "cloud" but it is the same thing...

That's really not even closely related. Please educate yourself so I can have intelligent discussions.

https://en.wikipedia.org/wiki/Software_agent

Re: Rise and fall of JVM languages

#227

Post by rusk »

shakna wrote: post #209
shagie wrote: post #164

Earlier quoted context omitted.

That is very true - there is a lot of cobol out there. Fortunately, it has a JVM target too. http://documentation.microfocus.com/help/index.jsp?topic=%2F...

Wouldn't the JVM's warmup time make it untenable for most places COBOL is used?

What places are these? I thought Cobol ran on server-side mostly? JVM is always warm.

Re: Rise and fall of JVM languages

#228

Post by shakna »

rusk wrote: post #227
shakna wrote: post #209

Earlier quoted context omitted.

Wouldn't the JVM's warmup time make it untenable for most places COBOL is used?

What places are these? I thought Cobol ran on server-side mostly? JVM is always warm.

Maybe I can better explain with an example, but it comes from the only time I've worked with Cobol professionally, and I have avoided it since. My experience is limited, and might not be the norm.

It was a bank, and transactions were processed through a pipeline.

Part of that pipeline was handing off transaction data from an always-active system, but then into many, many short-lived Cobol processes, and then into another always-active system.

The Cobol processes basically munged, pulled and pushed to database/s, and then killed itself.

In this case, I could see warm-up time being a huge issue, though a switch into another language might bring a change in architecture to threading and the like which would remove that problem, but I can't see a bank changing architectures easily.

From my limited exposure, several financial companies connected with the bank had similar processes. Something like Java or C running a server, Cobol when numbers need serious crunching, and then back into another server application.

(Incidentally, both the server processes were Fortran, if that's interesting to anybody).

Re: Rise and fall of JVM languages

#229

Post by rusk »

shakna wrote: post #228
rusk wrote: post #227

Earlier quoted context omitted.

What places are these? I thought Cobol ran on server-side mostly? JVM is always warm.

Maybe I can better explain with an example, but it comes from the only time I've worked with Cobol professionally, and I have avoided it since. My experience is limited, and might not be the norm. It was a bank, and transactions were processed through a pipeline. Part of that pipeline was handing off transaction data from an always-active system, but then into many, many short-lived Cobol processes, and then into ano…

I think I understand what you're saying but cobol runs in an environment that is optimised for cobol, and I'd expect where this were to be java you would have a similar arrangement in place. For a trivial example of what I'm talking about check out nailgun [0]

[0] http://www.martiansoftware.com/nailgun/

Re: Rise and fall of JVM languages

#230

Post by shakna »

rusk wrote: post #229
shakna wrote: post #228

Earlier quoted context omitted.

Maybe I can better explain with an example, but it comes from the only time I've worked with Cobol professionally, and I have avoided it since. My experience is limited, and might not be the norm. It was a bank, and transactions were processed through a pipeline. Part of that pipeline was handing off transaction data from an always-active system, but then into many, many short-lived Cobol processes, and then into ano…

I think I understand what you're saying but cobol runs in an environment that is optimised for cobol, and I'd expect where this were to be java you would have a similar arrangement in place. For a trivial example of what I'm talking about check out nailgun [0] [0] http://www.martiansoftware.com/nailgun/

Yes, a change to Java would require a large architecture change. Notably from mainframes to something a little bit more familiar to most people.

But when Cobol works, is blisteringly fast, and they can afford to hire and train people to work with it, I don't see the benefits of Java, at all. Especially not at the enormous costs of a major architecture re-work in systems that are live 24/7, and downtime is counted in milliseconds.

Having to work around the JVM is just icing on the cake.

Post reply on HN