Live data from Hacker News

RethinkDB: why we failed (2017)

defmacro.org

161–170 of 237 posts

Re: RethinkDB: why we failed (2017)

#161
post #15

Earlier quoted context omitted.

The problem is that this market is also one that is familiar to every other engineer. It's is a terrible one to get into because developers hate paying for their tools.

Did RethinkDB ever actually attempt to get people to pay for it? The massive, gaping hole at the heart of this analysis is "maybe we failed because we gave our product away for free as open source"?

[deleted]

Re: RethinkDB: why we failed (2017)

#162
I was under the impression that rethink db was not open source (until after it “failed”).

That’s not a reason for failure, of course, but I have mentioned before that we (as in developers) often only choose things with permissive licenses, often to the detriment of the products we “support” (see the recent elastic drama, where we blamed elastic being forked by Amazon for being too permissive!).

Re: RethinkDB: why we failed (2017)

#163
post #98

Earlier quoted context omitted.

I once saw a fascinating quote that went something like the following: "As computing technology develops it becomes more efficient to take centralised computing resources and distribute them closer to the user. As network technology develops it becomes more efficient to centralise them again. Further advances redistribute and yet further advances recentralise. This pattern has been noticed several times in the histor…

Can you give examples of "Further advances redistribute"? Also, I wonder if commodity cloud offerings such as AWS will change this?

Mainframes -> home pcs -> laptop -> smartphone, all advances miniaturizing and distributing computing closer to the edge

Re: RethinkDB: why we failed (2017)

#164
post #9

"Read The Economist religiously. It will make you better faster." Huh?

What he means is that if you're completely ignorant about business, then reading a financial magazine will help you level up over time. (Related: I've worked with new managers in SV who couldn't define what the words "leadership", "responsibility", "planning" or "accountability" meant, since all they knew was PHP programming.) It's a good post mortem read. I gave the same advice about "use case" as in the post mortem…

Thanks for the reply. I liked the article and was confused just about this part. I've browsed the Economist's site and all I could see was political propaganda and drama.

Re: RethinkDB: why we failed (2017)

#165
post #62

Earlier quoted context omitted.

Those are outliers, and even then most people I know with a GitHub account are using it for free. Same with IntelliJ - most of us at Google were using the Community Edition.

Andy Gocke put it on twitter better than I've ever seen it anywhere else: 'Developer tools seemed like a good industry to be in, "sell shovels in the gold rush" and all, but it turns out developers prefer to dig for gold with their teeth.' https://twitter.com/andygocke/status/1017509689695715328?lan...

I mean, as a hobbyist, and for side projects, I would use my teeth.

But for the company I work for, I don't care. I would recommend my employer the fastest and easiest tool. And my employer usually don't want to spend engineering time on reinventing wheels.

If I were to launch a business in this market, the targeted customers can't be individual developers, more likely other businesses.

Like gihub, individual developers who only use their free account are part of github's marketing team.

Re: RethinkDB: why we failed (2017)

#166
post #9

"Read The Economist religiously. It will make you better faster." Huh?

What he means is that if you're completely ignorant about business, then reading a financial magazine will help you level up over time. (Related: I've worked with new managers in SV who couldn't define what the words "leadership", "responsibility", "planning" or "accountability" meant, since all they knew was PHP programming.) It's a good post mortem read. I gave the same advice about "use case" as in the post mortem…

Hard to believe that reading a financial magazine written by journalists will increase your knowledge rather than an authority in the domain or a classic book on the subject.

Re: RethinkDB: why we failed (2017)

#167
So much of this is familiar. I was at two database startups.

The first one, an object-oriented database company (last 80s, early 90s) suffered from an extreme case of misperceived markets, due to the occasionally intentional blurring of the lines between a "database system" (which means SQL to nearly everyone, and we didn't to SQL), and a persistent storage class added to C/C++ (and later Smalltalk and Java).

The second one (mid 2000s) was a neat physical storage trick, which should have been a feature of a database system, not an excuse for building a new one. My bad for missing this, but I really, really liked the physical storage ideas, so I joined.

Building and selling new database technology is extremely difficult. There are successful, huge, entrenched companies. There is, therefore, no good reason for anyone to gamble on your new technology. Your only chance is to convince the architecture astronauts at some prospect that they just have to have your product, but the odds of such a decision sticking all the way through the delivery of their product is extremely low, no matter how good your technology is.

Re: RethinkDB: why we failed (2017)

#168

Earlier quoted context omitted.

Interesting, I think this is why private clubs used to be a thing and may be the only way to get a sustainable cozy, atmospheric coffee shop. Because really that's what you're selling, not coffee, but atmosphere. And membership is a way to charge for your real product.

Or charge for time, like Ziferblat do: https://ziferblat.co.uk/

That place looks lovely.

Re: RethinkDB: why we failed (2017)

#169

Earlier quoted context omitted.

I've heard this line many times but is this actually true? Are there stories or statistics of these things?

I've done several database migrations, and it's true, but not because the data is hard to extract. It's moderately easy to dump out CSV or JSON files to S3 and load them back in to another database (only moderately because you have to deal with fiddly encoding issues). So in that sense the data is easily extracted. Tools like AWS Data Migration Services, while not perfect, can also make this a lot easier. However, at…

4. Egress costs from the clouds are non-trivial for large datasets. So now you're locked into both your db and your cloud.

Re: RethinkDB: why we failed (2017)

#170
post #87

Earlier quoted context omitted.

Nice! I agree that curiosity is an incredibly valuable trait, especially in an entrepreneur. (In fact, one of our company values at TimescaleDB is, "Be a student in both work and life".) BTW - who is this? My apologies, I don't recognize the username :-)

Sky. Sensobi days.

Awesome! Hi!
Post reply on HN