Do you really think it's all just tweets and ads? Spoiler art: it's much, much, much more than that. Massive analytics stack, tons of distributed computing needs, lots of well-maintained OSS projects (Mesos, Aurora, Finagle, Pants, Bootstrap, Zipkin). I could name about 20 other things. The headcount may be a bit excessive but this is a caricature.
Those 4,100 people are not just facebooking all day. The question isn't whether they produced anything - it's whether it is actually needed to run twitter. And personally, I believe the answer is "not really".
As an example, they could have gone with Zurb Foundation instead of doing Bootstrap. They could have used (redo, cmake, tup, a hundred of other tools) instead of doing Pants.
If Twitter was non-profit, their breadth of products would have been awesome. But it's for-profit, and most of these projects are negative on the P&L summary, even if you favourably take into account intangibles like "help in recruiting people" and "coolness of brand".
I have to jump in and side with the grandparent. Despite everything you just mentioned, if it isn't about "tweets and ads" I would contest that it is exactly about them. Do whatever you want back-end, but that doesn't matter if my front-end experience is not so great. For example, they are terrible with spam bots. I mean when super-model-quality photos suddenly follow me, and the bot is posting shortened URLs, it makes me feel like they aren't on the ball at all.
Well sure. I don't think many people think all those people were sitting around twiddling their thumbs all day, but none of those open source projects ultimately benefit Twitter. If those had been OS api clients it would seem prudent (except twitter doesn't like third party integrations any longer).
For many businesses, that might be 2 or 3 too many.
Also, that was just an example I pulled out of the air. It could be middle management, or a documentation expert whose role is regulating font size. The point is that for a company with a simple product, an API and clients for that API, and monetization through advertising, that's a lot of employees. If the money's not there, cut the fat.
Am I the only one that doesn't see the value of assessing this at the state level? Given the drastic variability of rents within states, this seems like a useless (not to mention misleading) unit of analysis.
Even worse, this kind of sensationalism around rising rents seems to be bringing the rent control zombie back to life in a number of cities. What a disaster that would be.
So it looks like the conflict resolution strategies being recommended are "pick one arbitrarily", or in an advanced section, "keep the longer list"?
Not that it matters to me anymore, but it does sound like having all data in CRDTs is the only way to pass Jepsen. (Or to have your data be immutable, in which case Jepsen doesn't apply.)
Only three rust benchmarks use unsafe code, in one of them it's virtually mandatory, and in another it's just one line. On a side note, rust compiler enforces naming conventions, which is kind of cute.
The reverse complement program certainly doesn't need unsafe code, but the safe rust version[1] takes 3x the execution time of the unsafe rust version[2]. By comparison the fastest Go version[3] is fairly idiomatic Go without unsafe memory management and takes just 2x the time of the unsafe rust version.
Also, which benchmark did you have in mind when you said unsafe code is mandatory?
These are REALLY BAD examples, the safe rust version isn't parallelized but the two others are. The unsafe version is just translated C as people already stated. A safe version these days (heading towards 1.0) shouldn't be far of the unsafe versions.
That specific safe version, which, IIRC, was a basic translation of the fastest C version. I'd guess that there's other safe variations that are more idiomatic and much faster.
May be a faster safe version should be contributed. The current state is that unsafe rust takes half as much time as a safe go program in this benchmark. That is not very interesting because the benefits offered by rust are being given up to perform better, for a problem that doesn't really need unsafe memory access.
Same is the case with spectral norm. It is unsafe rust beating safe go there too.
Small, widely-verified blocks of unsafe code should be the norm if unsafe code is necessary. This does not mean "if you're using unsafe you've failed!"
I was originally thinking of the ship class and had never heard of Panamax the power conditioner. However at the end of http://www.panamax.com/PDF/Datasheets/M5400EX_L550A.pdf it states that Panamax is their registered trademark.
CRDTs in Riak are different from normal KV operations because you don't have to fetch CRDTs to modify them. Instead, you tell Riak which operations should be performed on them, such as adding a field to a map as you mention. Each data type had its own set of operations. Counters can be either incremented or decremented, you can add or remove elements to/from a set, and so on.
