Microsoft's APIs have traditionally been poorly written, bizarre, late, often built specifically to force vendor lock-in, and seem even now to appear and disappear depending on which group inside Microsoft is favored today.
C# is not a terrible language, but against its direct competitors in the 'safe boring garbage collected enterprise algol VM language' space, it loses on non-Windows platforms to the far-better-supported, much-faster, and much-better-tooled Java, where none of those API problems exist and the platform is, even under Oracle, moderately open.
at first I thought this was a humorous documentary about the sorts of dumb questions that novice interviewers use to make themselves look smart. But I fear after looking at it for a while that it's intended to be serious.
'falsy'...really? Unless you're interviewing for a language implementor, that's pretty ridiculous. That's an inside baseball question that bears no relation to actual ruby programming.
Amazon clearly needs a change in management at the head of AWS. The engineers are either petrified of telling the truth (very, very bad) or incompetent (less bad but still bad). And it has been this way for an unreasonably long time.
if it doesn't make sense to you, and you suggest using triggers (!) and mongodb map reduce (!) to get stats, then you are probably working at very small scale. There are a number of problems at small-medium to large scale, at which your mentioned solutions trivially fall apart. That's when you start using tools like Redis -- as scalpels to fix general-case solutions.
when you are asked if you've ever been involved in a lawsuit, the reasonable assumption that the person is interested in knowing of your involvement in lawsuits, not if you are capable of picking and choosing a single lawsuit and describing it. Reading it any other way is so ridiculous that you have to be kidding.
would you expect someone who writes articles about DBMSes, or comments in a thread about them, to understand that memory mapped file size is (a) not necessarily limited to address space and (b) 64 bit on 90% of the installations of even 32-bit mongo db?
it introduces a lock in your code, because that is what you want -- you want the string to be built by one thread only. Why the strange comments about 'yet another lock' and the synchronized methods being 'useless' or 'redondant' (sic)?
per their submission history, OP has also attempted to generate buzz here by posting over and over:
How the Galaxy In-Memory Data Grid Handles Networking
How the Galaxy In-Memory Data Grid Handles Failures
How the Galaxy In-Memory Data Grid Maintains Data Consistency
Parallel Universe open sources a novel in-memory data grid
Redis is a particular product, not a catch-all for low latency in-memory data stores. So saying your product is a Redis (which you did, rather than making an analogy) was merely embarrassing attention grabbing marketing palaver which does discredit to your product and suggests that you don't have the attention to detail and critical thinking skills required to properly implement a product in this space. See: MongoDB.
I don't think you understand Redis. Redis is also a key-value store, but implements a variety of structures, not just RTree, and has a large number of operations on those data structures (http://redis.io).
Spacebase appears to be a significantly more primitive KV store that implements RTree. Not that that's bad; looks interesting, even though it appears that the product won't be free, and so in my opinion is probably doomed.
Using 'Redis' in the title is just embarrassing for Spacebase and, by extension, for YC too. No need to troll the professional developer community with ridiculous comparisons.
Product appears to have nothing to do with Redis and isn't even remotely compatible. Marketer uses buzzword to attempt to get credibility and hence immediately loses all credibility with actual market.
The good thing about the AppStore password timing out after 15 minutes is that you can hand your child the ipad/iphone/etc. and not get a surprise $5,000 itunes bill.
Maybe it's just me, but I find the e-paper Kindles to be absolutely terrible reading experiences. The text is still relatively low contrast, but the real deal killer is the refresh flash. It's jarring and disruptive and it is nothing like a page turn.
Reading between the lines from both the posted note and their persistent failure to provide correct statuses: the ops guys over there are in full CYA desperation mode somewhere around 100% of the time, and a culture of 'it wasn't me', fuelled either by job fear, or promotion fear, or fear of being noticed by bezos, is in full bloom.
I would say there's a difference. PHP is bad because it has a wide variety of objectively awful design flaws, its standard library is a conflicted mess, and it's unperformant. Implementing it into a modern architecture is highly correlated with sloppiness and technical debt.
ORM is bad because the impedance mismatch between an object and a relational model is very difficult to get right.
Frequently, for example, one iterates over collections of objects in the OO paradigm. A naively written ORM, or one without sufficient introspection into the loop intent, can translate that into N select statements, each incurring a network round trip.
The end result is that OO programmers have to understand not only their object code, but also the relational model, and finally too the ORM's peculiarities and suboptimalities. So in attempting to solve one problem, most of the time you end up with three.
That said, there is a sweet spot in ORMs for simple code (e.g. most web apps, where ActiveRecord and Sequel and the like are fine). But there's no sweet spot for PHP code. Every line written is technical debt.
I wonder what Microsoft's hardware partners think of all this. It's not just competition, they actively disparaged the others by saying that it was as powerful as all the ultrabooks out there.
C# is not a terrible language, but against its direct competitors in the 'safe boring garbage collected enterprise algol VM language' space, it loses on non-Windows platforms to the far-better-supported, much-faster, and much-better-tooled Java, where none of those API problems exist and the platform is, even under Oracle, moderately open.