

Yes, but the tools provided by Rust:
- Prevent most common ones via aliasing^mutability, Send and Sync marker traits, etc.
- Require explicitly marking the cases not handled by this, e.g. unsafe features require an
unsafe {}block to be used.


Yes, but the tools provided by Rust:
unsafe {} block to be used.

…which is why I love #[rustfmt::skip] so much! You can do stuff like
#[rustfmt::skip]
const DIRECTIONS: [[i8; 2]; 4] = [
[0, 1],
[-1, 0], [1, 0],
[0, -1],
]
while still enjoying the convenience of auto formatting elsewhere.
Although linters which act on the behavior of code are unequivocally a good thing, e.g. “hey, this comparison will always return false you probably made a mistake here”.


People (such as myself) make the argument that it does a better job because it’s focused more on reading code than writing it since you don’t start in the “write” mode like in most editors.
I would say the choice of text editor shouldn’t make a difference in productivity so long as it doesn’t actively get in your way too often (looking at you, poorly implemented autopairs) and it supports the relevant LSP and debugging protocols.
Sorry, I thought we were using seal pelts as a stand in for something actually useful.
People buy what they can afford. The seal clubbers also like to put “ethically harvested” stickers on their pelts.
I believe they’re making a point about media’s efforts to blame consumers for global warming, while the 20 most emissive corporations singlehandedly released 40% of global greenhouse gas emissions in 2024.
Counterargument: ctrl+f is a great place for regex. Write once read never problems are a great application for unreadable languages. Imagine if people wrote scripts in the language vi uses for editnig<escape>bceediting, which mostly isn’t even displayed as it’s typed! <escape>
But yeah, it’s kind of terrible for anything else.


I don’t know much lisp, but in scheme you can do (1 . + . 2) = (+ 1 2)


Nice timing, I just finished it!
I was able to adjust the bit mask format to be easier to work with by hand and got it most of the way, then used the SAT solver to quickly finish the rest when I got stuck.


Based on my other comment, do you have any in mind that would be more appropriate?


For each operation my CPU’s ALU can do, I need to find a bit mask that turns it on only for the desired set of 8 bit opcodes. The bit mask is of the form [01_].[01_][01_][01_][01_][01_][01_][01_][01_] where 0 and 1 mean the bit has to match and _ means it doesn’t matter. The bit before the . is the xor of all the other bits in the opcode.
The solver has to figure out both which opcodes represent each instruction and what bit masks are needed to give them the desired operations.
I ultimately switched to a slightly different approach. It turns out the xor part of the mask isn’t very useful since the combinations I need aren’t super complicated. The trouble was that an operation could only trigger for a power of 2 of opcodes, so I added a secondary mask to each operation:
Base mask: still [] x8\
Secondary mask: [] x8 (x means both 0 and 1)
For the secondary mask, 1 matches only if the current bit or the one to the left is true (left of the leftmost is the rightmost). 0 is the same but with nand in stead of or. x, requiring both, only matches if exactly one matches.
Using 1 or 0 multiplies the number of matching opcodes by 3/4 (or a more complicated fraction if their areas of influence overlap), which allows much more freedom.
Due to restrictions in the game and my "hard"ware, I’m only able to use [] for the secondary mask, since a nand gate doesn’t respond right to being hooked up to a bunch of toggleable and inputs but xor/or gates do (xor is just as fast in game).
Just saying…
:%s/\s*—(\s*)/, /g