If anyone is planning on building a semi-ambitious web system soon, you should evaluate Go. It's kind of scary how productive it allows me to be now. All of the

If anyone is planning on building a semi-ambitious web system soon, you should evaluate Go. It's kind of scary how productive it allows me to be now. All of the following benefits, of course, may not apply to your project but I wanted to share my experience regardless. I started my project as a collection of (micro?) services, all talking to a distributed kv store, containers all orchestrated, etc ... That's just how we build things nowadays right? Well one day I said screw it and rewrote the whole thing as a Go monolith. Including the DB layer, which now runs on BoltDB, an embedded k/v store. So now I have a web analytics system, reverse proxy, rest api, pixel api, license key server, reporting engine, emailing service, and a custom stripped down time series database (uses Bolt as a storage engine) complete with a custom SQL-like language (stripped down version of InfluxQL). It all exists as a single binary, which magically works on Windows, OS X, and linux, with zero run-time dependencies. This has allowed me to provide my customers with a self-hosted version of my software if they don't want to use my cloud service. My cloud service is just a differently configured version of the self hosted binary. Compilation takes just a few seconds. Regarding performance. A single node handles thousands of requests per second. It's possible for me to optimize that further (I suspect by a lot), but I don't need to. And up to 1TB single node storage. Again, there have been larger BoltDB deployments but I simply don't need to push it very far since I can easily run multiple nodes when the time comes, each handling some subset of user accounts. Another delightful thing is my dependency situation. I have 8 library dependencies in total, and have never even had to think about which version I'm using past the initial download. They're mostly lean and mean and stay out of the way. Things like CORS middleware, JWT library, request mux, Bolt, and a few others. And they all work together since they all conform to Go's built-in defined interfaces. What I appreciate about the library ecosystem is that most of the libraries you will use are _done_. Go has no dependency versioning, semver, etc... It sounds concerning at first but I was pleasantly surprised about how much of a non-issue that is in Go. I suspect that a project of similar scale would have resulted in many lost hours in Maven, Gemfile, or package.json. Also, the concurrency makes me happy. I've never been one to multi-thread my programs. But Go makes it easy to build concurrent pipelines and services without needing a team of engineers to review it for correctness. Anyways I'm rambling, I guess I should list some of the frustrations and trade-offs I made. For one, yes you will miss generics at first. It seems like a weird thing to not have in the language. It kind of takes getting used to, but you will figure out how to write the same functionality in terms of interfaces. It's certainly unique, a bit more typing, but in the end, things still get done. But, yes, you will have to shift your mind to a different programming style. Which some find annoying. On the plus side, at least for me, Go is one of those languages that has changed the way that I think about programming. Also, not really speaking to the Go language, but if you're considering Bolt as I mentioned, don't expect it to handle replication or distributed fanciness for you. I'd have to say the biggest tradeoff I made is switching to a scheduled data file backup system in the place of an actual database service. With naive scheduled backups, you might lose a few minutes of data in the case of a total node failure. This can be improved on my end, but that starts to get pretty involved. ... I don't know why I just wrote an essay. Hopefully this encourages someone try out Go for their next project.