Hacker News Reader

Was with you until you said you don't need SQL.

For really simplistic applications, omitting SQL is a fine choice, especially in golang you don't have the comfort of a well established ORM.

There exists libraries that do provide an ORM, but since the declarative side of golang is limited compared to languages, say Python, I find them unwieldy. Also, the current trend shuns the usage of an ORM in golang and encourages directly or indirectly writing SQL queries and interacting with the database through database/sql and its extending libraries, like jmoiron/sqlx.

For really simple application omitting a k/v store is even better. Why isn't a simple map good enough?

Depends on the requirements (persistency, concurrency etc.) No offense, but it's bit pointless to discuss it further without deeper context.

Lack of persistence is one such reason. Because Go's built-in maps are not completely safe to use concurrently, too, their usefulness as a key/value store is somewhat limited in many applications.

Naturally, it's possible to build a solution to persist Go maps and to make them safe to access across goroutines, but by that point you've built a persistent key/value store.

Reply on news.ycombinator.com