201–210 of 366 posts
Slightly offtopic, but what do you use for your blog and documentation pages?
Since there's a little side riff about the name going on I thought I'd throw in my 2 cents. Personally I love the name. I think it does a great job of conveying the spirit of the project and provides unlimited pun opportunities. Plus it's memorable, just like a real life roach encounter. Unfortunately I'm sure some people will discriminate against your DB on the basis of name alone. That's ludicrous, but that's our s…
I see it as technical people on HN who appreciate the metaphor, versus marketing/business people who can only think of "image". It's to expected with the massive infestation of HN by suits and khakis in the last few years.
(Within reason. Someone on here actually said this argument is reasonable to have "because what would you do if they named it 'n-word'DB." Seriously.)
Earlier quoted context omitted.
If you have a moment, "tooling" is pretty vague; which kinds of tools were you worried about with Rust? (Also, congrats on the 1.0!)
This is more my personal opinion, and perhaps more revealing my ignorance on the existing equivalent tools in the Rust ecosystem, but here is a list of some of the Go tools we use when developing CockroachDB: 1. gofmt and goimports really helps enforce a single uniform style. We don't really care what the style is, as long as it's consistent across our 30 engineers and 200k lines of code. We have hand-rolled more Coc…
Earlier quoted context omitted.
I agree with all your points. That being said MongoDB, Aerospike and Hadoop have all gotten good traction even with their slightly silly names.
To me, cockroaches are such an unbelievably negative association that I don't think I could get over the name and work with this product, because I wouldn't want to be saying cockroach all the time. Same thing if your database was called BedBug.
That puts everyone competing with you at a HUGE competitive advantage. Making technical decisions based on the name of a product is the worst type of decision making.
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?
Also, they know what their sales cycles look like. They hear feedback from actual customers. They have people whose job it is to notice any advantage they could have along the way. And yet! They're still selling stuff, they're at 1.0, and they're still alive — with the name they have.
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 bikeshedding when the bikeshed's color will actually have concrete effects on adoption. Most people -- i.e. in procurement, management, finance, and others you need to appeal to -- don't want anything to do with cockroaches. The idea disgusts them at a gut level, not something you can talk away. HN users are giving vital advice, for free. Those who ignore it will have only themselves to blame. As I say every…
It so far appears not to be hurting them. In the slightest.
This "warning" comes from the HN crowd every time something is posted about CockroachDB. I think it's time to LET IT GO.
I for one, completely disagree with you but that's because I have a different understanding of the relationship between the business side and engineering. We are already looked at as eccentric and strange people, rarely if ever has an absurd technology name caused issue.
Someone talking about "cockroach" is equivalent to talking about "unicorns" or "git." Its considerably less offensive than talk of "masters" and "slaves." If you think this is such a problem for you, then work on your salesmanship as I wouldn't hesitate to talk to other departments or investors about this product.
I was a CTO up until I took medical leave this past October and I cannot stress how important salesmanship is to the role. I think your examples of other databases are hyperbole and not the point. You want them to be equivalent but they aren't. This comes down to what you can sell in your organization and if there is merit to it, then selling it should not be a problem.
One last point is other departments don't give a shit what the database technology is called unless it's something to put on their CV. Just call it the "database" as they most certainly will.
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]
Earlier quoted context omitted.
I can't speak for others, but at least for me the main attraction of CockroachDB is getting foolproof HA straight out of the box. That is something I think anyone can appreciate regardless of their dataset size. Note that I haven't actually ran CockroachDB yet, so I can't confirm if it really delivers on that promise, but I'm hopeful.
"getting foolproof HA straight out of the box" This is a minimal requirement for any modern database.
Earlier quoted context omitted.
It's not bikeshedding when the bikeshed's color will actually have concrete effects on adoption. Most people -- i.e. in procurement, management, finance, and others you need to appeal to -- don't want anything to do with cockroaches. The idea disgusts them at a gut level, not something you can talk away. HN users are giving vital advice, for free. Those who ignore it will have only themselves to blame. As I say every…
> It's not bikeshedding when the bikeshed's color will actually have concrete effects on adoption. Not taking a stance either way on the name, but that is the definition of bike-shedding (aka law of triviality). A committee won't vote for my nuclear plant because the bike shed is red. The bike shed's color has concrete effects on adoption. EDIT: I would just like to acknowledge the irony of bike-shedding bike-sheddin…
The bikeshed story is to illustrate overemphasis on something that is trivial. It uses the example of a bikeshed color and a committee wanting to spend a lot of time on it because a) they care a little about it, and b) they understand it well enough for hard-headed members to wade into the dispute rather than trust experts.
It's a failure mode -- by stipulation -- because the bikeshed color doesn't matter beyond minor (but real) aesthetic feelings among the committee, that are far outweighed the cost of high-level personnel devoting time to it. Had they been aware of the general dynamic of these thing, they could entirely prevent the loss by moving on; it's purely an internal matter.
The bikeshed model ceases to demonstrate a failure mode if and when the bikeshed color has impacts far beyond things under the control of the committee. For example, if the majority of the world's people had a near-religious devotion to destroying facilities that house a blue bikeshed, and that fanaticism was hard to defend against, this would be a valid reason not to make the bikeshed blue, and would warrant the committee's attention.
I summarize such situations as "that's not bikeshedding", though of course, to be more technically correct, I should say "that situation does not illustrate the avoidable failure mode in the parable of the bikeshed".
Similarly, if adoption matters for more than just that committee -- if they need to convince numerous other committees to adopt the design -- it's likewise "not bikeshedding" because the first committee doesn't have control over all the other ones; with respect to the first, it's an external matter, and they can't stem the loss just by saying "hey, this is trivial".
Now, you are correct that, a high enough level, this could work as a bikeshedding example, if you could simultaneously get the entire world to collectively agree on the non-importance of aesthetics on technical matters, and on what counts as technical vs aesthetic. Then the world could play the role of that first committee and say "wow, this is trivial" and it's done.
But if that were actually feasible, then that should be your product (producing universal agreement on matters where you have a logical proof-of-correctness), not a database!