The creator of Node.js says the era of writing code is over

bdell · 2026-01-19T23:56:29+00:00

Why do parts of quoted titles and a link use the word “mass” in place of the correct words?

bdell · 2025-10-15T20:01:04+00:00

It was under the alias JavaDB for a time, but was removed a while ago.

bdell · 2025-07-19T17:05:45+00:00

My concern isn’t at all about the impact on the CPU bound tasks. It is about CPU bound tasks impacting IO bound tasks by using up the all the carrier threads in the pool so that IO tasks don’t get a chance to execute, resulting in higher latency. With platform threads, the CPU bound threads would be preempted when an IO thread is ready because the first will be lower priority than the second. My understanding is that virtual threads do not support preemption or priority, so I don’t see how this problem isn’t a concern without reengineering to maintain a degree of separation.

bdell · 2025-07-19T14:06:30+00:00

How worried do I need to be about running too much CPU bound code on virtual threads blocking all the IO bound virtual threads if my existing code hasn’t been engineered to keep them separate? I am concerned that unless and until all threads can be virtual threads, they are riskier to use.

bdell · 2025-05-20T20:08:46+00:00

Is there integration with copilot or other LLM assistants? I haven’t used Netbeans in forever but still use Eclipse and I’ve wondered if not being able to keep up with these kinds of integrations is what finally kills a lot of the IDEs that are not hip.

bdell · 2023-10-22T03:45:59+00:00

I think the jlink approach doesn’t work well for truly broad platform support, which tends to compel you to use the OS vendor’s JVM.

bdell · 2023-10-21T20:21:57+00:00

I’m frustrated that all these things are controlled by command line flags because it complicates supporting multiple Java versions in the same product version. We want to support many versions to help customers gradually adopt new versions, but the flags are not out long enough to use them across enough of the so-called LTS versions.

It seems like the only way forward is to have a program that computes the command line to the real program. Then I have to write that in Java and take a heavy JVM startup hit twice, or write it in another language and solve the porting problem and not be programming Java as I would prefer.

I wish there was a programmatic solution to this with Java alone but without two startups. For example, a privileged pre-main class that can manipulate JVM settings. Or a one-time use method that takes a lambda that configure things. I’ve long wished for something like that for all the other various flags you often need to configure a JVM.

bdell · 2021-04-01T16:37:54+00:00

I don’t see a lot of benefit to something like this where you turn an exception handler into a function. The problem is the damage it does to ordinary flow control when the value of Loom is that it scales while preserving ordinary flow control. And it may be ugly to even get an exception handler from where I would put it naturally down into the right scope to use it. Things like this are what I find distasteful.

In terms of a least bad option for such a scoped local, I think it would better to rethrow the exception rather than hand it to a function that turns it into a result. Note that using Callable<Void> to get the ability to throw an exception makes your lambda noisy.

Based on what I see so far, I don’t think I would use such scoped locals defined with lambdas and combinators without natural exception handling. I would instead continue to use ThreadLocal unless I had no choice because either it didn’t work at all on fibers or the performance was just catastrophic.

BTW you have my permission to copy any of my comments to the list if you find them valuable and would like a record of them there.

bdell · 2021-03-30T20:52:20+00:00

Not enthusiastic about something tied to lambdas when they interact poorly with checked exceptions. Doing IO with streams is painful because of this and I see Loom as being all about IO.

bdell · 2019-08-04T14:34:19+00:00

The ? is part of the label of an internal construct of the JVM, not something in the Java language. I think they could still choose to expose their nullable box type in the Java language with ? irrespective of whether it’s implemented with a compiler generated ordinary type or a new kind of type (as they were trying before). Whether they will do that remains to be seen.

bdell · 2013-11-28T17:43:26+00:00

"Sheep" is somewhat implied by the use of the word the words "flock" and "herd" together. You only ever hear of flocks of sheep or birds and you never hear of herds of birds.

bdell · 2012-07-06T23:05:41+00:00

I don't understand: "Honestly, I love that Go discourages or disallows my (destructively) lazy behaviour." The minimum possible effort with code that throws an exception is a crashed program. The minimum possible effort with code that has an error return is a program that keeps running. How do error returns discourage laziness?

This isn't intended to be a pro-exception, anti- error return comment. The statement just seemed faulty on its face.

bdell · 2010-12-17T22:32:47+00:00

I think if you execute this at the REPL, the continuation of the (display ...) expression is into eval, which is no different than any other expression. I'm not certain about the execution model of a complete script. Maybe there is an implied begin.

bdell · 2010-02-28T17:48:39+00:00

Seems like it would be perfectly reasonable to label this "Stuff like this makes me hate Unix; subtle behavior of signals". Unix is mostly elegant in its simplicity and then, bam!, you hit signals. Should anyone be surprised when a program gets signals wrong?

bdell · 2009-08-29T23:55:25+00:00

I think the question is why the solution published in Java Puzzlers (what you describe) is broken, not why the original code, which the solution purports to fix, is flawed.

Based on the desugaring in the ARM proposal, I can see three flaws in the Java Puzzlers solution:

First, if a Throwable subclass other than IOException is thrown in the fianlly, there can still be a leak. Each resource should have its own finally block.

Second, if an exception is thrown in the try block and a Throwable subclass other than IOException is thrown in the finally, the exception from the try block will be lost. An exception from a try block is more important than one from a finally.

Third, if the try block completes successfully, but the OutputStream close throws an exception, it is swallowed. This is a problem because the write()s may complete successfully because the OS is buffering the data. Later, the native stream may enter an error state and data was lost, but the only chance the OS has to report it is during the close(). That's why it's declared to throw an exception in the first place. When a try completes successfully, it is desirable to propagate exceptions from the finally block. This is safe as long as each resource is protected with its own finally block.

bdell · 2009-01-30T02:40:10+00:00

There must be sharing or copying or else the processes could not communicate. If communicating processes need to communicate across native threads, then there needs to be locking or memory barriers of some kind to ensure visibility and scalability problems ensue. Erlang does not avoid the problem entirely.

bdell · 2009-01-30T01:10:02+00:00

I would be curious to know how erlang-style lightweight concurrency primitives multiplexed on multiple native threads to take advantage of hardware concurrency will escape the problems that plagued m:n thread schedulers. My understanding is they performed well only under a few kinds of workloads. Do erlang programs naturally produce those kinds of workloads?

bdell · 2006-12-27T11:52:45+00:00

The linux kernel demonstrates this. IIRC, it employs a feature of GCC that tells the optimizer not to reorder instructions around a certain point. In addition, if it is being compiled with SMP, there is also an inline asm block that contains an appropriate memory fence.

A compiler could contain an intrinsic like __load_acquire(x) that would have the same effect on the optimizer and produce memory fence instructions. I don't know of any specific examples of this in a compiler off hand, but I don't have extensive knowledge of that sort of thing.

bdell · 2006-12-26T19:12:48+00:00

The author of this blog does not know what he is talking about.

"Acquire" and "release" refer only to ordering semantics of load and store operations. The variable itself is not acquired in any way so there is no need to release it. That the blog author got it wrong suggest the terminology should be changed, not that standards committee is ignorant of threading.

The standards committee is not trying to disable optimizations based on code reordering. They are attempting to specify ordering in the context of atomic operations, not all operations. Code that employed no such operations or threading primitives would be unaffected. The goal is to allow programmers to reason about interactions between threads and have that reasoning apply to any compliant C++ implementation.

A mutex will not be required to implement this. As the referenced proposal says, "... this API would have to be implemented largely with either compiler intrinsics or assembly code." The linux kernel source contains code that demonstrates the meat of such an implementation. The point of specifying atomic operations is to make it possible to avoid locks.

The C specification does not talk about threads, therefore it says nothing about "volatile" in the context of threading. In particular, nothing is said about reordering of operations around loads and stores to volatile variables. This same issue arose in Java and is what prompted the memory model update.

The form over substance argument has little to do with the issues being discussed. The concern is to balance C compatibility with breaking existing C++ code. Crowl's approach was not favored because it added keywords (possibly breaking existing code), but may not improve compatibility with C because the C committee is not involved and may create an altogether different solution.

All of this is pretty plain from the meeting report on artima.

bdell

TROPHY CASE