I quite liked that they distinguished between idiomatic, normative, and canonical. I have had places enforce quirky stylistic opinions and pretend they are idiomatic for the entire language. https://google.github.io/styleguide/go/index#definitions
If I never hear the word “idiomatic” in style and software discussions again it will be too soon. It’s in the same bucket of facile rhetoric as calling something “modern” (which means: I like it!) or “legacy” (it stinks!).
While greater precision would be nice, it is not in the same bucket as “modern”, about which I agree with your take.
There is an implicit statistical claim being made with “idiomatic” meaning something like “this is how the majority of people do it in the language”. It may also mean “this is how the authors of the standard libraries do it”. Of course you can use it as purely rhetorical device to bolster your argument without any real evidence, but in theory at least claims of “idiomatic” can be backed up by, say, running wide scale code analysis on Github repositories, or examining the standard library.
It’s a perfectly legitimate and useful concept. There are maintenance, onboarding, and other benefits to following common styles.
I’m curious how this is different from https://github.com/kyleconroy/sqlc?
Hi! This is my project. The main differences are
No codegen. Like carlmjohnson said, the Go structs are the source of truth (and you can generate migrations from them). You can go entirely without codegen by defining table structs as and when you need it, but the option is also there to generate table structs from an existing database.
It can generate dynamic queries. sqlc can’t support dynamic queries unless you push the dynamism down into runtime using SQL CASE statements (which affect the query performance).
sqlc is no doubt faster. But sq allows you to write queries that can target four different dialects at once (SQLite, Postgres, MySQL, SQL Server)  as a result of its dynamic query generation.
Sqlc is a code generator that uses .sql files as the source of truth. This has the code as the source of truth. Sqlc also does type checking on its queries, which is cool. But I imagine there would be someway to combine these projects so that sqlc can generate smaller files and use a generic library behind it.
Just curious, but what is Zas Editor itself written in?
Rust and Swift: source
Rust for the backend and Swift for the frontend.