Grappling with Go

I had the exact same thought. On top of that, the fact that he did this before the post on Rust is strange. Why publish them out of order? Reading this first would have made it clear that he already had a strong bias towards Go, and also would have showed the Rust community what it was in detail that he liked in Go, so as not to have inflamed so many who love Rust.

It seems at this point clear to me, that the previous Rust piece was written out of sheer frustration, and that the entire period while "learning" Rust he really wanted to be writing in Go, which he had already found to enjoy. This is understandable, but creates a clear bias; which is completely fine, but would have been nicer to see this for that reason.

Everyone's experiences are going to lead them in different directions. I learned Go, decided it was missing features that I really wanted, and that's when I decided to learn Rust. That was a decision driven as much from comfort with a language as it was technical. Which brings me back to his original Rust post, it was written as though comparing two languages on their technical merit, when in reality (after reading this post) it was really about comfort. Again this is fine, and would have been clearer if posted in the original order.

DNS gets so much blame, and yet so little time is spent to make it better. If DNS is that important to your application, you should install a caching resolver locally on your system.

> Just as no sane person would pick up Rust to write generic web services in that scenario.

I agree, but that's the thing... people DO advocate for that!

http://www.arewewebyet.org

Of course, there's a lot of double-talk on the subject. "You can TOTALLY do it today!" ... "Eh, but maybe you wouldn't want to use it PRODUCTION today" ... "But we're just a FEW more crates away from being there!"", etc. The Rust community is great, but they seem they hedge their bets too much and are murky with the messaging.

Right or wrong, Rust and Go compete because there are a LOT of web and microservice developers out there (including me) who:

1. Love what Go brings to the table in terms of of type safety, and AOT compilation to single-file native executables...

2. ... but wish that Go had more functional-style constructs (filter, map, immutability, etc), generics, a contemporary package system that doesn't involve putting Git URL's in your actual source code... or any of Rob Pike's other stubborn alien quirks that people don't like.

Rust can't quite figure out whether it wants to market to this crowd or not. Sadly, due its learning curve, I DON'T believe that Rust is the answer for the "Go, but with more popular features" problem. But enough people aren't ready to concede that yet.

I continue to be surprised by this argument. It seems to only matter if your job is to learn one language per week.

I don't need to get up to speed in a weekend. It's the speed that I'm getting up to that matters. Of course there is a limit to this principle, I grant you that.

What matters as well is how readable other people's code is, or even my own code after not touching it for a year. And I mean readable for someone as proficient in the language as the original author. This aspect sometimes seems underappreciated by proponents of "powerful/expressive" languages.

so I ran this test using the linux source code. I warmed everything to prevent caching/buffering advantages.

For loc the best time was: 55.425s and the worst was: 1m30.557s

For loccount the best time was: 42.345s and the worst was: 56.396s

loc supports more languages but I also believe it has more false positives. loc reporting seems nicer as well.