tupshin

Citation would be nice. This article talks about them having rebounded after near extinction:

http://news.cornell.edu/stories/2015/08/some-honeybee-coloni...

Recipe:

Create a global Cassandra cluster with regional datacenters.

Use one keyspace per region

Use per-keyspace replication to only replicate that region's data locally, and to one or more additional datacenters

Have stateless app servers colocated with Cassandra in each DC handling all local traffic

Run spark on top of Cassandra to do analytics, or to do the etl to a dedicated analytics system

Optionally have a single "master" DC, with replicas of all data from all locations, that doesn't serve end user traffic, but is to allow efficient cross region analytics.

Profit (optional step)

And yes, the company I work for (Datastax) has a product and services to help make it simple.

Having just acquired a pixel c tablet, I am increasingly looking forward to being able to iterate on my rust projects while being highly mobile. I don't see it as a primary development platform in the near future, but absolutely invaluable as an auxiliary one.

You are precisely right, and people with a devops mindset are most of the people that are building the cloud platforms that will render the role largely obsolete.

A typical developer just wants to code against an api, and shouldn't have to care about the infrastructure. As cloud providers (both public and private) move up the stack from providing just virtualized machines (ec2) to higher level services (dynamodb) to more complete frameworks (lambda), the developer cares less and less about what runs underneath that.

Devops does indeed sow the seeds of its own destruction. :)

Definitely not

Thankfully it's on a long slow slide to oblivion. https://www.google.com/trends/explore#q=php&cmpt=q&tz=

This works only so long as the receiving side is able to retain all messages (or message ids if those are guaranteed to uniquely reference a given payload). It does not work for outages of unbounded (or otherwise impractical) data size or duration.

If this were not happening in main(), then the following would be one way of handling the errors.

  fn foo() -> Result<(),Error> {
      // Create an event loop
      let mut event_loop = try!(EventLoop::<(), u64>::new());
      let sender = event_loop.channel();
      for i in 0.. 5 {
          try!(sender.send(i));
      }
      // Start it
      try!(event_loop.run(&mut BearHandler(0));
  }

Trollish troll is trolling.

Rust has a myriad of ways to handle errors, and unwrap is the most blunt of those instruments as it explicitly converts handleable errors into panics.

Alternatives such as try!, unwrap_or(), and many others, should be your preferred options. I try to only use unwrap() in throwaway code and usually only in main functions.

The one thing rust doesn't let you do (at least without warnings), is to have unhandled errors.

Being forced to explicitly handle error conditions is a huge net win for any production code.

The global banking system has always been eventually consistent (overnight reconciliation, etc). Eventual consistency is essential whenever communication latency exceeds the acceptable time to receive acknowledgement that an operation was performed.

The limiting factor used to be the speed of a horse, though now it is some approximation of the speed of light.

Which is basically just using the weak anthropic principle as a convenient excuse for a lack of verifiability.

If only rust had (optional only, please) fall through on matches, then you could skip a whole line :D

There are numerous users of the paxos/lwt feature of Cassandra to selectively guarantee immediate/strong consistency for operations that need it (some at very large scale). But I'm not aware of anybody using this type of lease mechanism on top of Cassandra in production yet. I'm guessing this will be changing soon, as it has a lot of potential for infrastructure and application simplification. If you are interested, I'm happy to discuss further. Feel free to ping me on twitter, or email me at DataStax.

Cassandra's CQL is an SQL variant/subset (albeit without joins, which don't scale out horizontally anyway) that is adapted to variable partitions with rows grouped into partitions. It addresses the problem of locality by embedding partition awareness into the query language.

1) Buy a box with 1TB of RAM. Very doable these days, albeit a bit pricey still

2) Scale out. Spark can easily handle hundreds of nodes in a single cluster. Aggregate RAM across all of them can be used.

3) Cache intermediate data sets and/or hot data sets, as opposed to the entire data set.

Spark doesn't depend on much of anything from the Hadoop ecosystem, including HDFS. It supports S3, as well as NFS or any other locally mountable filesystem right out of the box. The FAQ talks a bunch about Spark's weak ties to Hadoop. http://spark.apache.org/faq.html

Datastax is committed to a highly distributed workforce, and is hiring like crazy. Almost all of our engineering positions are "anywhere".

http://www.datastax.com/company/careers

(Most of the engineering jobs represent multiple openings)

Projects like Apache Spark have demonstrated the power of a more complex DAG (Directed Acyclic Graph) approach that allows for more precise control over the data-processing flow, compared with the simpler execution model of M/R. All of the major Hadoop vendors are pivoting, and simultaneously adding support for Spark (which can work with the Hadoop stack, but is not part of it), while also supporting the development of one or more technologies that are trying to retrofit Hadoop into a more powerful model, such as Tez, from Hortonworks.

Looks interesting but very similar in concept to Mongrel2 built on top of zeromq.