I think NixOS itself could do a much better job here in terms of moving stuff from defaults into profiles.

But yes, it'd also be nice to have something closer to dockerTools.streamLayeredImage.

That, in itself, should be plenty of reason to stay the hell away from it.

> I really can't think of anything that comes close in terms of [...] developer experience.

Of all the languages that I have to touch professionally, C# feels by far the most opaque and unusable.

Documentation tends to be somewhere between nonexistant and useless, and MSDN's navigation feels like it was designed by a sadist. (My gold standard would be Rustdoc or Scala 2.13 era Scaladoc, but even Javadoc has been.. fine for basically forever.) For third-party libraries it tends to be even more dire and inconsistent.

The Roslyn language server crashes all the time, and when it does work.. it doesn't do anything useful? Like cross-project "go-to-definition" takes me to either a list of members or a decompiled listing of source code, even when I have the actual source code right there! (I know there's this thing called "SourceLink" which is.. supposed to solve this? I think? But I've never seen it actually use it in practice.)

Even finding where something comes from is ~impossible without the language server, because `using` statements don't mention.. what they're even importing. (Assuming that you have them at all. Because this is also the company that thought project-scoped imports were a good idea!)

And then there's the dependency injection, where I guess someone thought it would be cute if every library just had an opaque extension method on the god object, that didn't tell you anything about what it actually did. So good luck finding where the actual implementation of anything is.

I almost exclusively work in C# and have never experienced the Roslyn crashes you mentioned. I am using either Rider or Visual Studio though.

> Like cross-project "go-to-definition" takes me to either a list of members or a decompiled listing of source code, even when I have the actual source code right there!

If these are projects you have in the same solution then it should never do this. I would only expect this to happen if either symbol files or source files are missing.

I use VS Code on macOS for all of my C# code over the last 5 years and also never experienced Roslyn crashes.

Try "go to implementation" in place of go to definition.

You can back up a debunking with receipts or reputation. Ideally, both.

You and anotherlogin448 have neither, but also show incredible aggression towards anyone pointing that out.

Your confidence might actually be warranted, but there's no reason for any one of us to take you on your word, and neither of you have given anything else.

> Word and other editors/word processors change '--' to an em-dash

I'd be suspicious of people doing their writing in Word and copying it over into random comment fields, too.

> And the "slang version" of an em-dash is "I went to work--but forgot to put on pants", not "I went to work - but forgot to put on pants".

The fun thing about slang is that different groups have different slangs! I use the latter pretty regularly, but have never done the former.

> BTW, "humans almost always tend to use" is very poor writing--pick one or the other between "almost always" and "tend to".

Nah.

> It wouldn't be a bad thing if LLMs helped increase human literacy,

Where "literacy" is defined as strictly following arbitrary rules without any concern for whether it actually helps people read it?

And, on the assumption that those rules actually are meaningful, wouldn't you rather have people learn them for themselves?

But do you call that latter thing you do “an em-dash”? Do you tell a peer “You should put an em-dash here” when what you mean is a “space en-dash space”?

I don't call it anything, because I'm not in the business of telling people how to write. (Besides asking them not to use SlopGPT, of course.)

"Uses it" sounds strong.. I don't see any link to it from https://github.com/kieler/elkjs?

Annoyingly, anyone can just.. request a deepwiki for any GitHub repo. That one exists doesn't mean that it's endorsed or reviewed by the project.

They just kind of barged in, welcome or not. Just another SEO slop-spammer.

Hmm you are right, there is no direct link.

I seem to have found it via a google search.

So in the end people will believe that these are the official docs…

A couple of years ago the OCaml and Julia languages already had to deal with a content farm that created wikis for them, filled them with LLM-generated, blatantly wrong or stupidly low quality content, and SEOed its way above actual learning materials. Cue in the newbies to these languages being incredibly confused.

This at least tries to generate the text out of the actual project, but I'm pessimistic and think it'll cause similar confusion.

Yep, That's the goal! ^^

The former. If you intend to hard-fork then Git's model is already fine. If you're soft-forking and want to model your divergence explicitly then Lappverk might be for you.

Yeah, I mentioned Quilt in the post! Lappverk is effectively an exercise in "What if Quilt, but you could interact with it using any Git tooling, rather than Quilt's half-baked custom VCS?".

Have you seen git-spice? It may be up your alley.

https://github.com/abhinav/git-spice

I haven't, no. But as far as I can tell from the documentation, it looks more like an alternative to stgit (with a similar lack of history or collaboration support)?

stgit is similar in that it sits with git, but it's not the same workflow. git-spice has branches per feature that base on one-another. It's more git-like than quilt-like.

What you get is git-styled patch-series development. Branches on branches where each branch maintains history of the feature.

A git-spice workflow is compatible with GitHub style PRs where a PR depends depends on another PR.

Or pair git-spice with format-patch you can share with developers who prefer patch files. Or take patches from someone and import each patch as a branch, then let git-spice track the stack position.

(Author here.)

> fork the repo (at whatever tag makes sense), then periodically sync with the latest code for that version.

Yeah, this is the workflow that Lappverk is trying to enable.

The problem is that neither of Git's collaboration models works well for this problem. Rebasing breaks collaboration (and history for the patchset itself), and merging quickly loses track of individual patches. Lappverk is an attempt to provide a safer way to collaborate over the rebase workflow.

But you can always create a new branch before rebasing if you want to store the old revision metadata. or do a git format-patches if you don’t want a bunch of branches laying around. So what are the ways to be safer than this?