> Informing everyone, right down to the janitors (and all respect to janitors) where we are going and why.

But it isn’t a coincidence that you chose to single out the janitors as those who are “down”.

> Unfortunately, even now, it seems that there is a lot catching up to BK still to be done. To be fair, we had kernel level programmers working on it, we don't think anyone will pick up our code, you pretty much have to be a top 1-2% programmer to work on it, it's all in very disciplined C, people don't seem to like that any more.

Oh my oh my.

Believe me, I would do backflips if someone wanted the BK source base, it's got almost 2 decades of my work in it, north of 140 man years. It's a lot to just let fade away.

But I assembled a team of people better and smarter than me, I did my best to keep the code simple but I didn't always succeed.

If you, or anyone, wants to pick it up, I'm happy to answer questions.

Will take a look at it.

At this point, the trick to creating a sizable git alternative I think is to Trojan horse coding into a new realm with “no-code” like apps.

One of my favorites is Fossil by Richard Hipp. I wonder what your thoughts on it are. I think it is RCS, but usability wise I think it’s way ahead of git.

I just recently learned C and I really like the coding style Hipp uses as well. :)

Richard is awesome. He also did sqlite. As for Fossil, I'm a fan of his UI and code, but haven't looked in detail at the design. I'm pretty sure it is patch based with everything stored in sqlite. It's an OK way of doing things but not if you understand a weave.

But no disrespect intended towards Richard, I've met him plenty of times and enjoyed it each time. Great guy.

Write once, install JVM everywhere.

We should just retire sociology. It’s all just human nature, and what that means is just obvious to everybody.

Presumably people agree that we should “retire sociology” considering that I was being sarcastic.

16GBs of memory isn’t enough for me anymore.[1] Although that is mostly due to Intellij and the Web at large (my browser).

[1]https://news.ycombinator.com/item?id=26120743

All the layers that I see Rust and Zig are introducing have to do with the compiler. And if advanced compilation is a “layer” then Mr. zero-cost-abstractions C++ shouldn’t throw stones.

> Frankly, if you were to boil down the "unsafe" C vulnerabilities it is a small class of exploits, suitable for automated detection.

Ah, it’s simple, then. We will await eagerly for the non-forthcoming links to all those efforts/implementations.

Or would you like to walk that back to “in principle suitable for automated detection”?

It is certainly not simple, and while there's a limit to what languages can do to assist correctness, C sets a particularly low bar, one that newer low-level languages like Zig and Rust can and do improve upon. Having said that, eliminating memory errors from C is not only doable in principle, but used in practice, so far more than new low-level languages (see, e.g. https://trust-in-soft.com/). It does take a fair deal of work, but for established codebases, the approach is cheaper, less risky and better established than new languages.

This comment is as low-effort as the hypothetical examples.

Will they do things in that way? Heck, let’s just ask: are they doing things in those ways?

crickets

Just meaningless rhetoric (“being done fast and/or cheaply”) and unfounded hypotheticals.

I don’t get why this is off by default for debug builds though. Maybe that’s a separate concern.

In my experience enabling the backtrace is necessary in very few cases. I've defined a bash alias to save me a little typing in those situations. As it can be turned on persistently by setting a single environment variable I'd say it's a good middle ground.