They do have a ton of tests actually. In their defence, if this task is doing Git things then just killing it when it goes badly is probably the best you can do. Git itself is quite buggy if you stray from the most basic setup. I've had it almost completely destroy my .git directory in the past when using submodules.

On the other hand, Gitlab itself is an enormous entirely untyped Ruby monster, with extremely difficult to follow code. Not in terms of individual functions - except for the lack of types mean you can't really know what they do, they are quite clear and well written. The issue is the control flow between parts of the system. It's difficult to know what calls what, so I'm not surprised they occasionally have to give up.

I had a play with Deno's Fresh web framework recently (Typescript/TSX but mainly server rendered). IMO it's light years ahead of other solutions.

You get full amazing Typescript typing, including in templates (unlike Go for example), but unlike React you don't have to deal with JavaScript tooling or complex client side state management. It's a real breath of fresh air. (Ha that wasn't even intentional.)

Yeah you're right that comment doesn't make any sense.

I think the point is that Rust will make it easier to distribute portable binaries. You can use Musl and then you get a completely static binary with no dependencies that works on old versions of Linux.

You can achieve the same with C++, but it's waaaay more hassle.

It has them, but you can't use them from a single-file script. You have to set up a pyptoject.toml, create a venv and then pip install . in it. Quite a lot of faff. It also makes some things like linting in CI way harder than they should be because the linters have to do all that too.

With Deno a single .ts file can import third party dependencies (you can use any URL) and Deno itself will take care of downloading them and making them available to the script.

Some other languages have this feature to certain degrees. E.g. I think F# can do it, and people are working on it for Rust, but Deno is at the forefront.

We should not be designing around singular implementations

Like Linux?

Yeah I would avoid this. The meaning is not obvious and at least in the examples given there are far better ways to do it.

Yeah exactly that. Conceptually it's far superior to manyrepos. But it does have downsides:

• git will be slower, and it doesn't really have great support for this way of working. I mean it provides raw commands for partial checkouts... but you're kind of on your own.
• You can't realistically view a git log --graph any more since there will be just way too many commits. Though tbf you can get to that state without a monorepo if you have a big project and work with numskulls who make 50 commits for a small MR and don't squash.

Also it's not really a downside since you should be doing this anyway, but you need to use a build tool that sandboxes dependencies so it can guarantee there are no missing edges in your dependency graph (Bazel, Buck, Pants, Please, Landlock Make, etc.). Otherwise you will be constantly breaking master when things aren't checked in CI that should be.

That's exactly the same in git. The old commits are still there, they just don't show up in git log because nothing points to them.

The only benefit Octave has over MATLAB is that it's free. Which is something I guess, but in practice it is MATLAB without the benefits of MATLAB.

It's plotting functionality sucks as much as anything else, it has fairly good toolkit support but not remotely like MATLAB, and it still has the mediocre MATLAB language. Worse - with custom incompatible extensions!

Pip and venv have been tools that I’ve found to greatly accelerate dev setup and application deployment.

I'm not saying pip and venv are worse than not using them. They're obviously mandatory for Python development. I mean that compared to other languages they provide a pretty awful experience and you'll constantly be fighting them. Here's some examples:

• Pip is super slow. I recently discovered uv which is written in Rust and consequently is about 10x faster (57s to 7s in my case).
• Pip gives terrible error messages. For example it assumes all version resolution failures are due to requirements conflicts, when actually it can be due to Python version requirements too so you get insane messages like "Requirement foo >= 2.0 conflicts with requirement foo == 2.0". Yeah really.
• You can't install multiple versions of the same dependency, so you end up in dependency resolution hell (depA depends on foo >= 3 but depB depends on foo <= 2).
• No namespace support for package names so you can't securely use private PyPI repositories.
• To make static typing work properly with Pyright and venv and everything you need some insane command like pip install --conf-settings editable-mode=compat --editable ./mypackage. How user friendly. Apparently when they changed how editable packages were installed they were warned that it would break all static tooling but did it anyway. Good job guys.
• When you install an editable package in a venv it dumps a load of stuff in the package directory, which means you can't do it twice to two different venvs.
• The fact that you have to use venvs in the first place is a pain. Don't need that with Deno.

There's so much more but this is just what I can remember off the top of my head. If you haven't run into these things just be glad your Python usage is simple enough that you've been lucky!

I’m actually in the process of making such a push where I’m at, for the first time in my career

Good luck!

The kitty graphics protocol lets you send images to display in the terminal. I had a play around with it trying to make a similar GUI. The big gotcha is text rendering. You can either stick to normal grid aligned monospace, or I think you could maybe use a texture atlas, but it's not going to be very efficient at all. I haven't got as far as trying that though.

The videos... while they work are probably uncompressed video which is only going to work well over a very fast network.

Note that worktree does not work with submodules. Which IMO is a strong enough reason to never use submodules because worktrees are so useful!