I did this systematically: at the first sign of outlier in performance one system would move itself to another platform and shut itself down. The shutdown meant turn all services off and let someone log in to investigate and rearrange it again. This system allowed different roles to be assigned to different platform. The platform was bare metal or bhyve vm. It worked perfect.
RIRs don't prohibit out-of-region use of IP addresses or ASNs registered in their region. The country an IP is registered in is not necessarily the country it's being used in.
ASN is even worse, honestly. If I'm behind starlinks AS then I'm American? AWS, I'm also American? Level 3? American. Colt leased line in my office in Madrid, apparently I'm English.
How does a company define or at least describe company culture and displays it up front? I am genuinely curious, and not trying to start any sort of flame wars.
> Carbon exists so that it's possible to migrate a large C++ code base, like Chrome, from C++ to something saner, incrementally.
_Incrementally_: a C++ project can be incrementally made more sane also using constructs to avoid and constructs to use once the problem domain is confined. In my past, I had successfully implemented this quest for 3 different fairly large C++ projects. This is not a strong selling point for carbon.
i always emphasize to new programmers to learn any language and practice it with respect and discipline. All languages have dark corners, the human who can reason which constructs are appropriate.
Once you've done this work though, what stops the codebase from slowly drifting back into the less sane realm it previously resided in? It seems pretty reasonable to be concerned that a company that produced a messy codebase once is capable of making it messy again, and given that turnover is inevitable in the long term (which is the timeframe that seems relevant given that long-term compatibility in C++ codebases is kind of the whole reason this discussion is happening), it doesn't seem like relying on an individual to enforce the rules is super viable. The obvious way to enforce this sort of thing is through tooling, and there's no tool more powerful than literally making it impossible to express the undesirable code in the language itself in the first place.
You're right that incrementally rewriting isn't much of an advantage over C++ itself, but I think you're missing the point that the emphasis on "incremental" is to highlight the advantage in rewriting C++ code in Carbon over alternatives that don't provide as much compatibility (with Rust being somewhat notorious for being suggested by outside parties as a target for rewriting in whenever discussions about C++ codebases happen). The argument for Carbon over C++ isn't specifically that it can be rewritten incrementally, but that it's just a better language, which has benefits _after_ the rewrite. To be clear, I'm sure that someone could come up with reasonable objections to that claim as well, but I think it's distinct from the part you're objecting to, and it's worth treating as a separate concern.
perceptrons, memory-in-a-box, back-propagation (even though it's computation expensive), Long-term-short-term memory, Support Vector Machines and other Neural Networks.
In the book "Artificial Intelligence A Modern Approach" by Stuart Russell and Peter Norviq, you may find more gems.
