Based on the actual voting record, on the most serious issues, she's about on par with the worst president of the modern era. Cruz and Trump would be worse, sure, but not by "a million times", more like 2x.
Four years of letting Republicans remind everyone how terrible they are at governing for a chance to be rid of Clinton for good and take back Congress and the White House in 2020? Maybe worth it.
The person Lessig would theoretically be Nadering, you do realize that as a Senator she voted on the wrong side of all of those bad things you're pointing out, right?
I threw $n at a shot to get an honest, articulate voice on stage at an early-primary-season debate, to hopefully influence the party/eventual candidate's agenda. It didn't work. Oh well.
I have a $500 iPad sitting on my coffee table gathering dust, too, which was the bigger waste?
The actual damages that resulted from his actions were pretty small and purely financial.
Even if you prosecute on the basis of what could have happened (maybe we start charging everyone who runs a red light with manslaughter?), we're still not reaching the level of physical harm to anyone or (barring complete negligence on the part of the Tribune) a catastrophic material loss.
You really think society's need to avenge that wrong is worth spending $30k a year to hold him in federal prison, exposing him to possible violent harm, and depriving him of his future? Sorry, but that's insane. He should pay the actual damages, a punitive fine, and perform community service, tops.
Keys posted active credentials to a forum, and those credentials were used by others to deface a website. Do you regard that as a fair statement of what happened? Still completely insane to send someone to prison for that.
Keys is an asshole, and low-level nonviolent drug offenders absolutely should not be treated as they are.
Both of these things are completely irrelevant to the fact that any jail time for defacing a website is completely insane, the result of a witch-hunt mentality surrounding computer-based crimes.
Do you have any pointers to papers describing how vote auditing techniques extend to liquid democracy? The Google paper doesn't even acknowledge the problem, much less describe a solution, and most of the other papers I've read on the topic are either extremely handwavy on the technical details of privacy or make the same assumption as Google, that its good enough to hide votes from the participants but 'the system' still knows.
I'm a big fan of this general idea but taken to the limit of being able to delegate all issue votes to any person goes too far, and I'd prefer a system that elected representatives who accrue a threshold number of votes. There are a few reasons for this, but I'll just talk about one here, privacy.
Privacy is addressed in the paper but I think the real issues with it are just glossed over. "You get to see how your delegate votes" is great and should absolutely be true, but there are two other sorts of privacy that matter: privacy from the electoral system itself, and privacy from closely related people.
In very Googley fashion, this paper seems to take for granted that of course you'd trust the system itself with the knowledge of your votes and delegates, and that its privacy-respecting duty is fulfilled by simply not broadcasting that knowledge to the unauthorized public. But that's a terrible way to run a government that at least partially relies on a secret ballot as a means of expressing dissent and effecting change in the government itself, for hopefully obvious reasons.
The other form of privacy that matters is on a much smaller scale. A delegate who can exercise the votes of an arbitrarily small number of people is also capable of ensuring they are exercising the votes of a specific set of people. An abusive husband/father/wife/mother/boss/etc can know simply from the count of votes they hold whether their victims are following through on their command, and via transitive delegation they can pool that power with collaborators.
I'm bored of C++ apologists pretending like there's really such a thing as 'modern and idiomatic C++11/14' that any two C++ programmers actually agree on, or that you'd ever actually see practiced consistently in the wild.
You can no-true-Scotsman code that compiles, runs, and blows up in your face with any modern C++ compiler all you want, it doesn't change the fact that Rust eliminates entire classes of errors that are trivial to hit in C++.
In the cases where your application can benefit from parallelizing simple operations over a large data set stored in a collection, `parallel()` is fine.
It's even fine in the case where you're pulling data from a file or other low-latency sequential data source, assuming that the cost of filling a spliterator buffer is less than your cost of processing.
But there's a list of gotchas all more dangerous than the "magic make it faster" button of .parallel() imply:
- For the sequential data source case, if the cost of filling the spliterator buffers is higher than the cost of processing, you're just wasting a ton of overhead trying to use parallel.
- You have to be aware that by default all uses of parallel() run on the same threadpool, which makes it a potential timebomb if someone uses it in the context of, say, a webserver where multiple requests might all individually process streams. This also means blocking operations during stream processing are very dangerous.
- Mutating an external variable goes from being fine for a sequential stream to a race condition for a parallel one.
- You can't hand out Streams that you intend to be executed sequentially, b/c your callers can just call parallel() whenever they want.
And, yes, all of these considerations make the api more complicated than one operating over plain old iterators.
The main reason they build these on Stream rather than Iterable is b/c they wanted to include the `parallel()` method, which works via "spliterators" rather than plain old iterators.
In other words, in order to support a gimmick you can actually use in production in a maybe a handful of use cases, they complicated the api for the use cases you hit 99% of the time. Awesome.
Video cpms can be well over $10, a 40M-view video could easily make a few $100k (though, of course, only a % of that ends up in the creator's pocket). 500k views could be a few thousand. Spread your equipment costs out over a bunch of videos and you're making some nice money.
What do you mean by 'low-level extensions'? There's nothing in the language proper that can't run on bare metal, how much lower can you get?
If anything, it's the functional parts that feel bolted on: closures are crippled (though getting better soonish), the types that get spit out of iterator chains are hideous, no currying, no HKTs, functional data structures are much harder to write w/o a gc, etc.
I wouldn't say "trying to keep breaking changes to a minimum"; breaking changes still happen a lot. More accurate would be that breaking changes are happening less frequently than they were and generally require less effort to accommodate.
I'm only through the introduction right now, but assuming that it's representative of what's coming later, Piketty isn't saying 'r > g' as mathematical fact, he's saying 'when r > g, divergence in the distribution of wealth happens' and 'empirically r has frequently been and is again moving towards > g'. And his concern with this is the same as the problem you state, that r > g implies, eventually, r = g, which translated back to English means economic activity devolves into rent paying.
Quoting:
"When the rate of return on capital significantly exceeds the growth rate of the economy (as it did through much of history until the nineteenth century and as is likely to be the case again in the twenty-first century), then it logically follows that inherited wealth grows faster than output and income... Under such conditions, it is almost inevitable that inherited wealth will dominate wealth amassed from a lifetime's labor"
"Forces of convergence also exist, and in certain countries at certain times, these may prevail, but the forces of divergence can at any point regain the upper hand, as seems to be happening now, at the beginning of the twenty-first century"
"My conclusions are less apocalyptic than those implied by Marx's principle of infinite accumulation and perpetual divergence... In the model I propose, divergence is not perpetual and is only one of several possible future directions for the distribution of wealth"
It's a matter of taste. I personally feel that your specific examples make Rust more readable, because of how little space gets wasted on those frequent, unambiguous names. Ubiquitous boilerplete-ish things that show up everywhere should recede a bit, imo; let me spend my line width budget on what's unique and important about my code.
But again, it's just a matter of taste and not really worth wasting a lot of time worrying about. The important thing about Rust is its semantics (speed, safety, control), not its syntax.
Him switching from being neck-deep in compiler issues to actually using the language in anger on whatever it is he's doing now might end up being really good for the language. His twitter stream has started filling up with wtf's and really good bug reports.
Yes, it's just bindings to open-ssl. Yes, it's probably a little clunky to use. But we just went from "a decade or so before you can do anything networking related" to "ssl takes more than 3 lines". I can live with that.