In that case (and even sometimes in the more "graceful" cases), we don't always expect the user to know what an error message means.

You may have lucked out. I also didn't get terribly far in that book, but I thought it was fairly weird when I tried to read it, and after majoring in CS in college and eventually reading some very good books on programming, I believe I was entirely justified in not liking that one.

Yes, "inevitabilism" is a thing, both in tech and in politics. But, crucially, it's not always wrong! Other comments have pointed out examples, such as the internet in the 90s. But when considering new cultural and technological developments that seem like a glimpse of the future, how do we know if they're an inevitability or not?

The post says:

> what I’m most certain of is that we have choices about what our future should look like, and how we choose to use machines to build it.

To me, that sounds like mere wishful thinking. Yeah, sometimes society can turn back the tide of harmful developments; for instance, the ozone layer is well on its way to complete recovery. Other times, even when public opinion is mixed, such as with bitcoin, the technology does become quite successful, but doesn't seem to become quite as ubiquitous as its most fervent adherents expect. So how do we know which category LLM usage falls into? I don't know the answer, because I think it's a difficult thing to know in advance.

By the way, what do you mean by "PI lockfree"? Googling "ISA PI lockfree" just leads me to...another hacker news thread where you're arguing that RISC-V should replace everything.

Anyway, yes, please do "investigate how much out-of-the-box-thinking and disruptive this is" before continuing to have these inane arguments.

....or do you think that because RISC-V is "standard", assembly for RISC-V would run on any hardware?

The settings GUI in VSCode is just an auto-generated layer over raw JSON files. You can even configure it to skip the GUI and open the JSON files directly when you open settings.

> Blocking I/O executed on another thread, with a callback to execute when done, becomes async I/O (from the user's PoV).

That's not what we're talking about when we discuss languages with async I/O, though. That's just bog-standard synchronous I/O with multithreading.

> The read/write operations are still potentially blocking, so for efficiency you need multiple threads.

That doesn't actually follow. The entire point of language-level async I/O is to be able to continue doing other work while waiting for the kernel to finish an I/O operation, without spawning a new OS thread just for this purpose.

But if you actually want to program something usable in conjunction with existing software, such as Linux, you need to use the C ABI. There is no alternative.

You shouldn't need a "miracle language" or even an "all-encompassing solution" to have a chance to break free of this.

Zig solves interoperability by incorporating an entire copy of LLVM. Go does do bare metal syscalls, but as mentioned elsewhere in these comments, this has caused breakage on Mac when the kernel was updated, because this interface isn't stable.