You're getting downvoted because of your snarky opening statement.

But I do think it's important/relevant to compare virtual threads to Kotlin coroutines.

I agree with your point that tacking all of this onto the existing (flawed) Thread API is a risky move. I understand the reasoning on both sides, but I'm not usually a huge "backwards compatible at all costs" or "don't make people learn new things" proponent on anything. So that's my bias.

I think you're painting the `suspend` keyword a bit rosy, though. The fact that Kotlin has colored functions is a huge pain in the ass. You have to design different APIs sometimes to account for a "suspend version" and a "non-suspend version".

The idea with Loom (like goroutines, which is the first green thread model I've used) is that async stuff is so cheap that you can almost pretend it doesn't even matter if something calls a coroutine. I'm not sure if that's the best solution, though. One advantage that colored functions do have is that you see it and "know" that the thing involves expensive and/or blocking work. With coroutines, how do you know if calling a function will slow your current thread down as it waits for the results? That's a question we could ask Go devs today, I suppose.

I agree with your prediction that Kotlin's coroutines might just sit on top of virtual threads on the JVM in the future.

> I agree with your point that tacking all of this onto the existing (flawed) Thread API is a risky move.

This is not what Loom does, though. Virtual threads are not using the thread API. They are (Java) threads; no more and no less than today's threads. Just as people don't normally use the java.lang.Thread API directly to use today's threads, there's no reason why they should use it with virtual threads.

> One advantage that colored functions do have is that you see it and "know" that the thing involves expensive and/or blocking work.

It gives you the illusion of knowing something that you don't really. The OS, or the Java runtime, can and do pause your thread at any point for durations that are between orders of magnitude shorter and orders of magnitude longer than some blocking operations. There is no useful semantic knowledge you can extract from knowing something is "blocking" to the point that it's a meaningless designation. It does mean something in "single-threaded" languages like JavaScript, or when programming hard realtime software, but not in ordinary Java. You're wasting a syntactic "colour" on zero bits of information.

> This is not what Loom does, though. Virtual threads are not using the thread API. They are (Java) threads; no more and no less than today's threads. Just as people don't normally use the java.lang.Thread API directly to use today's threads, there's no reason why they should use it with virtual threads.

Right. That's fair. They are threads, but it's just that now you have two "kinds" of Thread, where before you had one (AFIAK). I like the analogy to "virtual memory" of an OS, but can applications ask for "real RAM" instead of "virtual RAM"? I don't think so, but I could be wrong. So having virtual threads and "raw" threads under the same class has pros and cons, IMO.

> It gives you the illusion of knowing something that you don't really. The OS, or the Java runtime, can and do pause your thread at any point for durations that are between orders of magnitude shorter and orders of magnitude longer than blocking operations. There is no useful semantic knowledge you can extract from knowing something is "blocking" to the point that it's a meaningless designation. It does mean something in "single threaded" languages like JavaScript, but not in Java.

That's true. But it's still a signal from the author of the function, the same way a type is. If a function makes a network call, you can be fairly sure that it will usually take longer to return than a function that is just flipping some bits around (even a fairly large amount of bits). Or do you still disagree? Would you say that if I'm writing JVM code, I really shouldn't worry about what functions make network and DB calls or what thread they're on because it really doesn't matter? Even if I have a UI that I'd like to keep responsive?

> So having virtual threads and "raw" threads under the same class has pros and cons, IMO.

That's one way to think about it. Another is that Java never gives you "OS threads" it always gives you Java threads, an abstraction with multiple possible implementations. One implementation is no more real or raw than the other (in fact, you could even theoretically make virtual threads the carriers for other virtual threads -- a thread is a thread, after all -- but we explicitly blocked that because it's not useful). There is no real difference between that and ArrayList and LinkedList both implementing the same List interface. They're both just as real, but they have different footprint and performance (the class hierarchy for threads is slightly different, but for uninteresting technical reasons).

> Or do you still disagree?

I still disagree. That network call might take 1ms, and that bit fiddling might trigger a GC collection that takes 10 times that or more. Moreover, neither Kotlin nor C# mark long subroutines with a different colour, and they don't even mark blocking calls with a different colour, just the flavour of them that's to be used with coroutines. The real reason that colour is necessary is because of the way the feature is implemented.

Originally, that colour meant to signify something else: nondeterminism in mostly-deterministic languages like Haskell, and it is also important in JavaScript. Trying to retroactively find a useful meaning for it in Java is an excuse.

Fair point about the abstraction level of a Java thread vs an OS thread.

In light of both things you just wrote, let me ask you this: why does Java give us any choice on thread implementation? Why not have everything be a green thread from now on?

If Java threads are not OS threads, can be paused for any amount of time, and there's no reason that network calls or db calls or file IO should be treated any differently, then I'm not sure why the old Java Threads shouldn't be deprecated.

Can you shine some light on that? After Loom drops, when would I ever want something other than a green thread?

The first part of the answer is the same as that for a similar question we've been asked about LinkedList: we don't deprecate things that are heavily used, however useless or superseded by something else, unless they are very harmful. Deprecation in Java does not mean "unrecommended" but "absolutely do not use this if you want your program to continue working on future versions." Not only is it a compile-time warning, but JDK tooling even checks for uses of deprecated APIs in binaries and warns about them. Ideally, deprecated usages should break people's builds. In other words, deprecation is a big deal and not taken lightly. We might need another standardised term for "unrecommended" or "superseded".

The second part of the answer is that there are still good uses cases for heavyweight threads, that are backed by one OS thread. For example, as carriers for virtual threads or parallel streams, i.e. as approximations of CPU cores, and also for cases where FFI is used for IO or some other native interaction. This is very rare in Java, but very rare could mean "used only in tens of thousands of programs rather than tens of millions".

> The second part of the answer is that there are still good uses cases for heavyweight threads, that are backed by one OS thread.

Hold the phone. Didn't you just say a few comments up that I shouldn't think of a "Java thread" like an "OS thread"?

If I use a Thread, today, how do I know if it's corresponding to an OS thread? I understand that it will, theoretically, depend on the platform on which the JVM is running. But on a non-exotic platform (x86/ARM Windows, Linux, macOs, Android, etc), does one Java Thread map to one OS Thread or not?

I meant that a Java thread, like the List interface, is an abstraction with multiple implementations for you to choose from.

In OpenJDK (i.e. the Oracle implementation of Java) today, a Java thread is implemented as a wrapper of an OS thread; I believe OpenJ9, the IBM implementation, does the same. But the Java specification does not require it. Loom might change the specification to require it, or leave the implementation of "platform threads" (i.e. non-virtual threads) up to the specific Java implementation.

Are virtual threads preemptable? If not, then one use for OS threads is when running a bunch of compute intensive tasks and you don't want worry about stalling everything else. I suppose in that case you could just use a separate executor for those expensive tasks. I wonder how many devs will spawn tasks using the default executor and then wonder why things aren't working out so well? Will there be tooling to help identify such issues?

> Are virtual threads preemptable?

Yes, but the preemption operation is not currently publicly exposed. We're considering whether and how to expose it.

> I wonder how many devs will spawn tasks using the default executor and then wonder why things aren't working out so well? Will there be tooling to help identify such issues?

What those issues would actually be, in practice, is still unclear, hence our reluctance to expose forced preemption. People rely on OS time-sharing (what you call preemption) inside applications far less than they think. No scheduling algorithm can make a program that requires more processing resources than available to run well.

They are threads in the same way that Java's original green threads were threads and in exactly the same way that co-routines are user scheduled thread like objects. They are not proper OS threads scheduled by the OS. Kotlin's co-routine implementation does something very similar and will just use a Loom thread when that becomes available.

It will also use executors with multiple threads if you use the right dispatcher.

I'm not sure I get your point about colored functions. Under the hood the compiler generates what is basically a callback structure not unlike what you get in javascript (i.e. a promise). It gains features like callback hierarchies, cancellation, etc. Loom fixes this by forcing you to wrap things with a Thread. Same kind of mental overhead.

> I'm not sure I get your point about colored functions. Under the hood the compiler generates what is basically a callback structure not unlike what you get in javascript (i.e. a promise). It gains features like callback hierarchies, cancellation, etc. Loom fixes this by forcing you to wrap things with a Thread. Same kind of mental overhead.

The difference is that I'm not allowed to pull apart the callback structure that colored functions (in Kotlin) cause the compiler to make. Instead, I just have a colored function I have to work with. And it's incompatible (in one direction) with functions of the wrong color.

Colored functions don't compose well. The green thread approach allows you to call anything from anywhere and compose whatever you want. When you choose to make it asynchronous, then you wrap it in a green thread and fire it off. That's pretty different than having two juggle different colored functions AND still needing to fire them off via whatever coroutine laucher.

It's like saying the article goes out of its way not to mention Scala/Haskell's IO type. Syntactic coroutines, monadic IO, and threads are different constructs, although they are different ways to address a similar problem -- expressing sequential (and, in contrast, parallel) composition. Virtual threads are Java threads; there's nothing "bolted". Syntactic coroutines are a kind of syntactic code-unit similar to subroutines.

Which one you prefer as a coding style is a matter of taste, but threads have some objective advantages over syntactic coroutines that go beyond syntax. For one, they don't require a split API (C# and Kotlin have two copies of their synchronization and IO APIs that do the same thing but are intended for different kinds of units, subroutines or coroutines); for another, they seamlessly integrate with the platform and its tooling, allowing use of exceptions, debuggers and profilers with little or no change to those tools. The Java platform -- the standard library, the VM, and its built-in profiling and debugging mechanisms -- has been designed around threads.

BTW, Java's strategy for targeting platforms like iOS and, later, the browser, is through AOT compilation of Java bytecode using things like Native Image (e.g. https://gluonhq.com/java-on-ios-for-real/). This allows you to employ the standard library as well. Kotlin's approach is different, and requires different libraries when targeting different platforms.

> Scala/Haskell's IO type

Since you've brought out Haskell's IO and Scala libraries' IOs (Monix, ZIO, Cats Effect), or F#'s Async, I think it's worthwhile to point out how they're different from the async-await approach that's in C#/Kotlin/Rust/etc.

They both require "special" handling -- in C# it's the `async`/`await` syntax, in Scala it's the flatMap function or for-comprehension -- there they are similar. But their meaning is different. IO/Task in Scala doesn't represent a possibly started and under-way computation; it represents a "dead" program, yet to be started, a mere value. And it has all the advantages that mere values have, like refactoring (extract variable, ...) or restarting in case or failure and so on. Pass it into a method, return it from a method, store it in a data structure/collection, create `IO[IO[X]]`, whatever you want, just like you would with `Option[X]` or `List[X]`. In Scala, you have to differentiate between `A => B` and `A => IO[B]`, because `B` and `IO[B]` are different, but both are still values. Your program then ends up being this one big IO/Task value, which is then executed "at the end of the world". These pictures illustrate it quite well:

https://twitter.com/impurepics/status/1182946618280153094

https://twitter.com/impurepics/status/1180064851219144704

On the other hand, async-await has none of the benefits, only downsides. You get functions of two colors, but no benefit in return. It's justifiable in Rust, because Rust aims for zero-cost abstractions. But for Kotlin/C#, it's a sad choice.

The Loom approach for Java is a reasonable one. No async-await shenanigans, no funny FP/Haskell/IO business. You just use threads for concurrency as God intended them and you can have gazillions of them, because they are M:N. And I respect that, even though I'm partial to IO/Task for the reasons outlined above.

> Loom approach for Java is a reasonable one. No async-await shenanigans, no funny FP/Haskell/IO business.

There's another important piece of the puzzle (putting aside any debate over the value of values): software is much more than syntax. When I think of some software construct, I don't just think how I can express and manipulate it in code, but also how I can express it and manipulate it while it is running and after it's run, i.e. present it in a profiler or assist troubleshooting when something goes wrong. In other words, how to make it a traceable, contextual entity.

The "process" construct on the Java platform -- regardless of the frontend language used to write the program -- is not that of an IO type, nor is it a syntactic coroutine; it is the thread. The JVM constructs stack traces for threads; it emits profiling, monitoring and debugging events for threads; its semantics of single-stepping follow threads; its GC heuristics are or can be designed around threads and even the JIT compilers perform optimisations that are implicitly based on threads [1]. In other words, the syntactic construct is just a part of of the problem, and the goal was not just to find a good fit for the language, but also all of the other important aspects of software. Adopting any other alternative would have required introducing that new concept into all layers of the platform as well. We're building a platform, not just a language.

Just to give you an example of a design issue we're struggling with now because even the mere number and duration of threads changes some of their runtime aspects: how do we perform thread dumps in a way that would tell the user what they want to know, i.e. what the different parts of their application are currently doing? Merely dumping a million stack traces probably wouldn't do the job, even if we grouped and deduped them. If we were to introduce a new kind of process, such "program dumps" would be the least of our worries; just the coordination with debugger/profilers/APM vendors would be a multi-year project.

> https://twitter.com/impurepics/status/1180064851219144704

OT, but, as someone who's interested in analytic philosophy and formal languages, such incorrect usages of "referential transparency" are a pet-peeve of mine. Java is more referentially transparent than Scala (at least Scala 2.x) because it doesn't have macros. It does not mean "an expression can be replaced by its value without changing [the value of the value of an enclosing expression]" but "an expression (term) can be replaced by its reference (aka denotation) without changing the reference of its enclosing expression;" hence referential transparency -- a syntactic term is a transparent representation of its reference, something that isn't true once you have macros. It's just that if your language is a pure-functional one, i.e. one with value semantics, i.e. one whose term references are values in the object domain of the language, then a reference is a value. That incorrect usage of referential transparency is nothing but a synonym for being pure functional (or of "value semantics") rather than a feature of it.

> It's justifiable in Rust, because Rust aims for zero-cost abstractions.

It's not that async/await is inherently more "zero-cost" than user-mode threads; they're just like that in Rust given its peculiarities. A different syntactic construct allows them to restrict recursion and virtual dispatch that would make stack size non-deterministic and interfere with their chosen memory-management strategy.

[1]: The compiler inlines calls (which are on the same thread); it doesn't inline multiple monadic stages (which often entail some megamorphic callsite).

It's more than that. Java developers are switching to Kotlin; notably on Android and Spring code bases (well over 50% of backend Java projects at this point apparently).

This is an article about structured concurrency and how Loom implements something that Kotlin has shipped that both Android and Spring heavily integrate with already.

So, there's more than a casual relation between Kotlin co-routines and Loom. I'd go as far that they apparently took a really good look at it and somehow ended up with something that essentially implements almost 1 to 1 the same kind of things.

Roman Elizarov (tech lead for co-routines, and recently the whole language) has been talking about structured concurrency a lot. I don't think he invented the notion but it definitely is what co-routines is designed to do.

So, when I see an article talking about how great Loom and structured concurrency is mentioning several languages but yet somehow glossing over Kotlin, I call it out as lame. Oracle no doubt has good reasons to not want to talk about Kotlin. But to me it is clear they consider it a threat. It's not the first time that they celebrate a few features new to Java where they mention other languages as influence and yet not mention Kotlin. Recent introduction of Records is a good example.

The Threading APIs date back to the late nineties and are full of complex stuff that you need to be aware of if you go near them if you care about avoiding all sorts of interesting categories of bugs, issues, and pitfalls. So much that I'd treat the occurrence of import java.lang.Thread as a giant red flag in a code review. Typically, it's a rookie mistake to use that. You shouldn't have to; there are better APIs.

Kotlin, btw. treats threads just as a special case of co-routines. You can have co-routine dispatchers that represent a particular executor. This is how you separate slow blocking IO things from e.g. CPU heavy stuff, or UI event handling. So, there is no API split in Kotlin. Some co-routines use a threadpool, some don't.

> notably on Android and Spring code bases

Of course they are, on Android, Google is doing everything that they can to push Kotlin down developer throats, most Java developers end up moving to Kotlin when the option is an half baked implementation of Java, called Android Java, stuck in Java 8, when we are already on Java 15, and Google is unwilling to move Java support any further than what they are forced to due to InteliJ own changes.

Spring, well they only care about marketing and getting Spring sales, I still remember when Groovy was supposed to take over the Java world and also had first class support in Spring, just like they are selling Kotlin nowadays.

I got some nice consulting gigs porting those projects back to Java, and the same will happen with Kotlin projects when Google gets fed up with Android and moves on to Fuchsia/Flutter.

> So, there's more than a casual relation between Kotlin co-routines and Loom.

Not beyond the fact it was one of the things we looked at and decided to go in a completely different direction. We looked at Python, Go, JavaScript, C#, Kotlin, C++, Rust, Zig, Haskell, Pony, Scheme, Erlang, Céu, Scala and Clojure, and decided not to go down the C#/Kotlin path, which is why we ended up with a solution that is nothing alike. The positive influences were Erlang, Go, and Scheme (with a glance to Céu). That's why virtual threads share a lot of similarities with Erlang processes and Go goroutines, and borrow ideas from Scheme's (and OCaml's) multi-prompt delimited continuations, but are not at all like C#/Kotlin's syntactic coroutines.

There are certainly things about Kotlin we love, like nullability types, and that we'd like to see in the Java language some day. When we do, Kotlin would have been the influence. Syntactic coroutines, on the other hand, were something to avoid.

> Java developers are switching to Kotlin

Just as they had to Scala in the past, many developers are switching to Kotlin, which has reached ~2-4% on the Java Platform, and might even reach 5-7% some day. That is huge, perhaps unprecedented, market penetration for a Java Platform language, but let's not get carried away.

There are certainly languages we consider serious competitors, but Kotlin is still an order of magnitude in size away from being one of them. Java is so big that you can still be 20-50x smaller and still be a very popular language, yet not quite a competitor.

> Recent introduction of Records is a good example.

Nope. First of all, Kotlin doesn't have records. Kotlin-like data classes were something we looked at (we look at all languages) and said, we don't want that, we want records. Second, the inspiration for records was ML. So records are actually yet another example where we decided not to go in the same direction as Kotlin. This isn't to say Kotlin did something worse or better, but it did do something decidedly different.

> Typically, it's a rookie mistake to use that. You shouldn't have to; there are better APIs.

The same APIs Java users use today (Executors) are the ones they'll use when Loom lands. There is still no need to use the Thread API directly.

> Kotlin, btw. treats threads just as a special case of co-routines.

Perhaps in your desire to see Kotlin influences everywhere (and, BTW, syntactic stackless coroutines were done in C# first, at least among the well-known language) you misunderstand what Loom is. Virtual threads are threads, period.

Anyway, it's perfectly fine to prefer Kotlin over Java (the language) just as it is to have the opposite preference. But I think you misjudge the influence those languages have and draw from.

> Syntactic coroutines, on the other hand, were something to avoid.

Could you articulate or point me to some of the arguments or thoughts that lead to the conclusion here? I know and understand the term "colored functions", but I'd love to read a real analysis of the pros and cons of colored functions, because I personally go back and forth on whether I think they are bad or good. On the one hand, having a function that is explicitly marked as "this thing needs to be treated specially because it may block for a long time" is actually kind of nice. On the other hand, it's hard to write generic functions/tools when you have to handle different colored closures, for example. Also on that hand is the fact that I can still write a function as the "wrong color" if I'm inept.

Or was that decision based on something other than language semantics?

> There are certainly languages we consider serious competitors, but Kotlin is still an order of magnitude in size away from being one of them.

Just out of curiosity, what are those languages? C#? PHP?

Also, this statement makes you sound like Goliath. I don't disagree with you that Kotlin, in particular, is probably not a huge "threat" to Java. But you're slinging numbers like a politician or a PR person: "Kotlin, which has reached ~2-4% on the Java Platform, and might even reach 5-7% some day". Java has 25 years of legacy- are you seriously saying that picking up 5% of JVM code in < 10 years from the HOST LANGUAGE OF THE PLATFORM is not a little unnerving? Also, do you only care about the JVM? What if everyone switch from Java to C#? Would you still brag that "90% of code on the JVM is Java" even if 0 new projects started choosing Java? I mean, those are unlikely events, but I'm just saying "there's lies, damn lies, and statistics".

The truth is that until pretty recently, Java was really lagging behind and many devs were cursing their fate that they were still working on Java projects. Java 8 was a huge leap forward, and Java 15 is another sizeable leap. So I suspect that Java will stop the bleeding. But it was not at all guaranteed to stay a behemoth, IMO.

> Nope. First of all, Kotlin doesn't have records. Kotlin-like data classes were something we looked at (we look at all languages) and said, we don't want that, we want records. Second, the inspiration for records was ML. So records are actually yet another example where we decided not to go in the same direction as Kotlin. This isn't to say Kotlin did something worse or better, but it did do something decidedly different.

I haven't used them yet, but I think that records look better than Kotlin's data classes. But the only difference I see is that they don't auto-generate a `copy()` method, like Kotlin's data classes do. I believe that was a big mistake on Kotlin's part. Is there some other way that Java records are different than data classes? Because if that's the only difference, it sounds really disingenuous to suggest that records are not inspired by data classes. Like, what are the odds that it took until 201x for you (all) to decide to copy records from ML? You certainly didn't do it before Kotlin for some reason.

> Could you articulate or point me to some of the arguments or thoughts that lead to the conclusion here?

I gave a talk about exactly that recently at Code Mesh. I expect them to post the video soon. https://codesync.global/speaker/ron-pressler/#745why-user-mo...

> Also, this statement makes you sound like Goliath.

Maybe, but it's not just a matter of size but also trajectory. And, as you say, our competition is mostly off the Java platform. My point wasn't to brag, but to put matters in perspective. There are dozens of nascent languages, the vast majority of which will never make it to the top ten, let alone the top five. And while a few of them will, no doubt, one day unseat the incumbents, we obviously don't think of all of them as "threats."

> what are those languages?

The obvious ones. It's not that we don't know that some smaller languages will one day become big, some will even surprise us all, but extrapolating early growth to long-term success is certainly not a good model.

> Like, what are the odds that it took until 201x for you (all) to decide to copy records from ML? You certainly didn't do it before Kotlin for some reason.

As I wrote in another comment, Kotlin's arrival and Java's "boost" are both a response to the same event: Java's decline in Sun's dying days. Once Oracle increased investment, it was mostly a matter of prioritising which features to do first. Records were seen as less urgent as lambdas, so they came later.

You didn't answer a few of the interspersed questions, so I'll press you on the records one.

What about Java records are different than Kotlin's data classes besides forgoing the auto-generated `copy()` method? I understand there are some implementation details, such as inheriting from a Record base class, and how it handles serialization. But I mean as a user.

Can records implement interfaces? Can records be variants in a sealed class hierarchy? Can records have a private primary constructor? Can I customize the getters (to e.g., make defensive copies)?

For other people reading, the answers for Kotlin data classes are: Yes, Yes, Not Really, No.

As an aside, I understand you are an Oracle employee. When you post under this username are you acting in any kind of official capacity for Oracle? Like, is part of your job, so to speak, to have a social media presence? I'm not suggesting anything negative- it's totally fair to invest in outreach, to answer questions, clarify things, etc. I was just curious if I'm talking to "a guy who loves the project he works on" or "a representative of a company".

> What about Java records are different than Kotlin's data classes

Java records, like enums (another feature that is philosophically very similar to records) aim not to reduce the boilerplate of certain operations, but to designate a subset of classes with particular semantic properties (and make those easy to express). In the case of enums, that subset is classes with a well-known, fixed set of instances; for records that is nominal tuples, i.e. immutable, unencapsulated data aggregates, similar to ML's product types. So users, the compilers, and libraries can make certain assumptions about records. For example, their semantic properties (that they are no more than a product of their component types) allow a much better serialization story for them and, indeed, record classes are serialized differently from non-record classes: Instead of invoking a no-arg constructor, their canonical constructor is invoked on deserialization. Their immutability also makes automatic implementations of equality, deconstruction and pattern matching clear and correct.

Just like Kotlin couldn't do user-mode threads efficiently because they have no control over the platform, there was also little point in doing records, because that language's goal was to make it easier, syntactically, to work with the existing Java ecosystem, and, prior to records, Java programmers worked with JavaBean-like classes, so Kotlin tried to make those operations more syntactically pleasant. Java's designers, however, can have an impact on what that ecosystem does and can change its direction.

> As an aside, I understand you are an Oracle employee.

Yes. I work on OpenJDK.

> When you post under this username are you acting in any kind of official capacity for Oracle?

Absolutely not. I speak only for myself. I'm the technical lead for Project Loom, and I want to see what kind of reactions people have to it on social media (as well as conferences, customer meetings, surveys etc.). I guess I see it indirectly as part of my job, at least as far as Loom goes, as these interactions help inform how we explain the capabilities, what features people want etc.. It's nothing official, though. It's also a harmful personal addiction.

> "a guy who loves the project he works on"

Yes, he is Ron Pressler, project lead of Loom - https://twitter.com/pressron

> Can records implement interfaces?

Yes.

> Can records be variants in a sealed class hierarchy?

Yes.

> Can records have a private primary constructor?

The accessibility of the constructor is roughly at least that of the record class itself. If the record class is public, then the canonical constructor must be public. However, thanks to the positive answers to the two previous questions, you can have a readable-though-not-publicly-constructible record -- make it a private implementation of a sealed public interface.

> Can I customize the getters (to e.g., make defensive copies)?

Yes. Although in most cases, defensive copying in the constructor is sufficient.

As I see it, the main difference is that existing code will magically work with Loom and will require rewrite with coroutines. I can get Oracle 9i JDBC driver from 1999 and use it under Loom and it probably will work just fine. Probably Oracle will not rewrite its JDBC drivers with Kotlin coroutines any time soon.

Well, Spring's r2dbc (reactive db abstraction) works great with co-routines on top of Spring's reactor framework. The integration for that is well supported by Spring. Drivers that support asynchronous IO, at this point include most obvious mainstream databases. I'd expect that stuff will work with Loom as well. Though we may have to wait a while for Spring to release support for that.

Oracle has not gotten around to supporting Oracle DB with r2dbc just yet apparently: https://stackoverflow.com/questions/58813658/r2dbc-oracle-da... but it appears to be in the works. Given that they are developing Loom, they probably aim to have that stuff working together perfectly with their own DB. If/when it does, it will work with kotlin co-routines as well. Basically, if it runs with Java, you can use it from Kotlin and trivially wrap it with a co-routine. I've done this recently for several other database that support async IO with some callback mechanism.

That old Java driver will also work fine with Kotlin & co-routines as well However, you probably want to be using the IO Dispatcher to ensure you have enough threads to deal with it blocking your process thread. So your server doesn't hang. That kind of is what structured concurrency is about. Of course, most blocking IO database drivers would typically use some connection pool backed by a (real) thread pool. Not sure how Loom 'magically' deals with interrupting IO blocked virtual threads but I have hunch that just means everything on the underlying OS thread ends up being blocked. Using virtual threads in a connection pool is probably going to end in tears. I'm not aware of any magic that Loom provides that addresses that other than just allowing you to use either OS threads (real?) or virtual threads (aka. fibers, co-routines, green threads, light weight threads, etc.).

There is an important difference with Kotlin coroutines. In Kotlin you still have the problem of colored functions [1], those marked with `suspend` and the regular functions. You can't call suspend functions from regular functions and the world is divided in blocking and non blocking APIs (e.g Thread.sleep() vs delay()). And then you have to use things like `runBlocking` to bridge these two worlds.

If I understand correctly, Loom breaks that wall completely. You don't need to mark functions as `suspend`, the runtime is just smart enough to do the right thing. For example, if you call Thread.sleep() on a regular OS thread, then that will block, but if you run it on a light weight thread, it will suspend instead, allowing the runtime to use the OS thread for another task.

And there is one more thing: because Loom is implemented at the VM level, that means that when using Lightweight threads you get all the good things you typically get with regular threads: Proper stacktraces and native debugging and profiling support.

[1] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

> Since the article goes out of its way to not mention Kotlin,

"Since the article goes out of its way to not mention [Rust|Kotlin]" and "I'm surprised this article has no mention of [Rust|Kotlin]" must be one of the most frequently used templates on HN.

The difference is that Kotlin has been gobbling up Java users using Java frameworks like Android and Spring. Coroutines are used in both and implement structured concurrency exactly like Loom does. It's not a little bit similarish and vaguely related: it maps 1 to 1 conceptually; well at least for the stuff that Loom actually implements.

Rust indeed would deserve a mention as well but it follows a somewhat different approach to the same problem. But Kotlin is somewhat special here as Oracle is bleeding users to specifically Kotlin.

I think that Kotlin's existence has really given Java a kick in the pants. I agree that there has been a lot of people picking up Kotlin because of how verbose and "last century" programming in Java feels. Modern (static typed, imperative, algol-like) languages are so much more ergonomic (Rust, Go, Kotlin, Swift, TypeScript, etc), that it's kind of painful to go back to Java, with its silly "everything has to be an object, except we still have unboxed primitives for some reason", etc.

On the other hand, to their credit, the Java devs (Oracle, I guess) have really stepped up their game in response. Java just (fucking finally) got "records" (better than data classes, IMO), and sealed classes. Soon they'll have virtual threads. And some day they may actually have what I think they call "value types" (bad name), which will be excellent news.

With these things, they've implemented basically all of Kotlin's "must have" features except for null safety and clean, sexy, syntax. If they ever tack on some kind of "strict null mode" to Java, that might just be the end of Kotlin. Everyone who wants a functional JVM language will go to either Scala or Clojure, and the rest can stay on Java. That is, unless of course, the Kotlin guys pull more tricks out of their sleeves. But, in all reality, the entire purpose of Kotlin seems to have been to have a middle-ground between Java and Scala while learning from the mistakes of both. If those languages also learn from their own mistakes (they are), then Kotlin is in trouble.

Kotlin was created circa 2010 as a result of Java's stagnation in Sun's dying days. Oracle has since increased investment in the platform. So Java's resurgence and Kotlin's appearance are both a response to the same event rather than one causing the other.

> ergonomic (Rust, Go, Kotlin, Swift, TypeScript, etc), that it's kind of painful to go back to Java.

I really don't know how you can include Go here. It's extremely unergonomic to manually write for loops, and to deal with pointers and references.

That's true. And honestly, I don't personally like Go. I included it out of respect. :)

But the whole static duck typing thing is really nice and much less awkward than Java-style interfaces, IMO.

Kotlin is just yet another guest language on the JVM, written in a mix of Java, C++, no Kotlin code around, neither today nor tomorrow.

Google is pushing Kotlin as hard as they can on Android, while leaving Android Java dialect stagnate on a pseudo Java 8 compatibility, they have a political agenda to play here.

Spring just goes after any shiny thingie that might bring users into their domain, Groovy, Clojure, Scala, and now Kotlin.

What makes you think that Kotlin should be mentioned? Especially since concurrency in Kotlin is really not great, compared to concurrency in Erlang or Scala.

I'm not familiar with concurrency in Erlang or Scala, could you explain how it differs from the approach in Kotlin (which I know)?

I've posted above how Scala's IO/Task is different from C#/Kotlin async-await.

https://news.ycombinator.com/item?id=25305574

I hope you will find it helpful.

Thanks! Really useful.

For starters, because the concurrency story in Kotlin is also built on the structured concurrency idea.

Well, Kotlin is not the only language. :)

The same is true for Scala and other languages. Languages that even existed before Kotlin.