Go: Ten years and climbing

As a big Rust proponent, I don't think it makes sense to invoke Rust here. The goal of Rust is to provide a more secure low-level foundation for software; any tools it provides to "ensure data integrity" are in service of that end, and pale in comparison to the sort of correctness that Haskell strives for on principle.

Given that Go is memory-safe (modulo a few concurrency foibles), any software that gets rewritten from C to Go is still a win in Rust's eyes. I know more than a few people in the Rust community who are big fans of both languages (e.g. burntsushi, author of Rust's regex library and ripgrep), and the Rust developers have a lot of respect for the Go authors. Go and Rust have different priorities, and that's A-OK.

Only the most cynical view of the language would see it that way. Just because they don't agree with your programming worldview doesn't mean they are idiots. The fact that people can say smarmy stuff like possible for poor developers to verbosely muddle their way through to developing working real applications without actually becoming better with a straight face just shows how closeminded and ideological people get about languages. Just because you know what a monad is or use map/reduce/filter plentifully doesn't mean you are a better dev than someone who has spent years honing their skills in an imperative language.

Nobody gets this ideological about natural languages. Nobody in the real world says "Hey, why are you speaking Spanish? It's so inefficient, you should be speaking Mandarin". Just as in natural language, programming languages can be learned and adapted by people of varying proficiencies, and when you "get" their particular way of modeling the world, they become an extension of you and a tool. We should just be happy when people become really good speakers of a language, not whether it is the right one.

Do people really believe that individuals such as Rob Pike, Ken Thompson, and Brian Kernighan are just trying to propagate Blub, the language, so that all devs are lowest common denominator morons? Have you seen how clever some of things they've built are? I dunno, maybe some of the original hackers have learned a lot about building complex systems over the last 50 years, and maybe they've got something useful to say.

This is a thing that's commonly repeated, but it's not that, well, simple. Having a simple syntax doesn't matter that much for tools once you have a reusable parser library.

More important for tools is having a simple semantics. Do all builtins behave the same way? Is nil handled consistently (e.g. does indexing a nil map do the same thing as indexing a nil slice)? Are the coercion rules simple? Is importing a package free of side effects? (The answer to all of these for Go, unfortunately, is no.)

The most important thing, however, for tooling is whether the language provides static guarantees. For instance, if the language controls access to shared mutable state, you can do a lot to detect races statically. As another example, if panics were part of the type system, then you could statically know whether functions panic and, if so, what types of panics can happen. Here, Go provides very few static guarantees: it's very difficult to soundly prove anything interesting about Go programs.

Unfortunately, you can't really have it both ways: you can have a more dynamic type system that doesn't put many constraints on on programs, or you can have interesting static tooling. Go chose the former in nearly every instance.

If you are doing heavy sql queries, then it might be beneficial for you to use an ORM. There are plently of those out there, so choose one you like. Just create structs for your tables and run your queries.

If you are doing light/moderate sql. Just have an interface for your db calls, wrap your responses in a struct and use json tags for json encoding/decoding.

> What is the best way to prevent a request from crashing the server and killing a bunch of unrelated requests?

I use negroni. And its recovery middleware does exactly that.