I found this a very insightful read as someone just getting started with Go. Makes me excited to see how Go matures but also helps me understand what I'm getting myself into. "Cautiously optimistic" is a good way to summarize the feeling indeed.
That was an interesting article to read for sure, but forgive my noobishness, what exactly is Go for? Im by no means an expert programmer or anything, but I think I have a fundemental understanding of what languages do and comparisons between them. What is it that is making Go so popular, or sets it apart from other langauges?
It's as fast as C++, easy to write as Python, highly parallel, and created by a popular company. It's primarily a systems-level language for things like back-end web services. It's fast enough to replace C++, but easy enough to write that Python and Ruby programmers like it. To give you a better idea, they have a great tutorial to make a wiki in about an hour. My biggest Go projects have been an online multiplayer text game server (a MUD), and a service to manage schedules for electrical switches for power distribution systems. It worked well for both; though I hit the metaprogramming wall with the MUD.What is it that is making Go so popular, or sets it apart from other languages?
what exactly is Go for?
Specifically, lack of macros. Though Go's reflection and other metaprogramming paradigms also suck. I had a pattern that was repeated everywhere involving both a continue and a return. Which is impossible to convert to a function; it has to be a compile-time macro. Which Go doesn't have. I put as much as I could in a function, but it still ended up being about 6 duplicate lines, repeated everywhere, which were literally impossible to abstract. That said, that was before Go added go generate. I've yet to play with go generate, but I think I could use it to abstract the duplicate block. Though it's a pretty ugly way of doing it.
I was previously attempting to write a MUD in python... it's no picnic either. So I decided to use the language I know best C... So far... things are okay.
Thanks for the indepth, fantastic reply! Ill definitely give Go a look, having a browse through the wiki tutorial right now, Ill admit some things are very strange to me after spending months bashing c syntax into my head for college but it seems easy enough to get to grips with. Now to find a project I can use go for :)
If you are to believe the article, and my limited experience, the popularity of Go stems from its simplicity, approachability, and performance. It's easy to jump into Go and get some really nice results. As far as what it's meant for, I don't know for sure. A "garbage-collected systems language" is an oxymoron to some people, but not to others. Seems like Go is probably going to fill the niche between higher-level compiled languages (e.g. C++) and popular dynamic interpreted languages (like Ruby or Python). Got a big compiled C++ application but wish your language was less crufty? Go might be for you. How about a Python programmer who's itching for type safety and performance? Go is again probably a good fit.
I've come to essentially the same conclusion. Go is performant, parallel, has good error idioms, good library support for protocols, and is generally great for writing services. It's also terrible at metaprogramming, has poor native GUI support, is maintained by a corporation which could abandon it or go bankrupt, and generally ignores thirty years of language theory. (Seriously, it's 2015, why do we still have statements?) Exactly. I push Go at work because it's great for services, and it's an Algol-derivative, which means a much bigger talent pool than better languages like Erlang, Clojure, Haskell. It's not the best language in a vacuum, but it's one of the best in the environment we're in. Some points I disagree with: Erlang and Common Lisp beg to differ. The lack of generics is a metaprogramming failure, not a type system failure. In theory. I've yet to encounter it in practice. It's both. Go's performance is on par with C++. It's not a replacement for C, unless you're using C for things you shouldn't. But it absolutely competes with C++ and other systems-level languages (e.g. Rust, D, Nim). Incidentally, if you want a 'C++ level' language with real metaprogramming, check out Nim. It hasn't seen the industry adoption that Go has, but it's a performant Algol-derivative with real Common Lisp–style macros.They’re not capable of understanding a brilliant language
remarkably difficult to maintain and slow. I think this is characteristic of statically and dynamically typed languages in general. Dynamic typing allows you to quickly build and iterate but lacks the static-analysis tooling needed for larger codebases and performance characteristics required for more real-time systems.
Go’s type system is impaired
[interfaces] also can cause some subtle problems like accidental implementation.
Go is not a replacement for C/C++ but a replacement for Java, Python, and the like
The more I read about Rust and Go, the more I hear about Nim. Sounds like I should check it out indeed. Thanks for your comments. I feel largely the same. The most disappointing aspect so far, in my mind, is the "no"-heavy attitude from Pike et al. It's fine to be opinionated for the sake of simplicity, but I feel like Go is taking it too far, so as to be alienating.
I think the author nailed it with "Go is boring". It is, and that's what I like about it. It's just really easy to use, to the point where I don't really have to think about the language, I just write it. Add type safety, built in unit testing, a single code style & automatic imports, go get (yes, I actually like it), and it's an awesome language. Yeah, there are ugly parts, but that's true of any language. I'm not sure I've ever found one that I've enjoyed writing as much as Go. Keep in mind, the only large systems I've worked on have been in either PHP or Go, so my opinion may be a little flawed.
A good graphical debugger would be nice, though.... Godebug works shockingly well, considering how it's implemented. My coworkers and I all found it at the same time, and had a good laugh at how insane the implementation sounded. Then I actually used it, because hey, sometimes you just need a debugger. And it works really well.