I'm JVM guy and really wish this platform has something like F# - "minimalistic" functional language (not like Scala) with static, powerful type system (not like Clojure).
Have you seen Frege and Eta?
Rise and fall of JVM languages
61–70 of 233 posts
Re: Rise and fall of JVM languages
#62Earlier quoted context omitted.
Well I am a Java guy and have two points to make. First. What are you even talking about? Quiet:test user$ time java Test Test real 0m0.104s user 0m0.074s sys 0m0.028s Quiet:test user$ That's on a current MBP 13" top end. And second: Who cares? What us "Java guys" do with Java, well, it doesn't matter in the slightest that it takes half a second to start. Because, we deploy to running processes. "We" power things lik…
The obsession with this is that people would like to be able to use their favourite JVM language to write CLI tools, consumer-GUI tools or AWS lambda programs. Sure, you can just say that the JVM is the wrong tool, but that is a somewhat unsatisfying answer because it still doesn't let me write those things in clojure/scala or whatever JVM language.
They can, it is their problem if they keep ignoring the existing AOT compilers, and there are quite a few.
Re: Rise and fall of JVM languages
#63Earlier quoted context omitted.
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…
>"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?
That's incorrect. Right now I do all my development in Kotlin at my workplace and on the backend. We use Spring (which has native Kotlin support from 5.0 btw: https://spring.io/blog/2017/01/04/introducing-kotlin-support...) and deploy to a Kubernetes cluster. It is absolute seamless. I'll never write server-side code in Java again if I can help it.
Re: Rise and fall of JVM languages
#64I 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?
> 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. If you look at the graph in the post, it didn't; Scala is substantially more popular. Kotlin is just at a different point in the hype cycle.
That's incorrect. Scala had 13 years to achieve something while Kotlin is only around for a few years. If you extrapolate the current trends you will see that Kotlin will surpass Scala __very__ soon.
Re: Rise and fall of JVM languages
#65The whole getter/setter argument is trite. Project Lombok has been around for years and resolves that issue as well as many more.
Lombok has a lot of issues. First and foremost it won't compile for people who don't bother installing it for their IDE. This greatly hampers OSS collaboration because it raises barriers of entry. I know there is delombok but the whole stuff comes with a lot of drawbacks. Reorganize my project just to delombok my project...whoa...
Re: Rise and fall of JVM languages
#66The whole getter/setter argument is trite. Project Lombok has been around for years and resolves that issue as well as many more.
You end up needing more-or-less your whole ecosystem to understand Lombok - your IDE, debugger, profilers, linters, code coverage tools... it ends up being just as much effort as switching languages.
Yep, my thoughts exactly. I tried lombok when I was coding in Java and ended up dumping it beause it had more issues than it tried to solve.
Re: Rise and fall of JVM languages
#67The whole getter/setter argument is trite. Project Lombok has been around for years and resolves that issue as well as many more.
True, but it's not trivial to adopt.
Re: Rise and fall of JVM languages
#68Earlier quoted context omitted.
The obsession with this is that people would like to be able to use their favourite JVM language to write CLI tools, consumer-GUI tools or AWS lambda programs. Sure, you can just say that the JVM is the wrong tool, but that is a somewhat unsatisfying answer because it still doesn't let me write those things in clojure/scala or whatever JVM language.
They can, it is their problem if they keep ignoring the existing AOT compilers, and there are quite a few.
Are there any without an expensive license?
Re: Rise and fall of JVM languages
#69I'm surprised to see that Groovy slightly beats Kotlin in on that graph. I really underestimated Groovy popularity, or overestimated Kotlin. I've yet to work with Kotlin but did like Groovy some years ago. Never used it professionaly though, only for play-projects.
It always blows my mind when everyone seems to forget Groovy. Especially since Kotlin is very very similar (well, syntactically anyway). The difference of course is that Groovy has full Spring support, Gradle, Spock etc.
Re: Rise and fall of JVM languages
#70Earlier quoted context omitted.
Lots. See https://en.wikipedia.org/wiki/Java_applet and https://en.wikipedia.org/wiki/Java_Web_Start for links.
You forgot Jini, https://en.wikipedia.org/wiki/Jini Also Oberon was another system that also allowed for something like Java applets, called Juice. http://www.modulaware.com/mdlt69.htm
Ugh, yes, so I did, though that was less about software deployment.