Lies we tell ourselves to keep using Golang
The author writes well and makes compelling points. His &quot;I want to get off Mr Golang&#x27;s Wild Ride&quot; post is good too.<p>But I don&#x27;t find myself agreeing with his position, which is &quot;you shouldn&#x27;t use Go for production services&quot; (he explicitly says this in one of his Go posts, I forget which one and don&#x27;t have time to look right now).<p>The better alternative to Go is Rust. Okay, sure, I&#x27;m willing to admit that in the examples presented, Rust handles things better. But Rust isn&#x27;t a panacea. Rust is complicated and hard, and often it&#x27;s not worth taking on that burden just to theoretically handle cases that rarely occur and even more rarely cause any problem. Programming is a means to an end, and the cost of using Rust (hiring, increased development time) is often not worth it.<p>The reason Go is successful is because it&#x27;s easy for companies to use to solve production problems with teams of varying expertise. Its stdlib is well-featured, its ecosystem is good. There&#x27;s generally one correct way of doing things. The same doesn&#x27;t appear true in Rust. For example, an _incredibly_ common thing to do in production code is to make a web request. In Go, there is no need for debate, you use the stdlib. In Rust, you have to use a crate, which requires a decision to be made. Even worse is the async story, in Rust you have to decide whether to use Tokio or whatever. That burden is just not present with Go.<p>Btw this article should not be flagged and it&#x27;s pathetic that people have flagged it.