Neat hack, but IMO this just loses waaay too many features and UX that Github et al. have. Only masochists will use this. Here are a few I can think of:

1. From a user perspective it’s “simpler” in that it saves maybe 1 command… git push (I’ve still going to want to make a branch), and clicking on the “create a PR” link. But you’ve also made updating a PR way more of a pain - it was git push, now it’s… I dunno some long command I don’t remember and looking up a PR number in the web interface?
2. Can’t request reviews from people.
3. Can’t enforce review requirements.
4. Can’t require review comments to be resolved (I bet it’s easy to miss review comments!)
5. Can’t easily tell who wrote review comments. Are you really supposed to have a conversation by adding // Dave: I agree under comments?
6. Can’t add comments to code that doesn’t support comments (e.g. packages.json)
7. No CI integration.

I guess some of those are fixable, but overall this seems like a clever hack but very clunky.

I guess it’s better than a mailing list at least.

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.

I think he meant anyone who can’t handle such modern innovations as bold and italic text would probably have an aneurysm if you told them about encryption.

I thought it was exactly the same based on the description.

Isn’t it actually because they moved most of their driver code onto the card itself or something?

Does that not happen with Mercurial? If not that seems like a point against it.

Git LFS does actually support file locking. But in general I find LFS to be hackily pasted onto Git and not very good (as with submodules).

That brings more problems. Despite the scaling challenges monorepos are clearly the way to go for company code in most cases.

Unfortunately my company heavily uses submodules and it is a complete mess. People duplicating work all over the place, updates in submodules breaking their super-modules because testing becomes intractable. Tons of duplicate submodules because of transitive dependencies. Making cross-repo changes becomes extremely difficult.

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.

git diff -w only ignores whitespace within a line (e.g. changing indentation). It doesn’t ignore adding or removing new lines.

But even if it did, wrapping a function call or a long string can introduce extra commas or quotes.

Yeah but sometimes you do get meaningless changes that aren’t just whitespace even with auto formatters. For example if you change the indentation on some code and that causes it to wrap an expression.

If Mallory were to discover a blind spot in the semantic diff logic

This is a very big stretch IMO. That xz change wasn’t actually the exploit, it was just used to make the exploit less detectable. And it was added by people with commit access so it didn’t even have to go through code review.

On top of that, code review is not magic. It’s easy to get bugs past it hiding in plain sight (if that wasn’t the case Linux would be bug free!).

Can you think of an actually realistic example?

Awkwardly. Pretty much generate a patch and email it as an attachment.

All the old people have learned the old systems (C, Perl, etc) and don’t want to have to learn something new, whereas young people are happy to use something newer and better (Rust, Typescript, etc.) because they don’t mind learning and don’t have a ton of old knowledge to throw away.

Yes that’s a big generalisation and there are plenty of exceptions, but in my experience it’s broadly true.

I work on an open source project which has a C component. I offered them our closed source C++ version which is way better and fixes a load of issues… Not interested. They learnt C in the 70s and don’t see why they should have to change.

Actually that project is a mix of old curmudgeons and young PhD students so there is a bit of a mismatch, but I didn’t feel like fighting the naysaying so…

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!

IMO Julia just had way too many big issues to gain critical mass:

1. Copied 1-based indexing from MATLAB. Why? We’ve known that’s the worse option for decades.

2. For ages it had extremely slow startup times. I think because it compiles everything from C, but even cached it would take like 20s to load the plotting library. You can start MATLAB several times in that time. I believe they improved this fairly recently but they clearly got the runtime/compile time balance completely wrong for a research language.

3. There’s an article somewhere from someone who was really on board with Julia about all the issues that made them leave.

I still feel like there’s space for a MATLAB replacement… Hopefully someone will give it a better attempt at some point.

Anything that helps scientists and engineers move away from MATLAB is welcome.

The MATLAB language may be pretty bad but IMO that’s not what makes MATLAB good. Rather it’s:

1. Every signal processing / maths function is available and well documented. I don’t know how well Julia does on this but I know I wouldn’t want to use Python for the kinds of things I used MATLAB for (medical imaging). You don’t have to faff with pip to get a hilbert transform or whatever…

2. The plotting functionality is top notch. You can easily plot millions of points and it’s fast and responsive. Loads of plotting options. I just haven’t found anything that comes close. Every other option I’ve tried (a lot) only works for small datasets.

I am indeed thinking of CPython because a) approximately nobody uses PyPy, and b) this article is about CPython!!

In any case, PyPy is only about 4x faster than CPython on average (according to their own benchmarks) so it’s only going to be able to compete with C++ in random specifics circumstances, not in general.

And PyPy still has a GIL! Come on dude, think!

Yeah exactly. You made it faster through algorithmic improvement. Like for like Python is far far slower than C++ and it’s impossible to write Python that is as fast as C++.

Sure but that’s not relevant to the current discussion. The point is that removing the GIL doesn’t affect Numpy because Numpy is written in C.