I disagree - Perl's biggest issue is that things which should be defined in the language's grammar are instead defined in code. This reduces it to a language of special cases.

Consider the following:

$_ = foo 1;
bar;
print;

Does the function bar, in the absence of an argument, use $_ as its argument?
Some functions do, some don't, and this is true even among the core functions. This is because the implementer of the function must explicitly read from the global $_, rather than the language passing the argument to it. The resulting inconsistency can make it difficult to reason about what a Perl script is actually doing.

There are other issues, such as variables inside functions being global by default, but that's the big one.

I suggest you look at using D instead. It is as powerful and efficient as C++, syntactically very similar to C#, and can link C++ libraries.
The main benefit this provides (apart from performance) is that it will be much easier to do a cross-platform release - although C# has Mono, I've found it to be unreliable.
That said, D is somewhat obscure, so caveat emptor.

tldr: good faith = don't be a dick

Disclaimer: IANAL, and I am not particularly familiar with equity law, which (promissory) estoppel falls under.

In contract law, acting in bad faith refers to following the literal wording of the contract while taking actions that would deprive the other party of their benefits. e.g. you lease a car, but do not provide the car key. In some jurisdictions there is an implied duty of good faith in contracts, while in others explicit terms are required.

Now, in this case there is no contract because there is no quid pro quo relationship between Tesla and the licensees (the legal term is consideration). Instead it is enforceable by promissory estoppel, which essentially means Tesla can't sue someone who relied on their statements.

Since Tesla isn't explicitly receiving anything in return for the license, it's unclear what an action in bad faith could deprive them of.
One argument would be that the benefit Tesla accrues from this is that other companies will (hopefully) build infrastructure. It's entirely possible that they may choose to do so using Tesla's patents but with incompatible, DRM'd connectors. I suspect this is what the good faith requirement is intended to prevent. (Non-DRM'd connectors would be more of a grey area, since they could argue that it was used simply because their technology is better.) In other words, the other company would not be permitted to prevent Tesla from supporting their charging stations if they used the patents in question.

Subjectivity cannot be eliminated completely; that is why the reasonable person test is used in law. Most (or possibly all) human languages require some interpretation on the part of the reader, and as a result terms like 'reasonable person' and 'good faith' are used in law to imply that such interpretation is required there.

You jest, but given that ChromeOS is a Gentoo-derivative, it might not be that far off...

I'll second this. I got a paid subscription to them after the picked up a kernel performance regression bug that no one else had noticed. They also regularly do file system benchmarks, which are really useful if you're interested in that.

C# is now 14 years old - I highly doubt it can be considered fly-by-night at this point. Not to mention Swift doesn't even achieve feature parity with it - it lacks C#'s variant generics and list comprehensions (which seem to be combined with lazy evaluation and called LINQ in C#).

My underlying point is, why create a new language? It's justifiable if you're actually trying to add new features or paradigms (e.g. Rust was created so that memory safety could be enforced at compile-time), but otherwise it's just change for the sake of change. It would make more sense to adopt the syntax of an existing language (e.g. Java, C#, C++, etc.) so as to leverage existing users of those languages, rather than requiring them to relearn the semantics. If you need to replace Objective-C, why create a whole new language when there are plenty of perfectly good ones already?

Quite frankly, it looks like a poor man's C#, with some Haskellisms (tuples, -> syntax) thrown in for good measure. I'm sure it's better than Objective C, but it's nowhere near competitive with any of the other recent languages. e.g. Rust*

* I think Rust is a long way from perfect and has a myopic focus on low-level coding where manual memory management matters, but at least they're doing something interesting.

KDE worked fine on 32-bit ARM, last I checked. If they're going through the effort to support a completely different architecture, I'm pretty sure they'll still support 32-bit x86.
Also, I'm not sure that PAE-support should even make a difference to anything running in userspace...

I just tested this with FTP and Audacity, and the files are copied to temporary directories before being opened in non-KDE apps. (Actually, they're copied for both, but to different directories for some reason...)
I'm using Sabayon with KDE 4.13.0 - you're either using an older, buggy version, or there's something wrong with your setup.

I'm not sure about Plasma-next, but I could comfortably run KDE 4.10 (or thereabouts) on a tiny little Tegra 2 clocked at 1 GHz with 1 GB of RAM and no hardware acceleration. Chrome ate more RAM than KDE ever did. I've also used KDE quite comfortable on a Pentium 4.

So if KDE doesn't run on your desktop, then I'll wager one of the following is the case:
-you have horribly broken graphics drivers. Try changing the compositing mode, graphic driver, etc.
-your PC is over a decade old
-you have stumbled across an extremely rare and specific bug in KDE

If you're using 4.13.0 (the first version with baloo), or about to upgrade, here are two things I learnt the hard way:

• When KNotes asks if you want to migrate your notes, say no. The migration process wipes them, and recovering them is non-trivial.
• If you have any virtual machines, make sure you've got limits.conf set to prevent baloo from eating all your RAM

Such is life on the bleeding edge...
But apart from that, Kmail/Kontact works great for me (especially with Kolab).

Most industrial machines are electrical; the kill switch is just a switch. Implementing something similar for an IC engine is probably considerably more complex.

They'd be a bit late.

It sounds more like an approximation. Given a failure rate of p and 2 (non-redundant) engines, the probability of system failure is 1 - (1 - p)^2 = 2*p - p^2. p > p^2, which means we can neglect the squared term, leaving just 2p.
It's not the sort of thing you'd do in a rigorous analysis without formally stating the justification, but it's exactly what I'd expect from a back of the envelope approximation or an informal explanation. Someone with a strong background in probability would probably do this sort of approximation almost subconciously.