...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.
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?
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.
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.
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?
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?
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?
That's cool, I hadn't thought of that. But does it identify "hot"/"cold" files that might benefit from being converted automatically to/from the compressed format? That would be a very nice feature to have.
Reading over the comments here makes me chuckle a bit because it proves the author's point: "Error handling is hard". I don't think any silver bullet solution has been invented yet.
I'd like to see error handling supported in a transactional way, which at least would roll things back to a clean state before the error happened. Of course if you performed an operation which cannot be rolled back, then so much for my great idea.
NTFS requires that files be manually converted to the compressed format. They're uncompressed in parts as requested, but this is only kept in RAM. I'm not aware of any built-in background task that converts files to/from the compressed format.
I guess it all depends on what side you're coming from. When I was in school, I studied MIPS from the perspective of a compiler writer who's only casually interested in hardware design. Having learned a couple of CISC designs beforehand, I found MIPS to be absolutely genius in comparison. I wasn't interested so much in implementing a MIPS processor, just coding for it.
I found this to be a good read, but I wish the author discussed the pros/cons of bypassing the file system and using a block device with direct I/O. I've found that with Optane drives the performance is high enough that the extra load from the file system (in terms of CPU) is significant. If the author was using a file system (which I assume is the case) which was it?
Is it just me or did anyone else think that the bottom of the dish was a solid concrete surface? I was surprised when I saw the pictures of the damaged dish and wondered how such a giant hole was created!
I've found that coding in a "C-like style" offers great performance too. Are there any languages that target the JVM and are designed for higher speed? If it enforced the "C-like style" at the language level, perhaps it would be easier to follow?
Of course at this point the usual answer is just use Rust, but is there a language that meets in the middle? Sometimes I just want the GC to do the work and I'm okay with that.
I found this to be a good read, but I wish the author discussed the pros/cons of bypassing the file system and using a block device with direct I/O. I've found that with Optane drives the performance is high enough that the extra load from the file system (in terms of CPU) is significant. If the author was using a file system (which I assume is the case) which was it?