It is no secret that git’s interface is a bit too complex

Right but that’s mostly because the CLI is a mess, not because the fundamental data model is bad.

Some bad interview questions are like that, sure. But they’re supposed to be things you are very unlikely to have done before and can reasonably figure out. It’s not too hard to come up with simple questions like that. (Though I will grant many people don’t seem to bother.)

IMO this is not a helpful way to put it. They measure skill under stress. Stress may have a large effect on skill level for some people but highly unlikely that it’s so large that performance is completely random.

I failed because I’d misformatted the for loop

Unlikely that you failed the interview because of a basic syntax mistake.

My personal preference when evaluating candidates ability to code is reading their actual production code

This would be a great interview method! But 99% of people are not working on open source code professionally so it doesn’t really work in general.

You don’t know how good you’ve got it. The hiring process in other industries is much worse.

Yeah me too but if you keep reading they didn’t actually “move on” in the way that it sounds.

• You have to tediously git submodule update --init --recursive every time you checkout a commit. There’s an option to do it automatically but it’s super buggy and will break your .git directory.
• Switching between branches that have different sets of submodules doesn’t really work. Git won’t remove/recreate the submodules like it will for normal directories. Worst case is changing a directory to a submodule or vice versa.
• If you’re working on a feature that spans several submodules you have to switch branches in all of them instead of once.
• Making co-dependant changes across submodules is a nightmare.
• If you’re using submodules for first party code (not uncommon), it basically creates a new public interface where you didn’t have one before. Now you have to worry about backwards compatibility and testing becomes much harder. Monorepos don’t have that problem.

The list goes on… Some of them depend on exactly what you’re using them for.

The slightly frustrating thing is that there isn’t a great answer for what to use instead. Git subtree has its own problems. Language-specific package managers do too. There aren’t any good languages agnostic package managers I know of.

I’m really hoping Jujutsu will come up with a better solution because it is possible. But it’s hard, and they are constrained by Git compatibility so I won’t hold my breath.

I agree, but if you take away the hard numbers from this (which you should) all you’re left with is what we all already knew from experience: fast languages are more energy efficient, C, Rust, Go, Java etc. are fast; Python, Ruby etc. are super slow.

It doesn’t add anything at all.

IMO it’s not as good a language as Rust, so I wouldn’t learn it for the purposes of making something. However it’s very easy to learn (at least to a productive level), so you may as well if you want to.

Just work through go by example and see what you think.

By far the best thing about Go is the tooling. Language itself is eh.

Worktrees are great, and a good reason (if you needed any more) to avoid submodules like the plague. Worktrees don’t work with submodules.

They used to have Typescript. Looks like they removed it at some point.

It’s barely transpiled. There are a couple of features that involve actual code generation - enums and namespaces (which are almost never used), but the vast majority of it is just stripping the type annotations so the performance will be 100% identical.

It’s like having “Python” and “Python with type hints” as separate languages and claiming there is a big speed difference between them.

That actually hasn’t been my experience of programmers’ behaviour. There are many developers who can’t be bothered to set up tools like IDEs, intellisense, debuggers, etc. which would definitely make them faster after the initial setup. I can easily believe it’s the same for AI.

That said, it does seem silly to require you to use it.

Sure, but I don’t think that’s an excuse for things like global hotkeys not working.

It’s a very heavily gamed benchmark. The most frequent issues I’ve seen are:

• Different uses of multi-threading - some submissions use it, some don’t.
• Different algorithms for the same problem.
• Calling into C libraries to do the actual work. Lots of the Python submissions do this.

They’ve finally started labelling stupid submissions with “contentious” labels at least, but not when this study was done.

They chose an “optimized” set of algorithms from “The Computer Language Benchmarks Game” to produce results for well-optimized code in each language.

Honestly that’s all you need to know to throw this paper away.

Stop linking this, please! Any benchmark where Typescript and JavaScript are different is trash.

Wow that’s kinda crazy. My work is the opposite - we’re banned from using AI. Why is nobody in the sensible middle?

Basically it uses bind mounts instead. See this page for details.

I haven’t actually used (since Plan 9 is dead) and I doubt it covers every use case for symlinks (e.g. this wouldn’t let you commit them to a git repo), but I really think the benefits of symlinks not existing at all would far outweigh the effort of having to think of alternative solutions.

Sadly we don’t get to live in that alternative history now… :-/

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.