wmrowan

The vast majority of people using TypeScript in their projects won't run into the deeper complexity of the type system. For the average TS user the only visible impact of features like template literal types and recursive conditional types will be fewer bugs because maintainers of popular libraries used them to provide better types.

You don't have to personally understand TS's more complicated features to benefit from using TS in your project. I hope they continue adding richness to the type system so I can eliminate more bugs from my code.

Companies issue shares. These shares are listed as a liability on the company's balance sheet. Each share represents a liability to the company because it entitle its holder to a share of any dividends paid by the company.

The intrinsic value of a share is the net present value of this future stream of dividend payments, not its current market price. OP's point is that the market price of a share can be significantly above its intrinsic value in periods of irrational exuberance, such as now, creating "paper wealth" that doesn't really exist and which will evaporate when the speculators head for the exit.

That's a good question. I've given some thought to how we might build drivers in languages that don't support lambda functions and unfortunately, there don't seem to be any good answers.

The actual underlying S-expression syntax for ReQL lambda functions is pretty ugly by itself and I'm glad that so far we haven't had to expose it. The python `lambda x,y: x + y` actually gets compiled to something like the following: `(func [1,2] (add (var 1) (var 2)))`. Variable references have to be constructed manually no matter how you do it. With native lambda functions though you can at least hide those constructions behind the scenes and bind them to the function's formal arguments.

Fortunately though both C++ and Java, the two "traditional" languages we would most like to support, have either just (in C++11) or are about to (in Java 8) introduce lambda functions rendering the point moot.

Thanks for the notes gsibble, please let us know anywhere where we can make the docs more clear, especially anywhere the behavior has changed since 1.3. We appreciate your patience with the breaking changes.

As for the changes to `connection.run` and `query.run` please note that in the Python driver you can call `.repl()` on any newly created connection to set that connection as a global default. This should replicate the old behavior.

We decided that doing this by default was unsafe as it relied on global state modified any time a new connection is opened. Even so, we appreciate the convenience and kept the behavior in the form of the `.repl()` for when you're trying out RethinkDB in a simple script (or the Python REPL) that only creates one connection and doesn't use threads.

Currently RethinkDB has official drivers for three languages, Python, JavaScript, and Ruby. I hope you understand why it would be difficult for us to support many more than this. Eventually we're counting on support for 3rd party drivers from the community. In fact, there are already a few early community drivers from some intrepid contributors including for Haskell and Go.

We've had lots of requests for more drivers and lots of offers to build them, but we've asked our volunteers to hold off while we revamp the driver interface to make it significantly easier to build drivers for RethinkDB. Having written the first JS driver myself and the new version I can attest to the much greater ease of doing so with the new API.

The next release (1.4) due very soon will include these changes and a driver development kit to support 3rd party efforts. After that I'm sure you'll see a PHP driver emerge very quickly.

This is Bill @rethinkdb

The distinction between query.run(conn) and conn.run(query) is very fine indeed. There has been much discussion about this and there are both solutions have their merits. At one point we even supported both but decided the simplicity of having only one solution merited dropping the other.

Creating a new connection involves opening a TCP connection and sending a message to validate the driver to the server, altogether a few round trips. There is a small bit of per connection state stored on the server but since RethinkDB uses a custom coroutine implementation for concurrency support this does not amount to the overhead of an independent OS thread for each connection.

Invoking the query with a specific connection object is thread safe. There is a feature designed to help REPL users that stores the last connection in global state that is slated for removal in the upcoming release (1.4) that is obviously not re-entrant.

It would make sense to have connection pooling, especially in the python driver where connections block on requests. This is an idea we're exploring but is lower down on the priority list. As it is a fully client side feature there is nothing stopping 3rd party driver developers from implementing a solution though the official drivers will have to wait for other priorities.