There's always ReactOS[1], a project for a bug-for-bug compatible Windows clone. It used to mostly aim at Windows 9x compatibility the last time I'd checked, though, but that could probably change. And if anyone wants to create a Win7 clone, at least some of the groundwork has already been made.
Thank you, rsc, for all your work. Development in Go has become much more enjoyable in these 12 years: race detector, standardized error wrapping, modules, generics, toolchain updates, and so on. And while there are still things to be desired (sum types, better enum/range types, immutability, and non-nilness in my personal wishlist), Go is still the most enjoyable ecosystem I've ever developed in.
> While the compiled programs stayed the same, we no longer get a warning (even with -Wall), even though both compilers can easily work out statically (e.g. via constant folding) that a division by zero occurs [4].
Are there any reasons why that is so? Do compilers not reuse the information they gather during compilation for diagnostics? Or is it a deliberate decision?
That could be true, but I've done a few optimizations of allocations in Go code, and I don't recall pointers to stack values ever being optimized (unless the entire branch is removed, of course). If anyone could provide an example of the code that does pointer operations yet doesn't cause allocations, I'd appreciate it!
The first line here is the allocation, since (at least, the way I recall the rule) in Go pointers never point to values on the stack, so concreteTypeValue must be allocated on the heap. The rule about pointers not pointing to the stack is there to make it easier for goroutine stacks to grow dynamically.
To be fair, if that's what you need ProtoBuf isn't the only option. Cap'n Proto[1], JSON Schema[2], or any other well supported message-definition language could probably achieve that as well, each with their own positives and negatives.
Privilege separation[1], most likely. If your system needs to do three things, it could either just do all of them using a single executable requiring all three permissions (thus also theoretically allowing an attacker to use it to do all three things as well) or split your system into three executables, each only having the permission to do one thing (thus reducing the amount of potential damage).
This makes me thing of the stories I've heard stories from those who lived in communal apartments back in the U.S.S.R. days. Couples who had a creaking bed and wanted to go at it at night would just do it on the floor instead of on the bed. Which in turn makes me think if those beds are just some kind of kickback scheme, because I can't be the only one who thinks of suck obvious solution, can I?
On a related note, have there ever been extensions for PosgreSQL/SQLite/any other FOSS DBMS that would allow using Tutorial D[1] (the Third-Manifesto one, not to be confused with Walter Bright's D language) to define and query data? In particular, I feel like PostgreSQL's CREATE TYPE[2] feature would allow for easier bridging between SQL and Tutorial D.
Unfortunately, searches for “PostgreSQL Tutorial D” don't issue useful results for obvious reasons.