iamaleksey

Except they are. Catalogued as δ-CRDT, under Lexicographic Counter in https://arxiv.org/pdf/1603.01529.pdf

edit: Although to be fair that blog post is ancient and covers Cassandra 2.0, now no longer supported. Counters were rewritten in Cassandra 2.1.

CQL is compatible with Thrift-created column families (the inverse is not true, though). Just do a DESCRIBE SCHEMA from cqlsh and see how CQL interprets a particular Thrift-created column family, then use regular INSERTs.

This is not true. See this for example: http://www.datastax.com/dev/blog/thrift-to-cql3

You can do CREATE TABLE schemaless (id blob, name blob, value blob, PRIMARY KEY (id, name)) WITH COMPACT STORAGE; and have a 'schemaless' table, essenitally, just as with Thrift.

This is not a workaround either - this is first-class supported, just as you can read/write from/to 'schemaless' thrift columnfamilies using CQL.

> Cassandra is really awesome at writes but reads are really expensive

This is getting old, and is just plain untrue. Reads are more expensive than the extremely cheap writes, but they really aren't expensive.

> Atomicity at the row level only

Partition level, really, in modern terminology (apologies if that's what you meant).

No batching here, just single-partition, two cell update. Atomic, but not isolated in the way you define isolation in your gist.

The difference is that all the cells with the same `id` would belong to the same partition and stored together, so you'd be able to write them atomically and read them together cheaply in a single operation.

What marshray suggested would look like this:

create table bucket.users (name text, field text, value text, primary key ((name, field))); - with a composite partition key. Then you'd have two separate single-cell partitions "jbellis:email" : "jbellis@example.com" and "jbellis:phone" : "555-5555". You don't want to do that in either Riak or Cassandra.

It's not how Riak does this, and it's not what's going on under the hood with Cassandra, either.

In case you are talking about Cassandra collections (maps and sets), and not abstract maps/sets, then you are wrong. Only CQL3 Lists work like that - there are no UUIDs anywhere in CQL3 maps/sets implementations.

Performance, mostly. To read both the email and the phone you'll have to make two requests (or a single multiget). The keys have a good chance of belonging to different replicas, too, and even if they don't, you are still going to have 2x disk reads.

This reminded me of "God Mode" (http://qntm.org/godmode).

'static' in C is the worst - it has 2 different meanings within the same language. Does anyone know the reason for this confusing design decision?

This is useful, thanks.

Would be even better with RSS/Atom feed.

Also ejabberd.

SMS/MMS gateway (aggregator) with SMPP, CIMD and MM7 support and AMQP interface (RabbitMQ as a broker). Also building a simple SMSC right now.

It's a perfect fit.

Is there even a word in japanese for "obscene"?

While Lua doesn't have many batteries included, it is trivial to expose a C lib-whatever interface to Lua when needed (example - http://github.com/iamaleksey/lua-zmq/blob/master/zmq.c).

And there is a c/++ library for almost everything.

There is also http://erlapi.prepor.ru/docs/

  ets:new(global_state, [set, public, named_table])

Now we've got a named table that any process may read or write to. It is possible.

Now that we have DHT + PEX + magnet links (http://lifehacker.com/5411311/bittorrents-future-dht-pex-and...), someone should come up with distributed torrent search and make the whole chain distributed.

Tsst, don't say things like this. They can be reading HN.

It will, but not anytime soon.

ASN.1 actually did take off, somewhat, at least in telco. And after comparing thrift to protobuffs to ASN.1 for our internal protocol I ended up chosing ASN.1, mostly because of the great ASN.1 support in the OTP (I'm using Erlang). Erlang protobuffs library, on the other hand, is somewhat lacking and is terrible at encoding/decoding huge messages with big lists.

And AMQP was chosen for the transport layer because it handles persistent messages, transactions, all the routing, buffers messages, etc., etc. I'd have to implement all of these myself, had I chosen thrift.

This is how I ended up with RabbitMQ and ASN.1.

REST, Thrift, AMQP + protobuffs.

A standard might lead to slower innovation at this point.

There is STUNT for that, but I have no idea about its current status. [http://nutss.gforge.cis.cornell.edu/stunt.php] [http://tools.ietf.org/html/draft-ietf-mmusic-ice-tcp-08].

Well, the NAT issue is almost solved with STUN [http://en.wikipedia.org/wiki/STUN] and TURN [http://en.wikipedia.org/wiki/Traversal_Using_Relay_NAT] (in those cases where STUN is not enough). Together they make ICE [http://en.wikipedia.org/wiki/Interactive_Connectivity_Establ...].

But none of these is needed for websockets to work.

This is much better handled in languages with pattern matching. And you can match on arbitrary fields.

Erlang:

  surf(Channels) ->
    lists:foreach(fun process/1, Channels).
  
  process(#channel{genre = "football"} = Channel) ->
    record(Channel);
  
  process(#channel{genre = "comedy", repeat = false} = Channel) ->
    record(Channel);
  
  process(#channel{genre = "crime", show_title = "Cops"}) ->
    skip;
  
  process(#channel{genre = "crime"} = Channel) ->
    record(Channel);
  
  process(_) ->
    skip.

Full gist: http://gist.github.com/250304

This doesn't make much practical sense. However, implementing Erlang on top of the JVM seems like an awesome way to learn Erlang and JVM internals at the same time.

Ah. Didn't get it.

Probably because writing erlang.org in PHP actually makes more sense to me than writing it in Erlang (:

Huh?

Erlang Web is pure Erlang, it doesn't have a single line of PHP. [http://www.erlang-web.org/]