...and now that NPE has a "helpful" message, I've generally found it to be almost a non-issue these days. During development, I can usually figure out the problem immediately just from the message and I don't need to examine the stack trace.
I think the best thing we have is the new `record` feature. You can declare a small public record before the method with the return type, and by using the `var` keyword, the caller doesn't need to repeat the type declaration.
I don't think there's anything that's fundamentally impossible (or even conceptually very hard) to solve, it's just that most of the times you're solving the interop problem with JNI/JNA. The opposite route is massively more complicated to implement and nobody wants to dump their time into that. IIRC, as a matter of fact, there are many amateurish level C->JVM compilers but nothing that you'd be comfortable working with on a daily basis.
If you're using GraalVM already, I think Sulong might be better -- my experience with WASM (for C) is that there's a bevy of POSIX-correct-but-ANSI-incorrect tricks that don't work properly on WASM. Debugging is also much nicer with LLVM IR (worst-case, just compile it to a binary and gdb that) than WASM (Firefox doesn't show the stack, Chrome has sourcemap bugs).
The last commit to this project was over 8 years ago. Any plans on getting this thing moving along again? Was there anything learned from this project that can aid development of similar projects?
> Any plans on getting this thing moving along again?
Yes, sometime in the upcoming decade.
> Was there anything learned from this project that can aid development of similar projects?
What is a "similar project?" Yokota Yuki's with-c-syntax¹ takes a completely different approach to parsing and runtime representation (it is similar to ScottBurson's ZetaC², which I studied closely before writing Vacietis). I want to use this to run OpenBSD or NetBSD hardware device drivers on a memory-safe Common Lisp operating system runtime. For me a "similar project" is user-space device drivers.
One word: patents. GPLv3 has wording which suggests that you need to give up rights to patents when you contribute. If you're a large company, with a large patent portfolio, this becomes an expensive endeavor. Either you give up patents (which might have value), or you do an exhaustive search to verify that no patents are being infringed.
Apache 2.0 has similar patent language as GPLv3, and is the current bigcorp favourite open source license, so I'm not sure that's correct. Or am I missing something?
This is true, however I think that the perceived "viral" nature of the GPL gives the impression that patent invalidation can easily spread around to proprietary projects as well.
It's funny that you use that example, we actually cited that in an earlier draft of this post. Despite the seemingly opposite title "Queues are Databases", that note actually makes many of the same arguments, that message brokers are missing much of the functionality of database management systems and this is a problem.
I'm not familiar enough with Go to understand why this is a challenge. What point are you trying to illustrate with the challenge? Is this easy or hard, and how does this compare to Loom and Structured Concurrency?
Many people in this thread are talking about structured concurrency in other languages. I brought up a fun one for golang that, as far as I can tell, is a 3 year old open issue [0] that I've recently bumped into.
Maybe this is a fun challenge for you to become more familiar with golang?
From what I can tell, async system calls are used whenever possible. A blocking call on a socket doesn't make a blocking system call, thus permitting the carrier OS thread to go do something else. As for file I/O, things are a bit messy. Older linux kernels don't support "true" async file I/O, and the Java NIO async file channels do use thread pools to emulate async behavior in that case.
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?
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.
Does this example fully answer the question? Does this allow the tasks to be scheduled deterministically? If I'm very careful and write the tasks such that they make blocking calls at specific locations, then yes. Otherwise, is there any feedback to inform me that tasks are switching context at places I didn't expect? Is it possible to define a custom scheduler that can simply print debug messages at every context switch?
It answers the question with a "hello, world." To do more sophisticated stuff, like what you want, you'll need to replace or wrap the standard single-thread Executor with your own Executor. There is exactly one method you need to implement. For example:
Executor ste = Executors.newSingleThreadExecutor();
Executor myExecutor = task -> {
if (task instanceof Thread.VirtualThreadTask vtt) System.out.println("Scheduling " + vtt.thread() + " on " + Thread.currentThread());
ste.execute(task);
if (task instanceof Thread.VirtualThreadTask vtt) System.out.println("Descheduled " + vtt.thread() + " from " + Thread.currentThread());
}
var myThreadFactory = Thread.builder().virtual(myExecutor).factory();
