Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CockroachDB 1.0

cockroachlabs.com

Post reply on HN
Print view View original

261–270 of 366 posts

Re: CockroachDB 1.0

#261

Post by oconnor663 »

throwasehasdwi wrote: post #187
newsat13 wrote: post #160

Very disappointed with HN turning into a 4chan/reddit style trolling board about the name. Guys, we get it that you don't like the name. Can we please stop bike shedding and move on? The people at cockroachdb have obviously seen all your messages but decided it's worth keeping the name. What more is there to talk about? Why not talk about the relative technical merits of this DB?

It's not trolling. It's a legitimate warning and they can choose to ignore the chorus to their own peril. The warnings get louder as they get more resistant to changing their name. Keeping the name for whatever reason IS going to cost them enterprise customers

There's a difference between "legitimate" and "useful". If the top comment on every CockroachDB post was "hey y'all remember that Go's maps aren't thread-safe", that would certainly be a legitimate warning. But at the same time, the CockroachDB team have been coding in Go for years, and they obviously already know that. If those top comments frequently turn into big threads arguing about whether Go's maps should have been thread-safe, the whole thing goes from being questionably useful to seriously annoying. Same thing's happening with the name. They know.

Re: CockroachDB 1.0

#262

Post by disconnected »

fs111 wrote: post #259
disconnected wrote: post #225

Earlier quoted context omitted.

Well, since this discussion has already gone down the tubes, we might as well spend some productive time making fun of other DB names: - SQLite: SQL database with no sugar. Less calories! - MySQL: A selfish database. - IMB DB2: Released in 1983, but never got promoted to DB3. Probably abandoned software? - Postgresql: Gesundheit! - CouchDB: A database for lazy people. Part of the NOSQL family, the Zen database family…

> - MySQL: A selfish database. MySQL is named after the founder's daughter "My". The fork is named after his other daughter "Maria": https://en.wikipedia.org/wiki/Michael_Widenius#Personal_life

I didn't know this. My intention was never to offend, just to try (and apparently, fail) to be funny.

Re: CockroachDB 1.0

#263

Post by ryeguy »

rubyn00bie wrote: post #252
eridius wrote: post #232

Earlier quoted context omitted.

The end goal of a company is not to raise venture funding. So you cannot use "they raised capital" as proof that their name isn't a problem. Their name absolutely will hurt their adoption. Maybe the product is good enough that they'll still be successful, but if so, you would expect them to be even more successful if they didn't have such an off-putting name.

Did I say it was the end goal? It's merely a metric for a young company. What it means is that enough people have decided that there is a future that current revenue, growth, and expectations are being met or substantial. Raising $53 million dollars isn't easy. So I can say capital raised is a metric on which to base a judgement. Your statement that it "absolutely will hurt adoption" is unqualified and nothing but op…

You're missing the point. Saying "they raised capital" is not a good counterargument to "it will hurt adoption". Your response would be a good counter to "they will never raise capital" or "no one will use this".

You can't know how many VCs didn't fund due to the name or how many tech decision-makers at companies will pass on this product due to the name. That being said, I doubt it will be/was significant in any case.

Re: CockroachDB 1.0

#264

Post by SilasX »

genkaos wrote: post #197
SilasX wrote: post #194

Earlier quoted context omitted.

"Deragatory" isn't the problem; the issue is whether it invokes visceral feelings of disgust. Many terms can be used as an insult, but are still tolerable as a name because a) they have non-insulting usages, and b) the emotional response does not rise to the level of "visceral disgust". The Spanish Wikipedia suggests many usages of the term "mongo", which probably wouldn't persist if the term was so repulsive: https:…

I'm a spaniard and mongo is an insult. [removed unnecessary snarky comment]

Okay, there are separate issues going on here; let me try to clarify:

Is "mongo" the equivalent of English "retard", in terms of being a low-class insult that invokes a visceral reaction among the majority of the population?

I didn't believe that at first; if so, why didn't anyone ever put it in Wikipedia? English has "retard" (in the pejorative sense):

https://en.wikipedia.org/wiki/Retard#Other_uses

And why doesn't it show up in a top-result Spanish dictionary?

http://www.spanishdict.com/translate/mongo

If it's merely an insult with numerous other meanings, I don't think it's comparable.

But let's assume it is equivalent to "retard". In that case, I would agree that it shouldn't be used as a name. But you have to pick your battles: all words will have that trait in some language. For my part, I would consider the Spanish-speaking market big enough not to expect them to buy [the equivalent of] RetardDB. So I agree there.

Edit: I agree with the sibling commenter networked's points.

Re: CockroachDB 1.0

#265

Post by eridius »

rubyn00bie wrote: post #252
eridius wrote: post #232

Earlier quoted context omitted.

The end goal of a company is not to raise venture funding. So you cannot use "they raised capital" as proof that their name isn't a problem. Their name absolutely will hurt their adoption. Maybe the product is good enough that they'll still be successful, but if so, you would expect them to be even more successful if they didn't have such an off-putting name.

Did I say it was the end goal? It's merely a metric for a young company. What it means is that enough people have decided that there is a future that current revenue, growth, and expectations are being met or substantial. Raising $53 million dollars isn't easy. So I can say capital raised is a metric on which to base a judgement. Your statement that it "absolutely will hurt adoption" is unqualified and nothing but op…

> And what exactly is "more successful?"

Pretty much any reasonable definition will do. For example, higher adoption is one metric that can be used to define success.

> Your statement that it "absolutely will hurt adoption" is unqualified and nothing but opinion.

It's an opinion that a lot of people share, judging from the HN threads I've seen about CockroachDB. And really, I shouldn't need to defend the idea that having a name that disgusts people will hurt adoption. It's just common sense. The only real question is how much damage will the name do? The better the product is, the more people will forgive things like bad names, but there will definitely be at least some level of damage.

In addition, if there's multiple products in the same category that are fairly close in quality, then subjective things like names will matter more. Maybe CockroachDB is significantly better than the alternatives right now (I really have no idea; this product category isn't something I know anything about), but if so, surely it won't remain "significantly better" forever. Other products will catch up, or other products will be created to compete, and we'll end up with several products that are similar, and once again, naming will become more important.

And finally, you're completely ignoring the fact that a lot of decisions about tech stack aren't actually made by technical people. They're frequently made by managers rather than engineers. And when the decision is made by non-technical people, marketing (e.g. name) is very important. Heck, even when the product is made by engineers, marketing is important, because that's how you convince the engineers to spend the time investigating the product to see if it lives up to its claims or does what they need.

Speaking as an engineer, if tomorrow I suddenly have the need for a cloud-native NewSQL database, I'm probably not even going to look at CockroachDB, simply based on the name, unless someone else convinces me that it's clearly superior. I find the name very off-putting and I'd rather not be confronted with the mental imagery of cockroaches any time I use the product.

Re: CockroachDB 1.0

#266

Post by orthecreedence »

lovich wrote: post #258
sandstrom wrote: post #221

Earlier quoted context omitted.

Mongo (similar to 'mongolism', another term for Down's syndrome) has done just fine, despite (or thanks to!) their name. There was similar criticism about their name in the early days, but it has waned as mongo has grown. This will too.

Wasn't mongo slang for humongous? Like Mongo from Blazing Saddles?

In the UK "mongo" is synonymous with "retard" if I'm remembering correctly.

Re: CockroachDB 1.0

#267

Post by nvarsj »

dmix wrote: post #25
dis-sys wrote: post #6

I really like the fact that the CockroachDB team recently did a detailed Jepsen test with Aphyr. The follow up articles from both CockroachDB and Aphyr explaining the findings are very interesting to read. For those who might be interested - https://www.cockroachlabs.com/blog/cockroachdb-beta-passes-j... https://jepsen.io/analyses/cockroachdb-beta-20160829

> CockroachDB is a distributed, scale-out SQL database which relies on hybrid logical clocks I was curious what "hybrid logical clocks" meant and found the linked paper a bit over my head. I found this more layman description: http://muratbuffalo.blogspot.ca/2014/07/hybrid-logical-clock... Apparently Google used GPS/atomic clocks to keep time synced: >> To alleviate the problems of large ε, Google's TrueTime (TT) emp…

I don't really get why you would build a distributed database with dependency on wall time (unless you're Google and can stick atomic clock HW on every node). Why not use vector clocks? Am I missing something?

Re: CockroachDB 1.0

#268

Post by nvarsj »

newman314 wrote: post #158
rodionos wrote: post #39

Earlier quoted context omitted.

> When a node exceeds the clock offset threshold, it will automatically shut down to prevent anomalies. If you're planning to run on VMware, be prepared to handle rather dramatic system clock shifts. I've seen shifts of up to 5 minutes during heavy backup windows. Not all customers might be willing to have their nodes go down due to system clock / NTP issues.

Do people not run NTP on their VMs? Or are you saying that you see heavy clock skew despite having NTP in place?

Cassandra user here in AWS. Clock drift is a big problem on VMs. NTP is not aggressive enough in these environments to keep clocks relatively in sync. We regularly had several hundred milli drifts between nodes. As cassandra is extremely clock sensitive, this is a big problem. We ended up using chrony with very aggressive settings to keep things in the sub-ms range for the most part. But it's still possible to get "hiccups" where time will skip. Especially if you reboot a VM.

Vanilla ntp makes assumptions about the hardware clock (that drift is stable) that don't apply to virtualised clocks. Using tsc clocksource may help as well.

Re: CockroachDB 1.0

#270

Post by irfansharif »

nvarsj wrote: post #267
dmix wrote: post #25

Earlier quoted context omitted.

> CockroachDB is a distributed, scale-out SQL database which relies on hybrid logical clocks I was curious what "hybrid logical clocks" meant and found the linked paper a bit over my head. I found this more layman description: http://muratbuffalo.blogspot.ca/2014/07/hybrid-logical-clock... Apparently Google used GPS/atomic clocks to keep time synced: >> To alleviate the problems of large ε, Google's TrueTime (TT) emp…

I don't really get why you would build a distributed database with dependency on wall time (unless you're Google and can stick atomic clock HW on every node). Why not use vector clocks? Am I missing something?

the section on lock-free distributed transactions on our design document[1] should answer your question, specifically the sub-section on hybrid logical clocks.

[1]: https://github.com/cockroachdb/cockroach/blob/master/docs/de...

Post reply on HN