What caught my attention about this post, and the reason I'm sharing it on HN, is that even though Rust's original selling point was its "ownership" feature, I'm starting to get the feeling that there are other things about the language and its that are driving its success.
In this case, it sounds like the killer feature is easy, powerful reflection. People also seem to really like Cargo. The standard library seems to be very nice. And the language's speed is excellent (ripgrep is written in Rust).
What's funny is that if you ask different people the same question about Rust's selling point, you'll get a different answer most of the time. Rust has a lot of features, and it's the sum of all the parts that make the whole, rather than a specific part in particular.
I loved that that article about Japan's rail workers. I'm a huge fan of this stuff. Pre-flight checklists, rock-climbing belay call-and-response, operating room instrument counts (to make sure nothing was left in the patient!), etc. Protocols based on the premise that even experts are fallible, and that even easy things can go sideways.
That is awesome. He has a lot more guts than I do. It's one thing to play a clever prank on a friend. It's quite another to play a clever prank on a casino security manager. And the secret service? Wow.
I think this is extremely cool, but I'm struggling to understand the disadvantage of actors compared to channels.
I think I understand the argument; just not sure I'm convinced by it. As I see it, the argument goes like this: Suppose you want to set things up so that block "A" is sending messages to block "B". With channels, block "A" just sends a message to a channel that it was handed; it doesn't know or care what is at the other end of the channel. The higher-level code that set things up created a channel, and then passed that channel to both "A" and "B". So, everything is loosely coupled, which is great.
With actors, on the other hand (so the argument goes), you would have to create actors "A" and "B", and then send "A" a reference to "B", saying, "Hey 'A', here is the actor to which I want you to send your output." So now "A" and "B" are wired up, but there is no explicit "channel" object connecting them. I think the argument is that this is worse than channel, because there is a tightly-coupled connection between "A" and "B".
But I don't think there is. In my scenario, some higher-level object still had to create "A" and "B" and wire them up; so, they are loosely coupled.
I think it may, perhaps, be true that an actor system lends itself more readily to tight coupling than a channel system does -- in other words, an actor system might lead the casual programmer down the wrong path. Is that what Rich meant when he said of actors, "Yes, one can emulate or implement certain kinds of queues with actors (and, notably, people often do), but..." ?
If I'm missing something, I'd love to be enlightened!
I don't know much about RethinkDB yet, but I will say that I have been a big fan (online) of one of its founders, Slava Akhmechet, for years. I've never met him, but he wrote some terrific articles on his website, http://www.defmacro.org/ , a few years ago. Start at the bottom of the list of articles, with "The Nature of Lisp."
Slava is a deep thinker, which makes me very excited to take a look at RethinkDB.
Indeed - he mentions in the article that he set himself a goal to convert 10 programmers into Lispers. Sounds like he probably has that many just in this thread! Kudos, sir!
He didn't make me a Lisper (I'm more a Haskell fan these days), but reading Slava's Lisp articles years ago was a significant part of what set me on my current career path.
He helped get me into functional programming, which got me a contract job [1], which is how I met one of my current co-founders.
I've joined RethinkDB just a couple of months ago, so I might not have all the historical facts right, but here is what I know.
In a previous incarnation RethinkDB was a highly optimized storage engine for SSDs implemented in C++ to be able to take full advantage of both low level SSD and kernel access.
The current distributed engine was built on top on this storage engine and I think it only made sense to continue with C++.
Originally, RethinkDB was to be a MySQL storage engine, which made C++ the natural choice.
They pivoted away from MySQL after my short stint in the beginning so I can't speak to why the storage code was kept (though I can't imagine it's because my code was so great they couldn't bear to throw it away).
Storage people tend to stick close to the metal, in general. This means C or C++ in most cases, for better or for worse.
In this case, it sounds like the killer feature is easy, powerful reflection. People also seem to really like Cargo. The standard library seems to be very nice. And the language's speed is excellent (ripgrep is written in Rust).