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

171–180 of 233 posts

Re: Rise and fall of JVM languages

#171

Post by coldtea »

pjmlp wrote: post #104
norswap wrote: post #74

Earlier quoted context omitted.

Kotlin is essentially Java with some sugar sprinkled on top. That's its strength: the semantics & the concepts are the same. I also never said Kotlin will replace Java, but that it will gradually grow to the detriment of Java, which is still here to stay.

I don't believe Kotlin will get much strong outside Android. In all these years of alternative languages customers still don't allow us to use anything other than plain Java.

>In all these years of alternative languages customers still don't allow us to use anything other than plain Java.

That's because all those years those alternative languages never got much traction except Scale.

Kotlin is already poised to reach hundreds of thousands through Android support.

Re: Rise and fall of JVM languages

#172

Post by ido »

kpil wrote: post #149
qyv wrote: post #97

Earlier quoted context omitted.

> it's a Fortran or Cobol situation, only maybe three or four orders of magnitudes bigger. You underestimate the amount of COBOL code that is still out there running our daily lives: http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Web...

I've done work for a fair number of banks and insurance companies, and my anecdotal impression is that there is always a java system siphoning data from the cobol systems... Both stay around for the same reason: backwards compatability and a stable api+abi. If you find and old Java system it's often trivial to do changes and recompile. Even a few years old C program is often problematic due to changes in the OS or li…

Js isn't usually compiled at all! And old sites using old js generally still work in modern browsers.

Re: Rise and fall of JVM languages

#173

Post by kuschku »

le-mark wrote: post #168
rsynnott wrote: post #70

Earlier quoted context omitted.

Ugh, yes, so I did, though that was less about software deployment.

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…

> The other stuff like JNI (a registry for RPC endpoints) and java rmi itself were baked into the standard libraries from the beginning as well. But the envisioned "software agents running on arbitrary machines on the network" never took off, seems kind of foolhardy in hindsight, that anyone would think that's a good idea.

Well, we’re back to it with webassembly now. Everything old is new again.

Re: Rise and fall of JVM languages

#174

Post by kuschku »

jabl wrote: post #142
berdario wrote: post #61

Earlier quoted context omitted.

Have you seen Frege and Eta? https://github.com/Frege/frege http://eta-lang.org

eta looks interesting for Haskell refugees in Java-land.. That being said, any idea why they started from scratch instead of building on or contributing to frege?

They had ideological differences, Frege focusing on the Haskell standard, Eta on "whatever GHC does".

Re: Rise and fall of JVM languages

#175

Post by jimbokun »

pjmlp wrote: post #40
norswap wrote: post #32

If the language designers keep their heads, Kotlin will slowly eat away at Java. Java itself is never going away: it's a Fortran or Cobol situation, only maybe three or four orders of magnitudes bigger. Xtend never was alive, and it's clear Ceylon has lost at this point, even though it is arguably better designed than Kotlin. However, they made some bad syntactic decisions (not shedding enough of the Java verbosity,…

Kotlin can never replace Java as long as the JVM is relevant. This is like trying to replace C on UNIX, C# on .NET, Erlang on BEAM, or JavaScript on the browser.

But it could play the same role for Java that C++ played to C.

Re: Rise and fall of JVM languages

#176

Post by edem »

lmm wrote: post #87
edem wrote: post #82

Earlier quoted context omitted.

Not really. If you check google trends now you can see that it _surpassed_ Scala after the Google announcement and while it was a bump in trends if you extrapolate the trend it you can see that it will surpass Scala within a year. Higher kinded types in themselves don't have any business value so I don't see why it can't be displaced by Kotlin or Clojure. I don't see any "anti-intellectual hostility" either. Actually…

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

> Clojure has a clean design as far as it goes, but the design is so spare that to do anything practical in it relies heavily on macros. [...] macros are too powerful to be able to reason about code that uses them

That's why Clojure has spec. It solves the reasoning problem. It is also incorrect to assume that you can't do anything practical without macros, it is quite the opposite. You can do anything without them but there are some special cases where macros are useful. You can read any lisp textbook and you will see this in every one of them. If you write any lisp code then you have to know that for your first few projects you will overuse them, then you might learn where they are really applicable.

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.

Re: Rise and fall of JVM languages

#177

Post by canes123456 »

Spivak wrote: post #152
tootie wrote: post #126

Earlier quoted context omitted.

Java will slowly absorb useful features from Kotlin until it's no longer necessary.

And eventually the C++ification of Java will scare away new developers who don't have years of context that explains the organic growth. Languages encumbered by backwards compatability and bolt on new features will eventually collapse under their own weight.

Ah yes, it will die just like C++. Backwards compatibility focus languages are the only ones that live long enough to be old and encumbered.

Re: Rise and fall of JVM languages

#178

Post by dionian »

vbezhenar wrote: post #34
ojosilva wrote: post #24

I wonder why Kotlin beat Scala in this virtual programming language traction game. I don't write code for the JVM anymore, but Kotlin occupies the same space as Scala. Was it compilation speed? Corporate support?

Scala is much more complex language. Kotlin is more complex, than Java, but its complexity is just enough to cover major Java pain points. Scala brings its own huge library with features that I don't need. Billions of abstract collections, but all I need is HashMap and ArrayList. They generalize over builders, so `filter` can return some fancy underlying class, but all I need for filter is to return ArrayList or lazy…

> Last time I checked, Intelij Idea wasn't able to parse even standard Scala library without errors.

Kotlin is a much simpler language than Scala.

Re: Rise and fall of JVM languages

#179

Post by dionian »

vram22 wrote: post #119
izacus wrote: post #30

Earlier quoted context omitted.

Probably because it was built to seamlessly interoperate with existing Java code and targeted JVM 6 compatibility (it was built to make development of IntelliJ IDEs simpler which had to run on Java 6 VMs and which already had a lot of code written in Java). As such it turned out to be a natural fit for Android apps as well, because the platform has pretty much the same type of limitations. Other nice things: - Standa…

>it fixes A LOT of Java pain points What are the pain points it fixes?

null

Re: Rise and fall of JVM languages

#180

Post by 0xbear »

I wish .net CLR would take its place instead. For one thing, as strange as that may sound, I trust today's MS more than I trust Oracle. For another, CLR as of 12 years ago (not to mention now) was already better suited for programming language development than JVM ever will be, owing to having less baggage and reified generic types support built in from the start.
Post reply on HN