The reality is that it's much easier to bring a lawsuit over damage done to shareholders (dropped stock value is measurable and easy to see, security fraud), than it is to bring a lawsuit over damage done to users (harm done to individual users is hard to measure).
It's a real shame damage to privacy isn't acknowledged as self-evident.
Of the 87 million or so individuals who were impacted[1], only 270,000 gave their consent[2]:
The first step for those filling out the questionnaire was to grant access to their Facebook profiles. Once they did, an app then harvested their data and that of their friends."
All of this could've been prevented if Go just had two ways to compile. Debug and release.
The go devs decided against this since they didn't want to build a highly optimizing (read: slow) compiler, but that is missing the point of developer ergonomics.
It could be prevented in an even simpler way: emitting warnings.
Most people nowadays ban building with warnings in CI and allow them during local development. But “CI” was barely a thing when go was developed so they just banned them completely. And now they are probably too stubborn to change.
As an outsider to Go, it feels to me like this basic pattern comes up over and over again in Go:
Q. Why can’t I have feature X?
A. We thought of that already, and your opinion is wrong.
Q. But basically every other language in existence supports this. And it makes development easier. We would really, really like it. Please?
A. Apparently you don’t get it. Here’s a pointer to a 15 year-old post on a mailing list where the first time someone asked for this, we said no. Your opinion is wrong.
> These new C4A instances are advertised as offering up to 50% better performance and up to 60% better energy efficiency than their current generation x86 instance types.
Hardware (see also, Google's TPUs and their performance vs. energy cost) is one reason why I'm fairly bullish on Google.
These are Neoverse-V2 based...same as NVIDIA Grace and AWS Graviton4. Also note they are comparing 48 cores in the C4A, to 24 cores and 24 hyperthreads in the Xeon C4 (Emerald Lake). So single threaded tasks will be somewhat worse than C4, but once the number of threads are significantly greater than the number of cores in C4, C4A will be better.
Intel and AMD are coming out with new server processors with 128/144/192/288 cores in a chip, which can easily put them back on top again.
Hardware companies have yearly releases and work closely with their customers. None of this describes google and it's the reason why nvidia is a trillion dollar company despite Google TPUs existing prior. Basically no one outside of Google uses Google hardware. If it's a generic arm target someone might use it because it's low effort, but it's not exactly a value add.
Do we really need more syntactic sugar? Frankly, I am still confused why Python is going for a separate syntax for if expressions instead of just making its regular ifs into expressions
There is an advantage of having this as syntax, which is a difference in semantics, which you couldn't get if this would just be an expression, namely:
x = func1() if something else func2()
In this example, only func1() or func2() is being called, but not both.
Other languages do this sort of thing, so certainly it "would work". But it's very much counter to the design and aesthetics of Python.
Python is intended to enforce a strong distinction between statements and expressions (`:=` notwithstanding :/) because it sidesteps a lot of questions that one might otherwise ask about how it's intended to be parsed (including by humans).
Being able to write something like your example makes it harder to figure out where the end is, figure out what happens if there's more than one statement inside an `if` (do we only consider the result of the last expression? What if the last thing isn't an expression?), etc. By the time you get to the end of understanding what's happening inside the block, you can lose the context that the result is being assigned to `x`.
At the other extreme, everything is an expression, and you have Lisp with funky syntax. But Python holds that this syntactic structure is important for understanding the code. I sense that this is part of what "Flat is better than nested" is intended to mean.
It's way to late to fix the "statement vs expression" bug in Python's design.
We could have done that in the v3 switch, but we decided to spend man-centuries of effort on chasing already deprecated legacy Windows Unicode semantics instead.
Afaik specialisation (in full generality) would cause soundness issues, so it's not even just blocked by the trait solver, it's also blocked by figuring out a 'slimmed down' proposal that fixes those.
And that's not even getting into the problem that it's a fairly controversial feature, since people are worried about terrible, hard to track specialisation trees. (See, inheritance.)
> Afaik specialisation (in full generality) would cause soundness issues, so it's not even just blocked by the trait solver, it's also blocked by figuring out a 'slimmed down' proposal that fixes those.
There is already a proposal for how to prevent unsound specializations [0], but it requires a lot of support from the trait solver, hence why I said it's blocked on it.
I don't think civilians regularly carry military-grade pagers.
And fwiw, I heard of two tragic cases of children dying, which sounds remarkably low to me so far. If this were truly indiscriminate, this number would be significantly higher and we would've heard of it by now.
Apart from the issue where this ignores how many people got injured (a much larger number), there's a very simple "survival bias" reason (ironically) why this argument doesn't work.
Children (and potentially health workers, as opposed to men of fighting age) are much more likely to die of such an explosion than men of fighting age. In other words, children will be significantly overrepresented here.
To just back up for a moment, your argument is that an attack that turned enemy combatants into unwitting suicide bombers in civilian areas with children doesn't qualify as terrorism, because children are easy to kill?
Would you hold this opinion if it was an operation by Taliban fighters on US soldiers at home on leave?
1. Hezbollah only mourned 10 out of the 26 killed so far, claiming them as members (one of them being a medic). So the 50% seems to still hold, even leaving some room for malice and mistakes.
2. Most of the explosion incidents and injuries are coming from residential areas in Beirut so statistically the percentage of civilians injured as "collateral damage" is likely high considering many of those carrying these devices were going about their life, either with family or in public places at the time.
My opinion of Israel inclines me to distrust reporting based on its claims, and believe your statements. But I still would require a source for these claims, if you would kindly provide them.
