Does Java even have custom value types ? Looks like author is attributing FP features to Rust ?
Not yet, but that's one of the big impending projects.
Java is becoming more like Rust, and I am here for it
51–60 of 71 posts
Re: Java is becoming more like Rust, and I am here for it
#52Earlier quoted context omitted.
I think async worked out pretty well with JavaScript. But that was added to an already async language, it was just verbose and awkward before the await keyword.
In what way was the language async? It has no threads outside workers, which have strict limits regarding data sharing. You would see a lot of code that registers callbacks as event handlers, but I don't think that makes the language async. That's just the nature of event handlers. They are invoked later, when the event happens. In a way, the lack of threading allowed `async` to be implemented without gotchas. In lan…
Async and multithreading are not the same thing. Async is about non-blocking execution between functions.
JavaScript is inherently async because the concept of the event loop is baked into the very language runtime itself.
In Java you can achieve a single threaded async runtime by instantiating a SingleThreadExecutor and having all your application code running as jobs posted to this executor. But because you can opt out of this model or use something like a ThreadPoolExecutor it's harder to bake in an `async` keyword into the language that is as simple as you have in JavaScript.
Re: Java is becoming more like Rust, and I am here for it
#53[deleted]
Re: Java is becoming more like Rust, and I am here for it
#54I'm surprised there aren't more people using Java nowadays. The JVM is rock solid, the speed is really good, and the latest changes are making the language much more modern. Maybe people are actually using it but not talking about it? Not sure.
Generic erasure inside the JVM is a fundamental flaw.
Why do you say that?
Re: Java is becoming more like Rust, and I am here for it
#55What "immutable" means in Rust is very different from Java or any FP language for thar matter. In Rust you can take any data structure and mutate it. There are hardly any invariants that you can force, unlike in Java. For example, strings are mutable in Rust. This, coupled with not being a language managed by GC, makes persistent data structures not practical or desirable. Of course, mutability in Rust is very contro…
> In Rust you can take any data structure and mutate it. What if a memory location not marked "mut" is allocated by the compiler in the executable TEXT segment, so the virtual memory page is itself mapped read only? Are you certain you can get away with what you said, within the promises of the compiler?
The underlying object type would still be mutable in this case, you just can't get a &mut reference to the object.
Re: Java is becoming more like Rust, and I am here for it
#56Earlier quoted context omitted.
> In Rust you can take any data structure and mutate it. What if a memory location not marked "mut" is allocated by the compiler in the executable TEXT segment, so the virtual memory page is itself mapped read only? Are you certain you can get away with what you said, within the promises of the compiler?
The underlying object type would still be mutable in this case, you just can't get a &mut reference to the object.
You get a segmentation violation if you try writing to a read-only page as in variables in a .text segment.
Are we talking about different things? I'm writing Rust too (and decades of C) and feel I'm missing what you're describing, perhaps.
Re: Java is becoming more like Rust, and I am here for it
#57Earlier quoted context omitted.
I think async worked out pretty well with JavaScript. But that was added to an already async language, it was just verbose and awkward before the await keyword.
In what way was the language async? It has no threads outside workers, which have strict limits regarding data sharing. You would see a lot of code that registers callbacks as event handlers, but I don't think that makes the language async. That's just the nature of event handlers. They are invoked later, when the event happens. In a way, the lack of threading allowed `async` to be implemented without gotchas. In lan…
Sounds like parent was using async to mean that JS has single-threaded concurrent functions by default.
Disclaimer: I'm just the messenger here so you might hate what follows, the community is choosing the words.
Concurrency as a keyword is increasingly being used to differentiate single-threaded event handling from parallel processing (threads). As long as event handling is quick enough, it can give the illusion of parallel processing. And in some cases it can outperform parallel processing because the cost of context switching between events can be lower than context switching between threads. See https://medium.com/@caophuc799/nginx-architecture-and-why-ca...
The async keyword, in practice, simplifies the callback boilerplate required to handle the event model. When used in communication, async is increasingly being used as a word to describe "Single-threaded Concurrent Functions Built On Hidden Event Handling", because there is no succinct way of saying STCFBOHEH in English.
So: JS has async/STCFBOHEH/context-switching on its functions by default whereas Java's functions are (by default) executed in order without async/STCFBOHEH/context-switching.
Re: Java is becoming more like Rust, and I am here for it
#58What "immutable" means in Rust is very different from Java or any FP language for thar matter. In Rust you can take any data structure and mutate it. There are hardly any invariants that you can force, unlike in Java. For example, strings are mutable in Rust. This, coupled with not being a language managed by GC, makes persistent data structures not practical or desirable. Of course, mutability in Rust is very contro…
Mutation in Rust is much more controlled than in SML or OCaml. Any record or variable (sic!) can contain a ref cell, or a special data type like an array, which can be mutated regardless of the type of the thing it’s contained within. That’s the ML approach to mutation.
In Rust on the other hand, even though ref cells are a thing as well, the main approach to mutation is through mutable bindings and mutable references, which preserve const-correctness (inspired by C++), i.e. there is a certain degree of transitivity in the guarantees around immutability. When I see an immutable reference in Rust and pass it to a function (or a method), then, outside of few special cases, I can reasonably expect it to stay unmodified. In ML I can’t, unless the code is written in a very unoptimal way, i.e. with persistent data structures anywhere and everywhere, and still the type system won’t give me any hints about that.
Re: Java is becoming more like Rust, and I am here for it
#59I'm a big Rust person but the language I think that's slept on is Kotlin. It has all the goodies I like in Rust (multiplatform, decorators, FP, pattern matching) but with a GC/JVM to back it. I personally like Rust since I can drop down to low-level embedded projects and stick with one language, but depending on what interest you, Kotlin can be an excellent fit.
Can’t be bothered with Kotlin as you have no choice but to use IntelliJ to work with it.
Re: Java is becoming more like Rust, and I am here for it
#60I imagine the lineage here is more Scala than Rust, right? Not that Scala invented these concepts, but if you’re looking for proven features with JVM implementations to add to Java, you’re probably going to look to Scala (and Kotlin) first.
The OpenJdk team has said multiple times that their inspirations are coming from ML and not Scala or Kotlin.
This seems hard to believe. If true, it seems very odd that they wouldn't be studying successful languages with enormous real world adoption targeting the same platform as theirs.