5 ms·

Go folk might get a kick out of this but >> I said this project is "from scratch" but I'm going to bring in a storage engine Oh, so... not from scratch, then?

metadat 5y ago
That's kind of a nasty bait and switch, definitely not from scratch if you pick the indexer core up from GitHub on the way home after work. Phil, I'm a bit disappointed in you. This hasn't been the sort of thing I've observed from your (excellent) prior writings.
- eatonphil 5y ago
  You people are harsh! :) I'll put it this way: I only write about stuff that I think is interesting. And I don't believe my title is clickbait. If you read the article and still think it's not interesting or not my normal level of educational, well then I'll be surprised.
  - bogomipz 5y ago
    I thoroughly enjoyed this post! I also didn't perceive the title as any kind of attempt at "clickbait." Thanks for sharing. I would like interested in seeing more installments of developing this Elasticsearch style API too :)
  - metadat 5y ago
    It is interesting. If the indexer is being imported, it's also not "from scratch", at all. The two are not mutually exclusive. Your piece will stand on it's own, perhaps call it something like: Implementing The Elasticsearch Backend Myself in Go Phil, your editorial honesty, integrity, and accuracy will be appreciated by me and others. <3
- kungfufrog 5y ago
  Did you read the article? He addresses your point directly. Your criticism sounds a little petty, but, perhaps you're being flippant and it's lost on me..
  - deleted 5y ago
    [deleted]
  - metadat 5y ago
    I most certainly did, eatonphil's articles are always cool, in fact I wonder if he has a mailing list? Anyhow, importing the indexer disqualifies the "from scratch" quality. This doesn't mean there's anything wrong with importing it, only calling it "from nothing" when this isn't the case. Such language sets improper expectations in the reader and may even reduce reader engagement, since article content diverges from what the title claimed to offer.
- hombre_fatal 5y ago
  I don't get the emotions. How you save/retrieve bytes isn't the interesting part of this blog post as it's elementary. He could have just defined an interface { save(id, doc), get(id) } and moved on. If anyone seriously wanted to try to follow along with this code, googling how to use the filesystem in Go isn't beyond them. They'd have their own implementation from scratch just as the blog promises.
  - kreeben 5y ago
    >> How you save/retrieve bytes isn't the interesting part of this blog post as it's elementary I do not have a beef with the author, at all, in any way, but, LOL, that is anything but elementary. Furthermore, >> this post will not implement full text search. ...makes their solution or specifically, their index, not very "Lucene-like". Which is why I had objections to their title, not their blog post. Their blog post is fine :) Storage is one of the problems you'll need to solve, when doing "Lucene from scratch". Indices are another. Full-text indices implemented from scratch: hard and interesting.
    - hombre_fatal 5y ago
      > LOL, that is anything but elementary. Like most tutorials, surely it's a simple implementation that breaks things down into simple code so that you can see how things work at a more fundamental level and follow along, not something that's going to satisfy ACID properties and compete with Lucene. Way too much guff in these comments.
      - kreeben 5y ago
        It's a very good run-through but it's not at all from scratch. That's my sole point. Didn't mean to be harsh, but their title is click-bait.
  - jandrewrogers 5y ago
    Storage engines are far from elementary. It is one of the most complex and subtle parts of a database implementation, especially if you care about reliability, scalability, or performance. The term "from scratch" usually does not denote outsourcing all of the hard parts of a database implementation to an external library. I think people were just disappointed that the article was more about writing a database-like API than an actual database.
eatonphil 5y ago
Hey since my paragraph saying it's easy to swap out storage engines wasn't believable, here's a diff without any 3rd party library: https://github.com/eatonphil/docdb/pull/1 https://github.com/eatonphil/docdb/pull/1 Took me about an hour for a +40/-40 diff that is still <500 lines of code. You may notice that the code basically looks identical. That's because I wasn't using anything specific to a key-value store.

metadat 5y ago

That's kind of a nasty bait and switch, definitely not from scratch if you pick the indexer core up from GitHub on the way home after work. Phil, I'm a bit disappointed in you. This hasn't been the sort of thing I've observed from your (excellent) prior writings.

eatonphil 5y ago
You people are harsh! :) I'll put it this way: I only write about stuff that I think is interesting. And I don't believe my title is clickbait. If you read the article and still think it's not interesting or not my normal level of educational, well then I'll be surprised.
- bogomipz 5y ago
  I thoroughly enjoyed this post! I also didn't perceive the title as any kind of attempt at "clickbait." Thanks for sharing. I would like interested in seeing more installments of developing this Elasticsearch style API too :)
- metadat 5y ago
  It is interesting. If the indexer is being imported, it's also not "from scratch", at all. The two are not mutually exclusive. Your piece will stand on it's own, perhaps call it something like: Implementing The Elasticsearch Backend Myself in Go Phil, your editorial honesty, integrity, and accuracy will be appreciated by me and others. <3
kungfufrog 5y ago
Did you read the article? He addresses your point directly. Your criticism sounds a little petty, but, perhaps you're being flippant and it's lost on me..
- deleted 5y ago
  [deleted]
- metadat 5y ago
  I most certainly did, eatonphil's articles are always cool, in fact I wonder if he has a mailing list? Anyhow, importing the indexer disqualifies the "from scratch" quality. This doesn't mean there's anything wrong with importing it, only calling it "from nothing" when this isn't the case. Such language sets improper expectations in the reader and may even reduce reader engagement, since article content diverges from what the title claimed to offer.
hombre_fatal 5y ago
I don't get the emotions. How you save/retrieve bytes isn't the interesting part of this blog post as it's elementary. He could have just defined an interface { save(id, doc), get(id) } and moved on. If anyone seriously wanted to try to follow along with this code, googling how to use the filesystem in Go isn't beyond them. They'd have their own implementation from scratch just as the blog promises.
- kreeben 5y ago
  >> How you save/retrieve bytes isn't the interesting part of this blog post as it's elementary I do not have a beef with the author, at all, in any way, but, LOL, that is anything but elementary. Furthermore, >> this post will not implement full text search. ...makes their solution or specifically, their index, not very "Lucene-like". Which is why I had objections to their title, not their blog post. Their blog post is fine :) Storage is one of the problems you'll need to solve, when doing "Lucene from scratch". Indices are another. Full-text indices implemented from scratch: hard and interesting.
  - hombre_fatal 5y ago
    > LOL, that is anything but elementary. Like most tutorials, surely it's a simple implementation that breaks things down into simple code so that you can see how things work at a more fundamental level and follow along, not something that's going to satisfy ACID properties and compete with Lucene. Way too much guff in these comments.
    - kreeben 5y ago
      It's a very good run-through but it's not at all from scratch. That's my sole point. Didn't mean to be harsh, but their title is click-bait.
- jandrewrogers 5y ago
  Storage engines are far from elementary. It is one of the most complex and subtle parts of a database implementation, especially if you care about reliability, scalability, or performance. The term "from scratch" usually does not denote outsourcing all of the hard parts of a database implementation to an external library. I think people were just disappointed that the article was more about writing a database-like API than an actual database.

eatonphil 5y ago

Hey since my paragraph saying it's easy to swap out storage engines wasn't believable, here's a diff without any 3rd party library: https://github.com/eatonphil/docdb/pull/1 https://github.com/eatonphil/docdb/pull/1 Took me about an hour for a +40/-40 diff that is still <500 lines of code. You may notice that the code basically looks identical. That's because I wasn't using anything specific to a key-value store.