3 ms·

All that lambda and operator overloading magic makes the development of new drivers a lot more complicated than it has to be. And i wouldn't be surprised if som

All that lambda and operator overloading magic makes the development of new drivers a lot more complicated than it has to be. And i wouldn't be surprised if some languages end up feeling like second class citizens in the RethinkDB eco system because of it.

coffeemug 13y ago
That's definitely true and is a big tradeoff. I think it's a good one because people use drivers much more frequently than they write them, so in retrospect I think it was a good decision (though the jury's still out). Interestingly, the server protocol doesn't require the use of lambdas in the driver (and knows nothing about it). So in languages that don't support them, one could design a driver with a very different feel that work for that language, and it would still work well with RethinkDB. You could even write a completely string-based driver, and it would work well. (Though we didn't think through what a good C driver for Rethink would look like; we really wanted to focus on Ruby, Python, and JavaScript and offer a great experience in those languages).
- lazyloop 13y ago
  Sure, but the next problem is documentation, suddenly you have very different and incompatible examples for different languages. Possibly even between different drivers for the same language. MongoDB gets that part very right, you can apply pretty much all documentation to all drivers, with minimal changes.
deleted 13y ago
[deleted]
dkhenry 13y ago
When you consider the lambdas are really just sugar around chaining together some of the method primitives you don't _really_ have a second class citizen. I mean different languages give you different features so you _choose_ to work in java you might be limited to using just the primitives and not the full lambda syntax. However given your working in java and not scala you already made that decision ( BTW scala looks like it will support the lambda syntax really really well )

coffeemug 13y ago

That's definitely true and is a big tradeoff. I think it's a good one because people use drivers much more frequently than they write them, so in retrospect I think it was a good decision (though the jury's still out). Interestingly, the server protocol doesn't require the use of lambdas in the driver (and knows nothing about it). So in languages that don't support them, one could design a driver with a very different feel that work for that language, and it would still work well with RethinkDB. You could even write a completely string-based driver, and it would work well. (Though we didn't think through what a good C driver for Rethink would look like; we really wanted to focus on Ruby, Python, and JavaScript and offer a great experience in those languages).

lazyloop 13y ago
Sure, but the next problem is documentation, suddenly you have very different and incompatible examples for different languages. Possibly even between different drivers for the same language. MongoDB gets that part very right, you can apply pretty much all documentation to all drivers, with minimal changes.

deleted 13y ago

[deleted]

dkhenry 13y ago

When you consider the lambdas are really just sugar around chaining together some of the method primitives you don't _really_ have a second class citizen. I mean different languages give you different features so you _choose_ to work in java you might be limited to using just the primitives and not the full lambda syntax. However given your working in java and not scala you already made that decision ( BTW scala looks like it will support the lambda syntax really really well )