Make sure you read the article since it doesn't look like they're doing that at all. The sentence you cited is pretty tricky to parse so your reaction is understandable.
I was employee six and didn't know (though I did know there was a history to Heap before it joined YC and there was another cofounder, I just never knew/didn't dig into who)
3. Because this derived from a previous enterprise SaaS app, our infosec policies are nicely buttoned up. Going through the fun of SOC2 now :)
4. It's coming! The first thing we're building is a relay so you can use Slack to talk to customers in Teams. Down the road, we'll consider building the same inbox functionality native to Teams, but we're waiting to see demand first.
5. Yes this works! You can even treat your team members as customers for internal ticketing systems (like IT or HR requests).
Did you look at any alternative graph layout algorithms? There are non-quadratic ones that are quite good (like Barnes-Hut and its variants). I did a Typescript port of ForceAtlas2 a couple years ago that could run on a Web Worker (so as to not block the interactivity of the graph) but never got around to open sourcing it.
I'd be amazed to see what this level of profiling skill could do on a fancier algorithm.
This isn't really accurate. VCs would much rather get paid 20+% carry than 2% management fees (and raising a follow-on fund would be quite difficult if you failed to make returns and publicly blew most of your fund on a boondoggle like Magic Leap).
Will let the parent reply but at a high level (at least for comprehensive insurance) there is a) a fairly competitive market (and comparison shopping is possible) for car repairs and b) a limit to the cost of a repair (the value of a new comparable car) that we don't / won't place on human lives.
No but I'll certainly pass the word along. I handle the network and wasn't directly responsible for evaluating AMD. I just heard the reasons why it didn't work and saw the not-so-impressive benchmarks when looking at single core performance. This was 2-3 years ago.
I spent _so_ many hours as a kid on RetroMUD. Nothing else will improve your typing and console scanning skills like being a healer during a massive boss fight.
Retromud is the only MUD I've ever played as well. Started in 2001 or 2002 and every once in a while will go through phases where I play again.
If you aren't that into Role Playing, and you prefer team based PvE combat, I think Retromud is the one to check out. 20 primary guilds (classes) and 80+ races, as well as branching paths from each of the primary guilds makes for huge number of possibilities for your character. Though to start out I'd suggest a Dragonian Fallen.
Good question! You probably are familiar with the bandwidth and throughput power of the underlying storage system of GCS, Colossus, through use of BigQuery. BigQuery Storage and GCS storage both leverage Colossus. It's silly fast :)
Others can chime in more intelligently wrt Spark/Hadoop specifically, but I'll point out that read latency from GCS would definitely be higher than local-disk HDFS (esp Local SSD). Throughput, depending on your configuration, could be much better with GCS. Spark/Hadoop don't take the same care to optimize the storage-to-compute route as BigQuery, as evident by some bits of Hive performing serial FS operations.
So my answer is, it depends on the configuration of the job, the cluster, how data is written, choice of disk, and et cetera.
That said, when talking about price-performance, flexibility, scalability, and ease of operations, I suspect the "job-scoped clusters" setup would have a far superior TCO. We should try and do the math one day :)
For most use cases, GCS is going to give you better performance than using PD. GCS removes some headaches, like replication. In so doing, when you read from GCS you can often read from a large number of places in parallel; you're also less likely to run into bottlenecks because the VMs have pretty freaking amazing network bandwidth.
To be fair, there are some exceptions:
1: Small files (several KB to maybe 1MB)
2: Many reads
With GCS, you pay the tax for network overhead + SSL, which means reads are slower and scanning tons of small files can also be less performant.
For Cloud Dataproc, we also do provision HDFS on PD for intermediate output, because it's usually more cost effective than trying to do everything in GCS (which you can do, but you're going to pay for class A ops, and we want to save people money.)
To go into another level of detail, GCS also used to lack immediate list after write consistency. Now that GCS has been changing to support it, you also get a good story on clusters hitting the same bucket without hacks (in our case we used an NFS cache on the cluster.)
Dennis Huo, the tech lead manager for Dataproc also gave a pretty good talk covering some of this at Google Cloud Next [1]. I also gave a talk w/ Michael Yu on the GCS team [2] talking about a change we're in the process of making - swapping out the Java SSL provider with one from Conscrypt which nets about a 2x improvement in reads, making a great thing even better. :)
