Specifically, the weird stuff the author encountered like:
* Generating the token list by parsing the comments of a source file
* only parsing up to a hard-coded token instead of all of the known tokens (?!)
* using a hacky token hashing mechanism that only looks at the first two characters of the token
have nothing to do with Go-the-language.
I think this used to be more true for all languages? Getting defined by the common implementation is something that feels more true today.
That is, is there a particular quality of the Go language you can think of that necessitates only looking at the first two characters of tokens when hashing? Or that requires it to iterate only to `_Var` when generating the keyword map instead of the full length of the list?
If you want your language to actually have some real-world usage, you need real-world performance numbers. Which tends to lead to compiler codebases an few orders of magnitude larger, and much gnarlier to extend.
https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
To it's detriment, I guess.
bool char decimal double enum false fixed float in int lock long new null ref short sizeof string true uint ulong