Hacker News Reader

Comment by dvirsky | Hacker News Reader

But Go really does encourage good practices. I came to Go after programming in C, C++, Java and a bunch of dynamically typed languages. After a couple of years with Go I returned to C (and a bit to Java). And I'm writing better code in those languages now.

Now, part of it is natural progress probably. But especially when I'm writing C, I can tell that I'm writing it much better than before because I'm adopting back some idioms that Go encouraged me to adopt in the first place.

Also, because Go's standard library is so well written, you can learn from the best very easily, and understand what's going on. It's certainly not the case with other languages I write in.

View on HN

I suspect every time you move to a different language family you learn new things. I did C/C++ and Java then worked with an old Pascal codebase of all things that IMO taught me more than most other languages. Even XSLT taught me quite a bit.

I can't say that Java has improved me in any language, but Go and Python have improved my Java. But any time you learn new idioms in a new language, your understanding of programming gets better I suppose.

Is there a good resource where those good transferable go idioms are written? I dont think I will have time to learn go anytime soon, but would definitely spent time with an article or something like that.

Not that I know of, but Go is super easy to learn. You will get a grip of the basics and be productive over a few hours or weekend at most, and one or two hobby projects later you'll learn to appreciate the stuff I'm talking about.

BTW I've only felt I really knew the language and its inner workings and idioms deeply - after much longer, maybe a year and 2-3 big projects. But you get very productive very fast.

Not only that, but rarely am I supporting a library that I'm the sole developer on. Go takes away so much "individuality" of code. On most teams I've been on with Python and Java I can open up a file and immediate tell who wrote the library based on various style and other such. It's a lot harder with Go and that's a very good thing.

Yeah, at times the obsession of gophers with "idiomatic code" is annoying. But when you read someone else's code and it's idiomatic, you almost immediately have an intuitive sense how it works and can understand and modify it easily. Compared to Java OO code where you have to start chasing inheritance layers to find out where the piece of logic you're actually interested in resides...

Well, "idiomatic code" can often mean "for what you're trying to do, there is a way that works with the language better than any other way; do that". That is, it often means "working with the tool rather than fighting it". So, yeah, do it the idiomatic way unless another way is clearly better. (Idiomatic ought to win if evaluating "better" gives you a tie, because idiomatic will be more readable.)

I never really stopped to think about it until I read your comment, but I just realized the same applies to old Go code. As some of mine is approaching probably close to 2-3 years (and few things I haven't touched or looked at since!), and while it certainly could be rewritten to be better, it's interesting that Go's partial enforcement of idiomatic authorship appears to reduce the number of WTFs generated as a consequence of atrophy over time, to say nothing about how much less time is spent understanding the code.

Perhaps it's psychosomatic, but it sure seems easier to pick up something written in Go--long since forgotten--than it is in other languages. Then again, maybe it's also that Go taught me to substitute cleverness with terseness. The advantage here is that I've never been especially clever.

Interesting!

i think a couple of years of experience and learning a new language .. was a far bigger factor than any intrinsict characteristics of go

Not sure. the diff between 12 to 14 years experience is not like 2 to 4 years.

Reply on news.ycombinator.com