[photon137]

I've often wondered about using Go as an architectural choice - it's near-native fast, the syntax and semantics are good, it's GC'ed and runs on Linux (edit: my language of choice is C# - and Go is the only one that comes close to it _and_ runs on Linux, IMO - any others out there?- performance is critical).

However, if I decide to go with Go as a framework choice, is there an active market of Go developers out there from which one can hire?

[icey]

I've spent the past couple of months working with Go, coming from a mostly C# and Python background. One of the attractions to the language for me is that it's straightforward to pick up. Because there aren't a lot of "fancy" features in the language like Linq or list comprehensions, it's easy to dive into a block of code and figure out what's going on without requiring a lot of background knowledge.

The language eschews some brevity in exchange for clarity, which gives me a lot of confidence that I can take a good developer from any background, give them a week and feel like they've got a decent chance of acquiring the knowledge they need to work with the language.

The newness of the language means that there isn't a huge ecosystem of libraries available, BUT the standard lib is pretty damn great, and there are more and more people coming to the language every day.

My favorite thing about go is it's overall sense of boringness - Go code seems very predictable. There's a culture of digging into the source throughout the community, and tools like go fmt & go vet ensure that most code looks similar.

It'd be worth spending a week with it to write something useful to get a sense of whether or not you truly like it, but my experience has been very positive so far.

[StavrosK]

My problem with it is how frustrating it is to write when you're not very familiar with it, but I suspect that's more of a generic complaint about learning a new language rather than soecifically about Go. Every line I write, I go "argh, I wonder if this is the idiomatic way to do this" and I get frustrated a lot.

I love the features, though, especially the concurrency ones. It was conceptually trivial to write a multicasting TCP proxy in it.

[icey]

I had the same problems when I first started learning the language, and while I'm certain I've got a lot more to learn I found that making a habit of reading lots of source code made a huge difference.

After a little while you start thinking about "can this code be clearer? Are the intentions obvious?" and that makes the code much easier to write.

Go is incredibly easy to refactor, so instead of worrying about being exactly right, you can focus on "is this easy to reason about?". My experience has been that this process will get you very close to idiomatic code on its own.

[StavrosK]

I'm not so much frustrated about being exactly right at a high level, since I am experienced enough with other languages to get the general architecture down correctly. It's more like "How do you declare a slice of channels of channels of ints? Do you make() it or not? If you want to pass a channel, do you pass a pointer or not? How do you pass and reference a pointer? Do you use make in the outermost scope? How do you iterate over a channel but still handle a close?"

It's stuff like that, things I already know how to do in other languages but whose syntax eludes me in Go. I think all I can do is power through it until I gain some familiarity, though. Good thing the people in the IRC channel are amazingly helpful.

[jebblue]

>> Because there aren't a lot of "fancy" features in the language like Linq or list comprehensions

Not yet perhaps.

[NateDad]

The team working on Go regularly rejects proposals that make the language more complex just to save a few keystrokes. They and most experienced Go programmers value the simplicity of the language. Syntactic sugar is routinely rejected out of hand. The increment operator (++) isn't even allowed as an expression because it is too easy to make confusing and error prone code. (you can still use it as a statement, you just can't do like foo[a++]). I wouldn't be worried about the language increasing in complexity much. :)

[gits1225]

I think, the best time to find hackers would be before killer applications[1] written in that specific programming language starts to appear. After that, time will pave way to The Go paradox[2].

The best places to find these people would be golang-nuts mailing list, /r/golang, #go-nuts irc etc.

[1] https://en.wikipedia.org/wiki/Killer_app

[2] http://www.paulgraham.com/pypar.html

[microtonal]

After that, time will pave way to The Go paradox[2].

I am not sure.

Most people who know the important low-level languages well, are not likely to be a fan of Go. Seasoned C++ hackers will miss templates dearly (no, interfaces are not a replacement for templates, they are a replacement for abstract base classes) and C/C++ programmers dislike the lack of control over memory management. If you are using C or C++ in 2012, you probably have good reasons and Go mostly sacrifices the advantages of C and C++.

Someone who is familiar enough with Haskell, ML, or Scala, will dislike the fact that Go practically ignored (or rejected?) two or three decades of research an programming languages. From the perspective of PL research, Go is a weak language.

In other words, the low-level and strong typing crowds are not that much interested in Go. If there is a new imperative language that does interest them, it is probably Rust.

The question is, who does switch to Go? One would guess that these are mostly Python and Ruby programmers who have never written much C, C++, or Haskell, and are looking for something faster and compiled. Yes, this is a generalization, and there are plenty of exceptions. Not exactly the 'Python paradox', 'better than the rest', programmers.

Following the Google+ community, discussions on HN, and to an extend the Go mailing lists, confirms those suspicions. There are lot of grandiose claims supporting Go (one of my personal pet peeves are people claiming that 'Go interfaces are like Haskell typeclasses'). But if you look at the language spec, there is not much interesting. Goroutines are nice, but they are just green threads. Channels have been done elsewhere.

Go is just a very boring language (which isn't necessarily bad), pretty much like Java, without the good package management (no versioning), good IDEs, broad library support, or a performant garbage collector.

Boring languages attract more mediocre programmers than great programmers.

Edit: if you downvote, please, at least leave a comment ;).

[icey]

Hi, mediocre programmer here!

I would add a bullet point to the list of reasons I like go: "Boring to people who bring up Haskell in every programming conversation" ;)

Seriously though, there are huge classes of problems in which the "interesting" part of the problem isn't the software that gets written but the business needs it solves. I am a fan of functional programming (I started the Clojure subreddit, and do a lot of "for fun" programming in it), but I've never run across a problem at my business where I felt like I needed to crack open Okasaki's book, or thought "this would be easier with an applicative functor".

Something I've enjoyed about learning Go is the open & accepting nature of the community; I don't think I've ever heard someone called "mediocre" because of other languages they use.

I am happy to feel like I don't have to be an incredible programmer to read the source code of the language I use, or the libraries I pull into my projects. I just want to get shit done so I can work on the problems that I find interesting, and for lots of us, that's just not going to be yet another implementation of datalog.

[aninteger]

I can't downvote but I'm using C/C++ in 2013 instead of Go simply because Go is not portable enough. There is currently no PowerPC port and that is still a requirement for me.

[jff]

gccgo might solve your problem, if you actually want the problem to be solved.

[3pt14159]

Easier concurrancy and better string management. Current c/c++ people already learned the common methods. Also, less ambiguous lines of code.

[burntsushi]

> no, interfaces are not a replacement for templates, they are a replacement for abstract base classes

Interfaces aren't a replacement for templates, but they aren't a replacement for abstract base classes either. Interfaces in Go provide polymorphism through structural sub-typing. My limited knowledge of abstract base classes says that these are very much not the same.

> Someone who is familiar enough with Haskell, ML, or Scala, will dislike the fact that Go practically ignored (or rejected?) two or three decades of research an programming languages. From the perspective of PL research, Go is a weak language.

I am a Haskell programmer, but that crowd is impossible to please unless you've provided every PL feature out of research in the last few decades. I've seen virtually no appreciation for simplicity of language design as an entire unit.

> If there is a new imperative language that does interest them, it is probably Rust.

Yes. I can't wait for Rust to get a bit more love in the documentation department. Pattern matching? Algebraic data types? Thread local storage? Type classes? Yes please! Where do I sign up?

> The question is, who does switch to Go? One would guess that these are mostly Python and Ruby programmers who have never written much C, C++, or Haskell, and are looking for something faster and compiled. Yes, this is a generalization, and there are plenty of exceptions. Not exactly the 'Python paradox', 'better than the rest', programmers.

In my experience, most Go programmers are in fact coming from Python and Ruby.

The premise of the "Go" or "Python" paradox is that skilled programmers tend to be the first ones to adopt new languages. Then the less-skilled programmers follow when there is sufficient buzz. I think that if one accepts that premise, it is applicable for Go.

> one of my personal pet peeves are people claiming that 'Go interfaces are like Haskell typeclasses'

That is annoying, but completely understandable. They are deceptively similar on the surface. But I don't think this kind of confusion is unique to Go. You'll see it everywhere.

You know what else people confuse? That Go interfaces are just like abstract base classes! :P

> But if you look at the language spec, there is not much interesting.

That's kind of the point. If you don't accept the overall simplicity of the design Go as a feature, then I can't blame you if you dismiss Go. If all you want to judge a language by is whether it includes cool and exciting new features, then Go will never be a good choice for you a priori.

> Go is just a very boring language (which isn't necessarily bad), pretty much like Java, without the good package management (no versioning)

I am utterly baffled. Go's approach to packaging is literally the best tool of its class that I've ever used. The Go tool militates toward convention rather than providing a dizzying array of features. This makes it strictly less powerful than other packaging tools, but god dammit, it makes it dead simple to install packages.

You want to try my window manager, which is roughly 30,000 LOC (including my X libraries)? If you have Go installed: `go get github.com/BurntSushi/wingo`. That's it. You're done. I just ran it on my system, and it downloaded, compiled and installed my window manager---along with all of its dependencies---in less than 30 seconds.

You might say---other build tools can do this! But do you know how many lines of configuration I had to write for any of this to work? None. I didn't specify dependencies. No strange command line flags. Nothing. The common case Just Works.

> Goroutines are nice, but they are just green threads. Channels have been done elsewhere.

This is a vast understatement. Just green threads? And please, tell me, what other mainstream language supports green threads? I know Haskell and Erlang do. Rust will (yay). Anything else? No? (I know Java doesn't, but I can't remember if this is a limitation of the JVM or if Scala or Clojure have green threads). Go does. That's a pretty big deal. Go makes a solid concurrent style of programming in a C-like language virtually free. Sure, everything is still mutable, but there are powerful idioms that---in my experience---militate against race conditions. It's not as good as Haskell/Erlang/Rust in the compile time safety department, but I'll be damned if it isn't loads easier than my other choices: C, C++, Java, Python, Ruby, Lua, blah blah.

> Boring languages attract more mediocre programmers than great programmers.

And close minded folk think they have all the answers. It's possible for people to enjoy using more than one tool. I'm a hacker, and I love good tools. Go is a great tool. So is Haskell. I hope that Rust will be.

[microtonal]

You know what else people confuse? That Go interfaces are just like abstract base classes! :P

I think you are confused by abstract base classes in Java. In C++, which has multiple inheritance, a class can inherit from multiple classes. An abstract without implemented methods behave like an interface, it specifies what deriving classes should implement. The largest difference is in implementation: in C++ a base class pointer is just that and methods will be looked up via the vtable, in Go the interface-typed 'pointer' is actually a type pointer - instance pointer tuple (which is ugly, because it clouds nils). And in Go you do not have to specify the interfaces being implemented explicitly. Some see that as an advantage, others as a disadvantage (since a struct + functions can accidentally implement an interface, while not implementing the intended semantics).

I am utterly baffled. Go's approach to packaging is literally the best tool of its class that I've ever used.

No version management. Fun for hobby projects, a nightmare for large mission critical programs.

This is a vast understatement. Just green threads? And please, tell me, what other mainstream language supports green threads? I know Haskell and Erlang do.

Many languages have green thread implementations (Ruby 1.8, Python, etc.). But there is a varying amount of multiplexing to native threads and some implementations are hampered by global interpreter locks, etc. In fact, even old Java versions implemented green threads, but they were replaced by native threads.

[burntsushi]

> And in Go you do not have to specify the interfaces being implemented explicitly.

This is precisely what I meant by "... [interfaces] aren't a replacement for abstract base classes either. Interfaces in Go provide polymorphism through structural sub-typing."

Whether it's a good thing or not, it drastically changes the way they are used.

> No version management. Fun for hobby projects, a nightmare for large mission critical programs.

I use the `go` tool for more than hobby projects.

You are re-stating what I already acknowledged. What point are you trying to convey? I said the `go` tool was strictly less powerful, but that it was awesome for the common case. If you don't think that's worth anything, then I'm not sure what else to tell you.

> Many languages have green thread implementations (Ruby 1.8, Python, etc.). But there is a varying amount of multiplexing to native threads and some implementations are hampered by global interpreter locks, etc. In fact, even old Java versions implemented green threads, but they were replaced by native threads.

So........... Go wins here.

Do you really want to have a conversation? Or do you just want to mirror everything I said right back at me?

[iamwil]

You can look on the google groups, called go-nuts, and see how many devs are subscribed.

I wouldn't worry about an active market of Go devs to hire. If a language is any good, it'll attract developers. If you're a programmer, you should try out the language to not only do things you can do in other languages (to see how it fares), but more importantly, "What are the new things I can do with Go that use to be hard, but are now easy?"

[krakensden]

No love for Mono? My impression was that they're doing good work- they've finally turned on their generational GC, for instance.

[wging]

It seems so easy to pick up that I wonder whether it's wise to restrict hiring to those who are 'Go developers'.

[photon137]

That's also true. But having the ability to hire people who can hit the ground running with production code is an advantage.