3 ms·

I really don’t understand the downvotes. I’m not experienced with either language - and this has nothing to do with a flame war. The question, unstated and uno

by dfee 6y ago

I really don’t understand the downvotes. I’m not experienced with either language - and this has nothing to do with a flame war. The question, unstated and unopinionated AND intellectually honest was: does language impact community adoption - and if so, what are the drivers behind it. If I were going to write a foundational technology, I probably wouldn’t write it in NodeJS, not that it couldn’t be done, but because I’d be concerned mainstream adoption might suffer. For example, I’d expect a hypothetical JsSql (a SQL engine written in JavaScript - assuming this doesn’t already exist) would achieve lower general adoption than writing it in C++. Get it?

pkaye 6y ago
Their main product is in Go so they are most familiar with it.
brokencode 6y ago
I don’t think Cockroach cares about adoption. This is not meant to be a generally useful product in itself outside of their database. So the language was chosen mainly based on their familiarity with Go and its ability to integrate with their existing codebase. I think their omission of major features such as transactions is more likely to limit adoption than the language choice, so language choice is kind of irrelevant from that perspective.
- strken 6y ago
  The integration with their existing codebase might benefit from an explanation. In Go, calls to C libraries are done using a compiler feature called cgo, and there's a performance penalty that the cockroachdb team measured at 171ns per call, plus you sometimes have to copy additional data around for memory safety[0]. So far as I know, there's no way to avoid this penalty that doesn't involve building a tool that does the same thing as cgo. In this case, given that they already have a database written in Go, writing the backing kv store library in Go has a clear performance benefit of 171ns every operation. This is above and beyond just familiarity and easy integration, although those are also important. [0] https://www.cockroachlabs.com/blog/the-cost-and-complexity-of-cgo/ https://www.cockroachlabs.com/blog/the-cost-and-complexity-o...

by dfee 6y ago

pkaye 6y ago

Their main product is in Go so they are most familiar with it.

brokencode 6y ago

I don’t think Cockroach cares about adoption. This is not meant to be a generally useful product in itself outside of their database. So the language was chosen mainly based on their familiarity with Go and its ability to integrate with their existing codebase. I think their omission of major features such as transactions is more likely to limit adoption than the language choice, so language choice is kind of irrelevant from that perspective.

strken 6y ago
The integration with their existing codebase might benefit from an explanation. In Go, calls to C libraries are done using a compiler feature called cgo, and there's a performance penalty that the cockroachdb team measured at 171ns per call, plus you sometimes have to copy additional data around for memory safety[0]. So far as I know, there's no way to avoid this penalty that doesn't involve building a tool that does the same thing as cgo. In this case, given that they already have a database written in Go, writing the backing kv store library in Go has a clear performance benefit of 171ns every operation. This is above and beyond just familiarity and easy integration, although those are also important. [0] https://www.cockroachlabs.com/blog/the-cost-and-complexity-of-cgo/ https://www.cockroachlabs.com/blog/the-cost-and-complexity-o...