I'd just like to add for the curious, that usually you'd use goyacc for parsing SQL.
And most serious SQL projects in Go have started with the SQL parser from vitess and adapted it to their use case (which is just funny trivia, but for anything big, I recommend it, did the same for OctoSQL [0]).
Call me contrarian but I find the article's approach poor (at least, as it is now).
If one looks at the overall content of the two articles of the series, 70%/80% of the content (or possibly more) is parsing, which is arguably the least interesting, or at least, the most boilerplate, part of a database system.
Regarding goyacc and "usually", I myself was curious about this years ago and asked on Stack Exchange: Do modern languages still use parser generators? [0].
Most of the time, major languages _do_ use hand-written parsers.
Of course it may literally be the case that most other SQL projects in Go do use goyacc. My point is that in general, hand-written parsers are more common in real software than you might think.
[0] https://softwareengineering.stackexchange.com/questions/2502...
Regarding the parsing part, that's interesting. Though the cockroachdb parser is a _great_ lecture about how to add nice error messages with goyacc. (You add a special error token which captures anything after a syntax error, so the parser doesn't break down. At least something around this, haven't yet dived deep into it.)
Though I know Go itself uses a handwritten parser.
Was it because they were the first and people just started using it or is it the best for some reason?
From my perspective (as the author of OctoSQL): I need a SQL parser. Vitess has a fully fledged MySQL compatible one. I'd probably want to copy the open source vitess one and add the necessary features myself, instead of writing it from scratch. It's just a big endeavor, a few thousand lines of goyacc code and even more Go boilerplate.
I'm not saying everybody is using the same library, because the code has been heavily modified after being copied. A look at the cockroachdb parses suffices to see how much changed it is.
If you look at OctoSQL, there too have been many changes to add stuff like table valued functions.
I don't work with Go, so this may be a requirement of the language that I don't know, but whenever I see lines like this, it automatically brings up the question why? --- do you really expect to need to rename the SELECT keyword? Especially when it's named "selectKeyword". Why not just use the string constant? Ditto for the others like "leftparenSymbol" --- I see there's explicit character constants in some of the other code too... it reminds me of the classic anti-pattern like "int five = 5;".
Also, you may find the full SQL grammars interesting to look through --- they are quite a bit more complex than the subset presented in the article: https://ronsavage.github.io/SQL/
One funny thing you can do in Go is for example to create a subtype of int and change its String() method to return the hexadecimal representation of that int. Very neat.
Other type systems, like TypeScript, support string literal types, and in Typescript we generally would just define the keyword type to be a union of string literals and then use those string literals in the code.
But without string literal types, using a string constant gives the compiler more information it can use to make sure your code is correct. That's a useful thing to have.
Yep, it would be a little harder to implement all of the SQL spec in a single post. Maybe over time though.
For example when storing session state into a Dictionary<string,object> all access to the session state is through static strings, never a string literal. This makes is super easy to find everywhere that’s accessing that particular session variable.
As much as I love rust, its learning curve is high and I'm sure Op doesn't want to spend half his article teaching all the intricacies of types and the borrow checker. Go is easy to learn over a weekend so its probably a better medium for illustrating the concepts as everything is laid out simply.
As for databases and GC, you may be right but there are still major databases out there written in Java for example.
https://www.quora.com/Which-databases-data-stores-are-writte...
I like parser combinators but a word of warning.
A lot of parser combinators (not all) have problems with recursive grammar such as Json and SQL [1].
For instance, a JSON map can contain a JSON map and this can lead to stack overflows when defining the grammar.
[1] https://fsharpforfunandprofit.com/posts/understanding-parser...
Here is a great set of videos from "Low Level Javascript" channel explaining how to write parser combinators from scratch. - https://www.youtube.com/watch?v=6oQLRhw5Ah0&list=PLP29wDx6Qm...
The repo [1] has some additional bare notes on architecture and links to similar, more mature projects (primarily go-mysql-server and ramsql).
[0] https://notes.eatonphil.com/database-basics-expressions-and-...
All that knowledge can't be gathered by just staring at the source code. And for people who understand the source code well enough to gather all this info themselves maybe they don't need the blog post around it, right?
Now all this I don't say to demotivate you. I hope you're strong enough to get over negative feedback and think about rewriting it to something more useful. I see a lot of potential here. But every good writer needs one (or ten million hacker news reading) editors to get to the really good content.
