It will probably take several weeks before it is possible to purchase put options on Snap.
The cost of LEAPS is very high when they are purchased on speculative companies. For example, take Tesla.
Tesla closed today at $250. To purchase an "at the money" $250 put dated January 2019 (aka a LEAP) would cost you $54. So TSLA stock would need to fall below $196 at expiration before you began to make money on it. That's a simplification because you could always sell your put early, possibly at a profit. Buying a January 2018 put would be cheaper, but still quite expensive at $37.
To reduce the cost of a put you can buy one that is "out of the money". For example the TSLA $200 put dated January 2019 would be cheaper, only $31. However, TSLA would need to fall below $169 before you made any money at expiration.
So, look at that last example. TSLA now $250, you pay $31 now and you don't make money unless TSLA closes below $169 at expiration.
Math like that is why sophisticated investors often short stock rather than buy puts. They need to pay a price to "borrow" the stock to short but for many companies that price is quite low, below 10% a year. The cost of buying put options on the same stock could be two or three times as high as directly shorting the stock.
When SNAP puts become available I expect the math to be much worse than for TSLA. It will cost A LOT to buy puts on such a speculative company. In trader talk, the "implied volatility" will be very high.
I don't think there are actually any breaking changes. The release notes say "includeInitial" is breaking, but I think all of your existing application code will continue to run the same if you upgrade RethinkDB. It's just that new code using includeInitial will fail on old versions of RethinkDB.
This is a really exciting release! Atomic changefeeds make it much more consistent and robust to subscribe to realtime data in the client, and the performance improvements look incredible.
Hi Slava! Your project was immensely helpful for me to figure out what's possible. Optimistic updating is definitely the biggest and most challenging feature on my roadmap. I figured I'd save it until last so that by the time I start working on it some of those kinks would be figured out :) but I'm going to take a close look at the blocking issues.
Even when those RethinkDB issues get resolved, I still have some conceptual questions understanding how to make arbitrary queries update optimistically. For example, say that I'm subscribed to:
On the client side, because I used the pluck('name') operation in the subscription query, we can't possibly know which rows to optimistically delete since we didn't download the 'votes' field.
Do you know how this issue is addressed in meteor? I'm currently thinking I'll have to limit optimistic updating to queries that follow a simple structure, but I'd love a more general solution.
