3 ms·
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 libr
by ckaygusu 9y ago
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.
- dkarapetyan 9y agoFor really simple application omitting a k/v store is even better. Why isn't a simple map good enough?
- ckaygusu 9y agoDepends on the requirements (persistency, concurrency etc.) No offense, but it's bit pointless to discuss it further without deeper context.
- ovao 9y agoLack 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.