271–280 of 356 posts
i understand that virtual threads are very similar to goroutines in golang
Earlier quoted context omitted.
Boring answer... but Chat GPT? I asked it what was new in Java 8 and it enumerated a number of features. I could proceed to ask it about more details for each, and then continue Java version by version and I think it would be quite exhaustive. The other day I did something similar for cell biology. As a layman I wanted to learn more about DNA, mRNA, tRNA, translation, transcription, mitosis, miosis, etc. I think I le…
When I’ve asked chatgpt to explain something to me that I’m very knowledgeable about, distributed systems, it was flat out wrong about many fundamentals in a way that would have seemed completely plausible to a novice. It was making up algorithms, complete with fake but believable names, to solve problems that are provably unsolvable. My wife, a physician, reported similar errors when I got her to ask it medical ques…
> The Byzantine Generals Problem is a more difficult problem than the Two Generals Problem because it requires a consensus algorithm that can tolerate the presence of faulty actors. There are many solutions to the Byzantine Generals Problem, including Byzantine Fault Tolerance, which is a common technique used in distributed systems to ensure that the system can continue to operate correctly even in the presence of faulty actors.
One can't jump over a chasm, you have to literately bridge from the known to the unknown.
https://privatebin.net/?45ed3f39de71f289#eyiwC81q93MtfpimZBH...
Really excited to see how virtual threads are taken up by developers, and if they affect the larger programming language community. They just really seem like "the best of both worlds" to me: the high scalability/low resource usage of async/await, with the ease-of-use experience of threads (e.g. not having to worry about "function coloring").
As an engineer that last used Java when it was Java 11, I cringe at the thought of diving back in. A trade-off of increased release velocity for any language I suppose.
I use Clojure, which benefits from these consistent JVM improvements; things like pattern matching have been accessible to me for years already, but I like that Java slowly trails along as it helps keep me vested in the Java ecosystem.
This is exciting, can't wait for the LTS release next year... that said, I don't much care for the "case SomeType t when ..." pattern matching syntax, I don't see the benefit of introducing a new keyword over using "if"... or even just "&&". To pinch the example used in[1]: case Tuner t && guitar.isInTune() -> ...; and case Tuner t if guitar.isInTune() -> ...; both seem as clear as case Tuner t when guitar.isInTune()…
I work on Dart which is also adding pattern matching [1]. When we designed the syntax for guards, we also considered exactly these three choices before ultimately landing on "when" too. Our main reasoning was: "&&" is intuitive but it means that you can have a pattern that is immediately followed by an infix operator. That can be problematic if you ever want to make "&&" a valid pattern infix operator. And, in our ca…
Earlier quoted context omitted.
> low resource usage of async/await Will calling a coroutine do zero heap allocations like async in Rust? > with the ease-of-use experience of threads That's highly subjective. Threads usually require locking which is often hard to get performant and correct at the same time. Async/await allows to write concurrent code with no synchronization.
> Async/await allows to write concurrent code with no synchronization Well you still need some sort of synchronization, because an "await" allows arbitrary other actions to occur. If an await is introduced in code you transitively call then you might find that some invariant you were expecting to hold has now changed across a call when it previously didn't. Fundamentally, locks are about making invariants atomic and…
Earlier quoted context omitted.
> low resource usage of async/await Will calling a coroutine do zero heap allocations like async in Rust? > with the ease-of-use experience of threads That's highly subjective. Threads usually require locking which is often hard to get performant and correct at the same time. Async/await allows to write concurrent code with no synchronization.
> Async/await allows to write concurrent code with no synchronization. Hmm,I don't see how async/awaits makes a difference. Care to explain? Like, if you have multiple sources that can add or read from a queue, unless there is a single thread running all your async loops (ala python), you still need some synchronization. At least that's my experience using coroutines heavily in kotlin.
Earlier quoted context omitted.
If applets and web start are dead, and Wayland doesn’t render remotely, how would this work? Would a Java app server have to ask the user to run something on the desktop?
There are java desktop applications, e.g. IntelliJ, SQLDeveloper, etc.
When a backend needs an internal UI here, it's always a Javascript app in a browser.
Earlier quoted context omitted.
That was my initial pitch too. But after months, almost no one seemed to have warmed up to it. When we changed it to "when", just about everyone seemed to like it better. Syntax design is weird. Sometimes the only way to tell if I did it right is when no one says anything. People complained when I used "if". No one did after I switched it to "when".
It’s always bugged me when syntax selection is done by popular vote. The most frequent vocal complaints tend to be from people who just have to adjust to something new. But if you only ever show a user what they’ve already seen, you inhibit the ability to innovate / try new things. The flip side is that it also bugs me when language / library designers make weird choices that don’t seem to have a compelling reason (o…
Familiarity and intuitive structure in a low context language is very important. A language syntax is for humans to comprehend. If a new syntax is under discussion, it's probably around new functionality (or sugar). Where is "encourages innovation" in the list of reasons to use any specific syntax? I would say, far down on the list.
As a Clojure programmer, I don't care about any of the Java language features or improvements, but I'm super happy that I'm getting a state of the art JVM that is continuously developed, maintained, extended and optimized, over a time scale of decades. This is incredibly useful: having a good VM to run your code in, with good modern garbage collectors, is not an obvious thing (as many other languages have learned). T…
As another Clojure programmer, I say you should care about developments in Java. After all, the Java module system is precisely why classes became minefields with clojure.core/bean -- illegal reflective accesses and what not. As someone else noted in this comment section, a lot of useful Clojure libraries are wrappers over Java libraries. So improvements to Java used in these libraries are good for you, too.
I'm sure it works for OpenJDK though.