BatmanAoD

5 ms·

1.
by BatmanAoD 3mo ago
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.)
2.
by BatmanAoD 3mo ago
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.
3.
by BatmanAoD 3mo ago
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 o
4.
by BatmanAoD 4mo ago
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?
5.
by BatmanAoD 4mo ago
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.
6.
by BatmanAoD 5mo ago
What makes you say that?
7.
by BatmanAoD 9mo ago
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
8.
by BatmanAoD 1y ago
> 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
9.
by BatmanAoD 1y ago
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
10.
by BatmanAoD 1y ago
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.
11.
by BatmanAoD 3y ago
...okay, so what is "PI lockfree"?
12.
by BatmanAoD 3y ago
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 sens
13.
by BatmanAoD 3y ago
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 h
14.
by BatmanAoD 3y ago
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?
15.
by BatmanAoD 3y ago
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
16.
by BatmanAoD 3y ago
Precisely true, but from a PHP background, I assume there's not much to prepare you for this.
17.
by BatmanAoD 3y ago
What are you talking about? Even the standard library is littered with `any` and reflection. Look at how JSON serialization works.
18.
by BatmanAoD 3y ago
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
19.
by BatmanAoD 3y ago
Okay, that's quite funny. Thank you.
20.
by BatmanAoD 3y ago
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://stack
21.
by BatmanAoD 3y ago
Honestly, this is better than the article itself.
22.
by BatmanAoD 5y ago
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
23.
by BatmanAoD 5y ago
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 actuall
24.
by BatmanAoD 5y ago
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 lang
25.
by BatmanAoD 5y ago
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 el
26.
by BatmanAoD 5y ago
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).
27.
by BatmanAoD 5y ago
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 fun
28.
by BatmanAoD 5y ago
It does now, but that's a fairly recent development. That's why Steve is calling this a "regression".
29.
by BatmanAoD 5y ago
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.
30.
by BatmanAoD 6y ago
Nothing in this article seems to be saying that C "isn't useful". It also doesn't state that bounds checks are the "most difficult thing in software development." As the article mentions, C is 50 years old. The

More ›