BatmanAoD

U sane, bro?

You mean `jj advance bookmarks`? It still seems like a pain to not just have it happen automatically on `commit`. (I use the "experimental" auto-advance-bookmarks feature, but it's got a lot of papercuts.)

I honestly get the sense that several, or possibly most, jj maintainers truly are not familiar with the "typical" way devs use git. They really do not seem to consider branches with many commits to be a common use-case.

I still don't understand your point. The comment you responded to says:

>As a general rule, if someone ever posts any kind of career troubles on any platform, the only correct responses should contain sympathy or a relevant career opportunity.

Do you disagree with that? Do you just disagree with the use of the phrase "career troubles"?

I don't understand your point; what other type of messages are you saying should be acceptable as a response to a post about career troubles?

Why are you conflating "no intention of doing a rewrite" with his actual wording, "we haven’t committed to rewriting"? The latter does not at all indicate that there would definitely not be a rewrite.

What makes you say that?

This seems to be missing the point. Sometimes users see error messages. Sometimes they're good, sometimes they're bad; and yeah, software engineers should endeavor to make sure that error behaviors are graceful, but of all the not-perfect things in this world, error handling is one of the least perfect, so users do encounter unfortunately ungraceful errors.

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.

> Reading C++ for dummies even though I had untreated ADHD and couldn’t sit still long enough to get much past std::cout.

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.

Like a lot of blog posts, this feels like a premise worth exploring, lacking a critical exploration of that premise.

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.

If 20% of people really think they'd be better off as factory workers, that's actually kind of a lot. Can you imagine if 20% of the working population really did work in factories? That's an enormous number.

...okay, so what is "PI lockfree"?

Nobody said anything about RISC-V being "perfect" or not. The problem isn't how good RISC-V is or isn't; it's that your desire for software to target one and only one type of hardware just doesn't make any sense. That's not how computers have ever worked.

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.

So the "right way" is to replace all hardware with new hardware, and the second-best solution is for CISC systems to emulate a specific RISC architecture? And you think this will be more maintainable, performant, etc? Do you have even a shred of evidence that this makes any sense at all, beyond "RISC is a good standard"?

Are you proposing a kernel that would only run on risc-v hardware, or expecting that people would run some kind of emulator?

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

Any good Vim-emulator extension has macro support. VSCode also has an extension that lets you run the actual neovim server to manage your text buffer.

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.

Precisely true, but from a PHP background, I assume there's not much to prepare you for this.

What are you talking about? Even the standard library is littered with `any` and reflection. Look at how JSON serialization works.

That's...not...how threads or async work...?

> 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.

Okay, that's quite funny. Thank you.

That's...not precisely true. The C++ standard doesn't specify how std::async works, and for a while GCC just ran the operation sequentially, and later both GCC and Clang launched new OS threads by default. https://stackoverflow.com/q/10059239/1858225

Honestly, this is better than the article itself.

Well, yeah. Hence the rest of my comment. And if you don't go through glibc, then you still must follow the C ABI rules (since that's the only thing the kernel understands), and you are at risk of having your calls break when the kernel is updated (it's already been mentioned elsewhere in these comments that this actually happened to Go on Mac).

Sure. You can re-implement everything starting with the Kernel, as long as you don't have to interface with any of the C microcode on the hardware itself. And, yeah, people are doing this, for instance with Redox OS.

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.

It's "organic" because, as this article is pointing out, creating alternatives is really difficult due to this exact lock-in, both at the OS level and at the hardware-vendor level.

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

You still have to follow the C ABI when interfacing with C. That's the exact problem being called out in the post.

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.

It runs on all hardware because hardware manufacturers support it, which they essentially must do because that's what's expected. It's a self-fulfilling prophecy (and arguably a vicious cycle).

Okay, here's the Linux syscalls(2) man page: https://man7.org/linux/man-pages/man2/syscalls.2.html

The second sentence is:

> System calls are generally not invoked directly, but rather via wrapper functions in glibc (or perhaps some other library).

Okay, so we can't avoid C that way, but what's the "invoked directly" way? Well, it's syscall(2): https://man7.org/linux/man-pages/man2/syscall.2.html

This man page actually reiterates what the other one, that you shouldn't be making syscalls directly! But in any case, what is `syscall()`?

...it's a C macro.

So yeah, Linux does require programs to use C. You've just been isolated from it.

It does now, but that's a fairly recent development. That's why Steve is calling this a "regression".

It used to have a motto that was something like "a shell for the github age", and I guess they never picked something more appropriate.