BatmanAoD

joined 2 years ago
[–] BatmanAoD@programming.dev 7 points 6 months ago

I agree that it's a "cop-out", but the issue it mitigates is not an individual one but a systemic one. We've made it very, very difficult for apps not to rely on environmental conditions that are effectively impossible to control without VMs or containerization. That's bad, but it's not fixable by asking all app developers to make their apps work in every platform and environment, because that's a Herculean task even for a single program. (Just look at all the compatibility work in a codebase that really does work everywhere, such as vim.)

[–] BatmanAoD@programming.dev 2 points 6 months ago* (last edited 6 months ago)

Oh, I see, so you don't exercise your muscle memory but you at least see the "raw" commands more often.

Looks like this was suggested in nushell, and someone came up with a way to emulate the behavior manually: https://github.com/nushell/nushell/issues/5552#issuecomment-2113935091

Edit: there's another issue for this: https://github.com/nushell/nushell/issues/5597

Hopefully nu will decide to implement it properly in the future.

[–] BatmanAoD@programming.dev 1 points 6 months ago (3 children)

Hm, I'm not sure what you're looking for, then.

How are fish abbreviations different from nushell aliases for working on temporary machines? Surely your Windows sandboxes don't have fish installed?

[–] BatmanAoD@programming.dev 2 points 6 months ago (5 children)

I think it really depends how much time you actuall spend working on these temporary systems, and what mechanisms are available for automatically configuring those systems, even temporarily. You can generally assume that some version of bash is available on all systems, so if you have a bashrc that you like, you could use sshrc or kyrat to at least bring over some functions and aliases (I used sshrc long ago but haven't tried kyrat): https://github.com/cdown/sshrc, https://github.com/fsquillace/kyrat

If you do want to use nushell on remote systems, possibly xxh would enable that; I haven't used it personally, but it looks promising: https://github.com/xxh/xxh

If you're not using ssh, then it really depends what you are doing.

[–] BatmanAoD@programming.dev 1 points 6 months ago

I don't think it's fair to consider unsafe Rust such a small subset of the language that it requires calling it out as a separate thing from "Rust" in the title of an article. Unsafe constructs are necessary in the standard library and many crates, whether or not you use it in the code you actually write.

[–] BatmanAoD@programming.dev 2 points 6 months ago

My point is that the claim in the comic and in other comments that this corrupts your repo or loses work simply isn't true.

[–] BatmanAoD@programming.dev 5 points 6 months ago (4 children)

It's not even actually that bad, at least not since January of 2020: https://stackoverflow.com/a/59687740/1858225

[–] BatmanAoD@programming.dev 5 points 6 months ago* (last edited 6 months ago)

Huh. I had forgotten that git does actually create a file with the branch name. But it doesn't actually screw up the .git folder or lose your data when you try to do a rename like this; it just rejects the rename unless you also use the "force" option. This has been the case since at least January of 2020. But apparently it actually doesn't always use a local file for branch names, so sometimes there's a problem and sometimes there isn't, which I guess is arguably worse than just having consistently-surprising behavior.

[–] BatmanAoD@programming.dev 74 points 6 months ago (24 children)

I honestly don't even understand the joke. Case-insensitive file names cause problems, but what does that have to do with version control branch names?

[–] BatmanAoD@programming.dev 4 points 7 months ago

Yeah, consistency is good, which is why it's good to follow the spec. I'm saying that the decision to make errors be flat strings in the spec was a bad one. A better design would be what you have, where code is nested one level below error, plus permitting extra implementation-defined fields in that object.

[–] BatmanAoD@programming.dev 17 points 7 months ago (2 children)

The spec requires errors to be a single string, and also mandates using the space character as a separator? I'm not a fan of deviating from spec, but those are...bad choices in the spec.

view more: ‹ prev next ›