go-json VS sqlx

For go -> you can actually get away with the standard json encoding package. Or if you want a slightly better one, I prefer goccy/go-json

Someone made a benchmark of serialization libraries in go [1], and I was surprised to see gobs is one of the slowest ones, specially for decoding. I suspect part of the reason is that the API doesn't not allow reusing decoders [2]. From my explorations it seems like both JSON [3], message-pack [4] and CBOR [5] are better alternatives.

By the way, in Go there are a like a million JSON encoders because a lot of things in the std library are not really coded for maximum performance but more for easy of usage, it seems. Perhaps this is the right balance for certain things (ex: the http library, see [6]).

There are also a bunch of libraries that allow you to modify a JSON file "in place", without having to fully deserialize into structs (ex: GJSON/SJSON [7] [8]). This sounds very convenient and more efficient that fully de/serializing if we just need to change the data a little.

--

1: https://github.com/alecthomas/go_serialization_benchmarks

2: https://github.com/golang/go/issues/29766#issuecomment-45492...

--

3: https://github.com/goccy/go-json

4: https://github.com/vmihailenco/msgpack

5: https://github.com/fxamacker/cbor

--

6: https://github.com/valyala/fasthttp#faq

--

7: https://github.com/tidwall/gjson

8: https://github.com/tidwall/sjson

Drop-in replacement for the stdlib JSON package: https://github.com/goccy/go-json

go stdlib json encoding/decoding is incredibly slow, not sure for how much longer because there are drop in replacements now that I think are just as strict and feature parity.

3rd party JSON libraries could help if you were comparing JSON. https://github.com/goccy/go-json

However, I understand the code that is generated is super optimized. For example, rather than use a router, it does a static code generated router. Rather than use goccy/go-json, it does manual marshalling.

Minimal dependencies: julienschmidt/httprouter and goccy/go-json

I suggested using https://github.com/goccy/go-json at my work, since its a drop in replacement for the standard lib, but there are people who apprehensive. In my opinion the performance gains are significant to justify adoption. But I'd like your input.

go-json for encoding/decoding

We've always used https://github.com/jmoiron/sqlx which is just the standard package + mapping to/from structs.

You can use this https://github.com/jmoiron/sqlx

I will be using sqlx to execute queries and map columns to struct fields and vice versa, sqlx is a library which provides a set of extensions on go's standard database/sql library.

sqlx + squirrel ftw

I'd rather suggest the use of tools more aligned with the core concepts of the language such as sqlx, which is an extension of the database/sql standard library. It allows you to use models/structs to map your tables but you have more control over the SQL statements you use to perform queries and the like. You can combine sqlx with Squirrel to build queries from composable parts.

IDE: use whatever make you productive. I personally use vscode. VCS: git, as golang communities use github heavily as base for many libraries. AFAIK Linter: use staticcheck for linting as it looks like mostly used linting tool in go, supported by many also. In Vscode it will be recommended once you install go plugin. Libraries/Framework: actually the standard libraries already included many things you need, decent enough for your day-to-day development cycles(e.g. `net/http`). But here are things for extra: - Struct fields validator: validator - Http server lib: chi router , httprouter , fasthttp (for non standard http implementations, but fast) - Web Framework: echo , gin , fiber , beego , etc - Http client lib: most already covered by stdlib(net/http), so you rarely need extra lib for this, but if you really need some are: resty - CLI: cobra - Config: godotenv , viper - DB Drivers: sqlx , postgre , sqlite , mysql - nosql: redis , mongodb , elasticsearch - ORM: gorm , entgo , sqlc(codegen) - JS Transpiler: gopherjs - GUI: fyne - grpc: grpc - logging: zerolog - test: testify , gomock , dockertest - and many others you can find here

This is the same situation I saw 20 years ago. Back then, all the managers were pushing development in Oracle tools. Those managers grew up on Oracle and Java was too modern for them. Now the situation is similar. Managers used to do things in Java and now they are still pushing Java. In fact, today Java brings nothing but problems. When I see a new project starting on Java it is always some big desperation. For a comparison of Java and Go, just look at the documentation for SQL. For go: https://pkg.go.dev/database/sql (31 pages) and maybe https://jmoiron.github.io/sqlx/ (12 pages). In Java only one class is 59 pages (https://docs.oracle.com/javase/8/docs/api/java/sql/ResultSet.html) and look how many of those documents there are: https://docs.oracle.com/en/java/javase/13/docs/api/java.sql/java/sql/package-summary.html and on top of that we have javax.sql - https://docs.oracle.com/javase/8/docs/api/javax/sql/package-summary.html And even then you use Hibernate for example, where the documentation has 11 manuals and of those the User Guide has 353 pages - https://docs.jboss.org/hibernate/orm/6.2/userguide/html\_single/Hibernate\_User\_Guide.html

sqlx