Solid state physics.

Nice idea!

In addition, we could have an allowlist for honest bots (like search crawlers).

You are not expected to remember a v6 address - or even v4 for that matter. They are designed for machines. DNS is designed for humans.

That works only if memory safety is optional. Additions of the language features needed for mandatory memory safety are backwards incompatible.

This is definitely into the territory of misinformation.

I don’t write Rust, but lots of programs I use do and, as I said, they seem to crash about as much as any other compiled language tools I use are written in

I already addressed this before. Regular crashes are almost always (I can't remember any exceptions) due to panics or aborts chosen by the user - especially due to unwraps. Using that to equate Rust programs' stability to 'any other compiled language tools I use are written in' is very disingenuous - because it's just as easy to handle those errors and prevent a crash at all.

If not doing segfaults is what makes a language “safe,” then it seems to me most modern languages are as safe as Rust

You are unnecessarily conflating issues here. 'Most modern languages' are not a replacement for what C, C++ and Rust can do. Go most famously had to retract their 'systems programming language' tag, for example. If a GC language meets your requirements - then by all means, use it. But it's not without reason that many companies have rewritten even their web backends in Rust. Memory safety without GC is a very big feature that a lot of professionals care about. It's not something to dismiss as trivial.

And while at it, you neglecting what segfaults represent. It's just a benign example of memory safety bug. It's benign because it gets caught causes the program to crash. There are a whole lot of them that causes the program to continue running - causing serious vulnerabilities. This is why even the US government and agencies recommend memory safety languages and especially Rust if performance and other limitations matter.

If we include crashes, then as I said, I see Rust programs crashing about as much as any other proglang.

I really don't want to repeat the reason twice in a single comment and 3 times including in my previous comment. But the only way you are going to make Rust crash as much as 'any other prolang' is to neglect idiomatic Rust. That isn't surprising because crashing anything is possible if that's your intention.

possibly several parents, like 8 parents

Fun fact. Such merges with more than 2 parents are called 'octopus merges'. The Linux repo has a single merge with 66 parents that Torvalds named the 'Cthulhu merge'.

Git never deletes a commit that is less than 90 days old.

On its own, that is. Not if you do a git gc.

Deleting a branch removes a reference to a commit, but the commits in the branch are still there.

but you can see them using “reflog” related commands

Reflog - one of the most underrated git commands that has the potential to save your life some day. At least one team member must learn it.

I'm yet to hear anyone saying that chatGPT can navigate the complex series of design decisions needed to create a cohesive app (unless of course, it was trained on something exactly the same). Many people report spending an inordinate amount of time rectifying the mistakes these LLMs make. It sounds like a glorified autofill (I haven't used them yet). I shudder to think about the future of the software ecosystem if an entire generation is trained to rely entirely on them to create code.

I’m curious, what tools are you talking about?

My fav ones are b4 and lei - both backed by a system called public-inbox. Linux kernel Lore is a public-inbox instance. There are other tools too - like patchwork. B4 and Lei, for example make working with patch series a breeze. You can also do things like compare different versions of the same branch - something that Github PR model is sorely lacking in.

What is happening here? Where is the patch?

That's what public-inbox and patchwork are for. Lei is especially useful with public-inboxes. If you are a bit more established, there are tools like notmuch and aerc that can make it even more easier.

Is each email a commit?

Yes, that's the idea. But more specifically, each email is a patch. Usually, a single patch is a refined commit with a full feature that you get after proper rebasing to weed out experimental code, mistakes, etc. A single submission is often just one or a handful of patches.

Where at the comments on the patch?

You don't deal with patches and emails manually that deep. You only need to have a rough awareness of the location of the patches (lei, notmuch, etc help you with this awareness). Code review mails and discussion mails are often threaded and intertwined with a series of patches. Threading actually helps you to follow the correct flow of discussion. Think of mailing lists as PR, Issue tracker and discussion forum rolled into one. You wont be hunting patches in this haystack. That's the job of the tools - they extract the correct series of patches in the right order, ready to be applied. Some can even alert you to the presence of newer revisions of the patch series. (I'm not even sure how far this goes - I haven't tried patchwork yet). There is actually a lot of automation involved.

but mailinglists are even worse

Even if they decided to keep mailinglists, they could at least put on a better UI

Frankly, here is the problem! All the other problems you mentioned boils down to this. The thing is - Github and Mailing lists deal with the same kind of data - with the latter being more transparent. But the mailing list interfaces are god-damn awful. But honestly, it doesn't have to be like that. I believe that with some proper UI design, mailing lists can offer an experience that's at par or even better than GH PRs. All the noise and clutter you mentioned doesn't need to be there. The tools make all the difference. Webmail clients like Gmail just butcher the mails. But it's already much better when you have a text-only threaded mail client. I believe people hate email workflow just because of how badly its interface is designed.

Facebook for all its nastiness was very much incompetent in influencing the direction of the web. Look at their failed attempts like free basics.

Google on the other hand has the web tightly in its dirty grip. At this point, they aren't even pretending to be nice. Even those plans that cause them reputational damage are brought back in some other name.

The only way to stop Google is for the regulatory agencies to put their foot down hard. They should be divided into at least a couple dozen companies that are not allowed to do business with each other.

Actually, this isn't the first time they did it. There was a thread by a mozilla ex-employee that described how Google destroyed Firefox's market share using the same dirty trick.

It's reported to be a declarative block list that's already vastly powerless compared to regular ublock. Its presence shouldn't give you a false sense of security. One thing that is sure to happen is that its capabilities will be gutted in the long run - perhaps by just bypassing the blocks.

You're right - though I don't know about the 'control memory' part. However, the other person is addressing the use-case of 'network automation', not of microcontrollers. There it really doesn't matter what the exact memory layout is, or if GC stops your job for a microsecond. Go is sufficient for that. Go is sufficient even for many web backends and network infrastructure. In fact, much of kubernetes is written in Go.

I use Rust for where one would normally use a shell script. But I have been using it for nearly a decade now (yes, I started before it reached 1.0). I have gotten used to the strict type system and even rely on it to write proper code. I also have a background in hardware - so much of it makes sense to me. Even so, I can't recommend Rust to a beginner who values productivity. Rust takes a lot of time getting used to. And no matter how you try, you will never be as fast as you are with python or go. It's not always bad considering what you get in return for the sacrifice. But it's better to set your expectations straight.