Live data from Hacker News

Rise and fall of JVM languages

blog.frankel.ch

211–220 of 233 posts

Re: Rise and fall of JVM languages

#211

Earlier quoted context omitted.

Isn't Rust niche safe low-level (mostly GC-less) programming? I think it is, and the hoops you have to jump through to guarantee that safety are really at odds with what I would call "power".

It often feels high level (iterators and closures and all that), but yes, Rust is definitely designed to give you C++-like control over your memory. The learning curve is fairly steep, and new Rustaceans do tend to go through a phase of "fighting the borrow checker". But once you get a handle on the ownership rules, I think you very rarely find them blocking you from doing something you actually should be able to do.…

> But I'm not sure I've heard of anyone running into that limitation in practice.

Algorithms processing trees and graphs are everywhere, both in practice and in CS theory. Both are hard to implement in Rust and/or slow and/or require complex unsafe code. Here’s an example for trees, as you see all 3 approaches are far from ideal: https://github.com/SimonSapin/rust-forest

Another thing, because of that ownership thing, in Rust it’s harder to compose data structures. For example, here’s 1300 lines of code implementing hashmap + linked list combination: https://docs.rs/linked-hash-map/0.4.2/src/linked_hash_map/li... Sure, that particular collection is already in Rust’s standard library. However, quite often I need to compose standard library containers my own way. In Rust, that’s either a lot of complex unsafe code like that LinkedHashMap, or performance sacrifice (e.g. switching from pointers to index in a vector, or ref.counting).

Re: Rise and fall of JVM languages

#212

Earlier quoted context omitted.

It often feels high level (iterators and closures and all that), but yes, Rust is definitely designed to give you C++-like control over your memory. The learning curve is fairly steep, and new Rustaceans do tend to go through a phase of "fighting the borrow checker". But once you get a handle on the ownership rules, I think you very rarely find them blocking you from doing something you actually should be able to do.…

> But I'm not sure I've heard of anyone running into that limitation in practice. Algorithms processing trees and graphs are everywhere, both in practice and in CS theory. Both are hard to implement in Rust and/or slow and/or require complex unsafe code. Here’s an example for trees, as you see all 3 approaches are far from ideal: https://github.com/SimonSapin/rust-forest Another thing, because of that ownership thing…

I'd heard about the graph issue, but I don't know much about it. Is the main takeaway that GC makes managing trees/graphs a lot easier? If we were talking about C++ instead of Rust, what extra options would there be?

Re: Rise and fall of JVM languages

#213

Earlier quoted context omitted.

> But I'm not sure I've heard of anyone running into that limitation in practice. Algorithms processing trees and graphs are everywhere, both in practice and in CS theory. Both are hard to implement in Rust and/or slow and/or require complex unsafe code. Here’s an example for trees, as you see all 3 approaches are far from ideal: https://github.com/SimonSapin/rust-forest Another thing, because of that ownership thing…

I'd heard about the graph issue, but I don't know much about it. Is the main takeaway that GC makes managing trees/graphs a lot easier? If we were talking about C++ instead of Rust, what extra options would there be?

> Is the main takeaway that GC makes managing trees/graphs a lot easier?

It does indeed.

But raw pointers in C or C++ also make it easier than Rust.

Sure, it’s very easy to screw things up leaking and/or corrupting memory. But it still quite possible to implement correctly, I did that more than once.

Technically, you can usually do the same in Rust with unsafe pointers. Like the developers did to implement that LinkedHashMap for the Rust’s standard library. However, C++ is just better for writing unsafe code like this. After all, it evolved for decades being an unsafe language. Over that time, huge amount of stuff were implemented in the language (STL, esp. the checked version), runtime (debug heap), standalone tools (vtune, valgrind), and even OS (windbg) to help people implement e.g. graphs without leaking memory or exposing dangling pointers.

Re: Rise and fall of JVM languages

#214
post #78

Earlier quoted context omitted.

Kotlin is 6 years old, so about half the age of Scala - and, despite the heavy marketing, less than half the popularity on the chart in the article. We'll see what happens; Scala's growth has been slow and organic, but the flipside of that is that its success is down to the merits of its design. (There's plenty I don't like about Scala qua Scala, but I don't see it ever being displaced by a language that lacks HKT. K…

It's 6 years old if you count from the time it started development. But nobody was seriously using it at scale until it stabilised, which was the start of last year. Judged from its 1.0 "ok you can use this now" release, it's a little under 2 years old.

Sure, but if you're measuring that way then Scala is a lot less than 13 years old.

Re: Rise and fall of JVM languages

#215
post #200
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…

Along with implicits, the lack of a central Scala repository was the biggest turn-off for me.

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

Re: Rise and fall of JVM languages

#216
post #194
post #130

Earlier quoted context omitted.

Thanks for the info. Might check out Play. Yes, Java performance is fast. I had read that Sun had put millions of dollars into making it fast [1], hiring very qualified people to work on the compiler, the JIT engine, etc., over a period of many years. And the speed difference between early and later Java versions was perceptible. [1] Apart from the millions they also put into marketing Java to enterprises. And that w…

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 source:

>In February 2012, JetBrains open sourced the project under the Apache 2 license

from:

https://en.wikipedia.org/wiki/Kotlin_(programming_language)

Re: Rise and fall of JVM languages

#217
post #194
post #130

Earlier quoted context omitted.

Thanks for the info. Might check out Play. Yes, Java performance is fast. I had read that Sun had put millions of dollars into making it fast [1], hiring very qualified people to work on the compiler, the JIT engine, etc., over a period of many years. And the speed difference between early and later Java versions was perceptible. [1] Apart from the millions they also put into marketing Java to enterprises. And that w…

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

Just checked and saw this:

https://github.com/JetBrains/kotlin-native

So Kotlin Native may be another good reason, once it is stable.

Re: Rise and fall of JVM languages

#218

TFA mentions Groovy but not JavaScript which could be considered Java's direct dynamic/scripting variant given JavaScript's origin. In fact, there are two mainstream implementations of it even (rhino, nashorn), though not upgraded to ES2015.

I hope this is trolling :D

Re: Rise and fall of JVM languages

#219
post #215
post #200

Earlier quoted context omitted.

Along with implicits, the lack of a central Scala repository was the biggest turn-off for me.

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?

Re: Rise and fall of JVM languages

#220
post #161

Earlier quoted context omitted.

I have heard that before. I like(d) Perl. Got me tempted to try Scala.

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.
Post reply on HN