The Plan 9 solution looks better to me. At the very least if you keep them then paths should be resolved lexically. I think most people are under the false impression that they are resolved lexically (i.e. foo/bar/../baz and foo/baz are the same).

But IMO it's better just to not have them and use another solution where you might have used them.

Yeah it's easier to compile software with support for the latest vector extensions etc. if you do it from source. It is also possible to do runtime detection and switch between implementations that way, but it requires more work.

Tbh I don't think it would make much difference in practice. If you are ok with supporting only recentish CPUs you can use one of these options:

• -march=x86-64: CMOV, CMPXCHG8B, FPU, FXSR, MMX, FXSR, SCE, SSE, SSE2

• -march=x86-64-v2: (close to Nehalem) CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3

• -march=x86-64-v3: (close to Haswell) AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT, MOVBE, XSAVE

• -march=x86-64-v4: AVX512F, AVX512BW, AVX512CD, AVX512DQ, AVX512VL

v2 is definitely fine and v3 is probably acceptable by now.

In short I don't think -march is a compelling argument for avoiding binary distribution. If it really makes a big difference either distribute multiple versions of your software using the flags above, or do runtime detection.

Ah yeah you're right - I missed that.

Definitely true for a minority. Not the way most of these articles are presented though (including this one).

Has anyone used Jujutsu and Sapling? Which is better?

I don't really know anything about Vim so I'd have to take your word for it.

Not the kinds of bugs he is talking about. This is about spectre mitigations.

Yep. It's great. The awesomeness of JSX/TSX without having to deal with client side JavaScript frameworks and their awkward state management systems (does anyone actually like hooks?).

unsigned is just short for unsigned int. int is 16 bits, so yes unsigned is also 16 bits.

I may have misunderstood your question because it doesn't really make sense...

Right... I mean the idea is obvious so why even bother with any of it? The only interesting reason is to demo that it actually works in reality which clearly they didn't.

My advice is that you debug via tests. If you install Rust-analyzer (you probably already have) then any tests you add have a little "Run test" and "Debug test" button next to them that you can just click. It magically works without having to faff around with JSON files.

As for your current setup, as other said you have an issue in Cargo.toml which is unrelated to debugging, and the target binary is in target/debug, not in the workspace root.

try to play hard ball by mentioning that they’re already talking to other providers

It's not "playing hard ball" to mention that you are look at other options. Jesus. As the author said, of course they would be. Wouldn't you if you were facing a 40x price increase?

To use a service tier that they’ve clearly exceeded for quite some time and then act surprised when they’re asked to upgrade.

We must have read totally different posts.