They’re both general purpose languages that put a premium on usability. Except that Go is faster, runs better in multithreaded environments, and is actually simpler to grasp due to a liberal lack of features. I don’t think it’s crazy to conclude that you should replace all your Python with Go when you can have more efficient program and more compile time checks at no additional cost.

I’ve seen plenty of projects switching to mypy and asyncio kicking themselves that they can’t just use something like Go.

I find Python easy to use. I don't think Go is easy to use at all. Boilerplate, boilerplate, boilerplate.

I don't have to write for loops in Python. Go makes me.

Go is not especially friendly when dealing with lots of similar, but different, json though. Lots of boilerplate and overhead (more code) there.

A lot of that isn't so much "Go" as "statically typed language".

I say this not to defend Go, but to encourage anyone creating a JSON-based API to at least test with a statically-typed language. It's too easy in a dynamically-typed language to create a field that is either a number or a list of numbers, but you just boned all the static languages in the process. Unless you know you're only talking internally, and you're never going to change to a static language of any kind, JSON APIs should generally be written in a subset of JSON that is static-friendly.

It's not that crazy of a requirement anyhow; it's not really a great plan in dynamic languages either because it complexifies the code there, too, just not as much. It's a bit of discipline, yeah, but it's good for you even in a purely-dynamic environment.

Do note that Go also heavily uses reflection (from what I recall) for parsing json, so it can be a bit slower than one would expect.

In some ways Go is a litmus test. Do you have a simple, consistent schema? Are you trying to overload the types of fields and making parsing more difficult? I have run into this problem myself, but I realized that Go was pushing me to simplify and make things uniform which actually made my life way easier in the long run.

nice, I'm just going to send mails to the various creators of the JSONs I consume to ask them to change their protocols because it's not simple enough and solve world hunger while I'm at it

Most of my struggles here have been when consuming /existing/ json blobs, specified elsewhere: 3rd parties, other internal services, "versioned" json blobs, and the big one... consuming json structured logging.

So I think we could both be right.

The additional cost is in the inevitable boilerplate that you'll end up writing to handle real world problems. Python let's you extend the language to help with this. Go, by design, doesn't allow you to. There are pros and cons of each. Not once have I felt I could forget Python because Go exists.