No, rust is stricter because you need to think a lot more about whether weird edge cases in your unsafe code can potentially cause UB. For ex. If your data structure relies on the Ord interface (which gives you comparison operators and total ordering), and someone implements Ord wrong, you aren’t allowed to commit UB still. In C++ land I’d venture to guess most any developer won’t care - that’s a bug with your code and not the data structure.

It’s also more strict because rusts referencing rules are a lot harder then C’s, since they’re all effectively restrict by default, and just turning a pointer into a reference for a little bit to call a function means that you have to abide by those restrictions now without the help of the compiler.

The data model there is fundamentally different. That would break how git would work because operations that worked one way before would now no longer work that way. You’d functionally have rewritten and mapped all the old functionality to new functionality with subtle differences, but at that point is it even git? You have a wrapper with similar but subtly different commands and that’s it. It’s like saying “instead of reinventing functionality by building both ext4 and btrfs, why don’t we just improve ext4”?

The two are practically entirely different.

It being objectively better then SVN or CVS doesn’t mean that it’s the best we can do. Git has all sorts of non-ideal behaviors that other VCS’s don’t. Pijul’s data structure for instance is inherently different from git and it can’t be retrofitted on top. Making tooling only support git effectively kills off any potential competitors that could be superior to git.

One example is pijul specifically let’s you get away from the idea that moving commits between branches changes their identity, because pijul builds a tree of diffs. If two subtrees of diffs are distinct, they can always be applied without changing identity of those diffs. This means “cherry picking” a commit and then merging a commit doesn’t effectively merge that commit twice resulting in a merge conflict.

That’s one example how one VCS can be better.

Not OP, but personally yes. Every code forge supporting only git just further enforces git’s monopoly on the VCS space. Git isn’t perfect, nor should be treated as perfect.

The above is probably the reason why so many alternative VCS’s have to cludge themselves onto git’s file format despite likely being better served with their own.

Interesting new VCS’s, all supporting their own native format as well for various reasons:

• pijul
• sapling
• jujutsu

Sapling is developed by meta, jujutsu by an engineer at Google. Pijul is not tied to any company and was developed by an academic iirc. If you’re okay with not new:

• mercurial
• fossil
• darcs

VCS’s are still being itterated on and tooling being super git centric hurts that.

It’s not battle tested on massive projects nor does it have the prior mindshare git has. It doesn’t have a lot of tooling either. (Does any CI/CD system support pijul?) It has nice properties, but ultimately git with all it’s terrible warts is well understood.

Yeah, good commit messages are about intent and context of a change - not what the change itself is. We can look at the diff for that. Just write a single line or two summarizing what the commit does, and everything else should be adding context on top that doesn’t directly exist in the codebase.

Not having to swap over to a ticketing system just to see the context of a change is really nice (Or to add context on why changes are done a certain way). One line that says what you changed, then any context such as why it was done that way, and important notes about that change works wonders. It’s pretty much the exact model the Linux kernel uses, and it makes looking at changes great for anyone down the line.

According to the benchmark in the article it’s already way faster at n = 1000. I think you’re overestimating the cost of multiplication relative to just cutting down n logarithmically.

log_2(1000) = roughly a growth factor of 10. 2000 would be 11, and 4000 would be 12. Logs are crazy.

How would rust fare any better then a tracing GC? Realistically I’d expect them to use more memory, and also have worse determinism in memory management - but I fail to really see a case where rust would prevent memory leaks and GC languages wouldn’t.

There’s built in functions to leak memory that are perfectly safe. You can also do one really trivially by making a reference count cycle. https://doc.rust-lang.org/book/ch15-06-reference-cycles.html

Rust only prevents memory unsafety - and memory leaks are perfectly safe. It’s use after frees, double frees, etc. It prevents.

Rust doesn’t guarantee the lack of memory leaks anymore then java/C++ does, so sadly not sure if it would help here. :)

While part of me agrees, I will say most ecosystems have some glaring flaws in them. Python’s lack of lock files in particular is something that annoys me to no end. Having to use poetry, pipenv, or whatever else people are using now to get around it sucks. Python’s lack of being able to use multiple versions of the same library is also a thing… but not something I’ve found issues with personally.

I’m not going to say cargo is some mind blowing system cause I really don’t think it’s innovative, at all - but I do think it’s far better than most ecosystems just due to benefits of hindsight. Having an opinionated, simple build system that does all the right things out of the box is valuable, and I can’t think of any mainstream language that really hits that mark otherwise.

Also, it’s worth noting that cargo is a fairly good package manager all things considered. It has a native lock file format, unlike requirements.txt. Running code that’s built with cargo typically just works with cargo build. No futzing around with special build commands for your specific build tooling like in js. I can’t speak for maven since I’ve only used it a little bit and never used it enough to be comfortable with it… but cargo just doesn’t really have many major paper cuts.

Admittedly, cargo isn’t really special - it’s just a classic package manager that learned from the hindsight of its predecessors. It’s all minor improvements if any. There’s actually innovative build tooling out there: things like buck2, nix, etc. But those are an entirely different ball game.

See if you can find a book on python, and work through it a bit. Sit down with him once you know some and try making something basic with turtle or the likes. Your goal is to keep his interest up and not make it a “studying” thing. For a kid the most important part is that he needs to be able to see results of what he’s making. Drawing simple shapes, cool patterns, etc. in python is a nice way to start and it can teach all the basic initial things he needs to know.

There’s also simple robot kits for kids that could be fun to play with, which he could eventually move on to basic electronics to after from.

W.r.t. safe browsing, I’d try blocking egregiously bad stuff with some DNS blocker that you either buy or host using something like pihole. Use it to block ads and well known “bad” domain names. Also have a conversation about it. (I’m not sure how much this helps here considering he’s 8… but better then nothing.)

Rust does this too. In practice you just bump the lock file in rust and rebuild. It can be a bit rebuild heavy, but it’s not too bad with a proper cache.