> Work somewhere else.
You could equally say to any workers at Tesla who want to establish a union. Work somewhere else.
8,739 karma · joined May 26, 2010
> Work somewhere else.
You could equally say to any workers at Tesla who want to establish a union. Work somewhere else.
You seem to be replying as though I’m saying he’s not wealthy? Obviously he’s extremely wealthy by any definition. But most ultra-wealthy people are a LOT more diversified in their portfolio than Musk is. Someone with a diverse portfolio stands more chance of being able to functionally realise their wealth—if, say, they wanted to donate a large chunk of it to some charitable cause.
An argument could be made that Buffet is far and away the richest person (in terms of realisable wealth) due to his highly diverse holdings.
Also, is there any evidence that collective action returns a sustainably larger slice of corporate revenues?
The M1 Air is a bit bigger, but that two centimetres of width does go to good use with a bigger screen (with more pixels), a bigger trackpad, and a bigger battery.
I have no problem when a language allows the programmer to explicitly opt for a variable to be an undefined/dynamic type, whether as part of generics or as part of a defensive ingest of untrusted data. I admit this is previously unspecified nuance but in my mind this doesn't break my rule: "this variable is always going to be a dynamic type, never not a dynamic type." This means you know when to interact with it defensively.
The thing I'd like in a hybrid static-dynamic language is type assertion blocks which restore some benefits of static typing while dealing with dynamic typed variables. E.g.:
declare x as dynamic;
x = untrusted_source();
if (x IS_A string) {
// Inside here, x behaves as a statically typed string.
// The compiler knows it and checks types appropriately.
// Passing x elsewhere will send a static typed string.
function_that_demands_a_string(x);
}
else if (x CAN_SAFELY_BECOME_A uint) {
// True for any non-negative integer regardless of data type.
// Inside here, x is always a statically typed uint.
// If it was some other type, it was converted for me.
}
(This probably already exists in some language somewhere but my familiarity with languages is narrow.)Perhaps Docker could learn from this and only auto-update to versions which have been used by a large audience for N weeks with no regression reports.
The only exception to this is untrusted input, but for that an string is usually always fine.
I’ve no doubt that Tesla can make it score well on crash tests though. Crumple zones don’t have to involve literal crumpling of a metal body—it could be achieved with other forms of deformation.
Also, you overestimate the complexity of installing charging points. In many cases the parking will be directly against the post office building. In many cases you would only have to dig a small trench. In some cases you would string up a new overhead wire. When you’re doing 10 at a time, this isn’t complicated or expensive on a per vehicle basis.
Heck, we haven't even transitioned 100.000% away from horses yet.
There will be one factory pumping out cars on a specialised, serial production line. It will be competing with 30 thousand locations operating in parallel.
Also it’s unlikely to have been upper deck gray water. More likely it was condensate.
When speaking in relative terms to a newly built fossil fuel plant you are most likely correct. You'd be hard pressed to find a plausible source of energy that's worse for the environment (immediate AND long term) than burning dirty sequestered carbon sources like coal and oil.
When speaking in relative terms to a newly built nuclear plant—the context of my response—batteries would be significantly worse per KWh of baseload energy supplied.