Programming in Go: Is Go widely used in the enterprise?

[Qunfeng Wang]

Hi Mark,

I have a question about the usage of Go. I have an overview of Go. It seems it's not a language very interesting. For multi-thread programming, Erlang is way better and has been in practice for a long time. It doesn't support functional programming either. It's a killer feature for most modern programming languages. For the library, I think it's not bigger than Java or Python. So what does make the Go language popular? Will it be a language like C++ or Java, not well designed but popular in the enterprise?

Thanks!

[Mark Summerfield]

Hi qunfeng wang,

You haven't really asked a question; you've just said that Go isn't interesting and isn't well designed. Both of which I disagree with!

If you prefer Erlang for concurrent programming by all means use it. Personally, I prefer Go's channels and goroutines approach to concurrency more than any other model I've seen.

You can do functional style programming in Go, but it certainly isn't a functional language. In fact, no functional language has proven to be successful outside academia.

Go's standard library is not as extensive as Java or Python: but then Go is a much younger language and its standard library will grow over time just as the Java and Python libraries have.

For most of its life Python has been a language used by those "in the know" and not considered an "enterprise" language (compared with C++ and Java). But in recent years with the pressure to deliver applications faster and for increased flexibility, there has been a certain amount of switching from Java to Python, and many new projects that would formally have been done in Java are being done in Python from day one. I suspect that Go will follow a similar trajectory with the tipping point coming when organizations need to make their applications work concurrently to take advantage of multicore machines and the development and maintenance cost of doing so in C++ or Java is too high. At this point, more savvy developers will switch to Go which will provide them with a competitive advantage because of its excellent concurrency support. (Of course, Go's approach to concurrency will be adopted by C++ and Java in the form of libraries, but whether that will happen before Go becomes the natural choice for writing concurrent applications is moot.)

[Junilu Lacar]

Not that it's anything to go by -- pun intended -- but I watched the feature intro video at http://golang.org and found it intriguing enough to download and install Go. I try to do the pragmatic programmer thing and learn a new language each year. Not very successful at doing it but I think I'm going to give Go a go this year (sorry, pun overload). The Stringer and Marshaler interfaces alone are going to be quite a bit of exploring and experimenting. I love those XML and JSON examples.

I wonder, did the guys at Google pick that name on purpose just to see how far people would go with the puns? It's like you can't help it when you talk about Go.

[Mark Summerfield]

Hi Junilu,

I think they chose the name purely to win the attention of Google to fund them to do what they wanted. It doesn't help much for searching with Google though! I tend to always include "golang" or "go language" in queries.

The JSON and XML types are very interesting as is the uniformity of their approach. My experience suggests that those types are very easy to use for easy data---and straightforward to extend for more complex data. (I give some coverage in my book, of course.)

Good luck as you go for it!

[Junilu Lacar]

So as far as adoption in the enterprise goes, there are a few obstacles that I can think of right off the bat:

1. Cost and effort to operationalize - what does it take to deploy, operate, support, and sustain Go applications in an enterprise context? How easy is it going to be to find people with the necessary skills?
2. Tooling - What kind of tools are available that support/facilitate development and operationalization? What build and dependency management tools like Maven and Gradle, continuous integration tools like Jenkins, etc. that support automation, are available and how mature are these tools?
3. Frameworks - application frameworks, testing frameworks, etc. In Java, there's a plethora of frameworks such as Spring that help speed up and ease development and operation of applications. How long until we see some of these kind of things for Go?

There are many more but I think that will be quite enough to talk about for now.

[Mark Summerfield]

Hi Junilu,

It is a chicken and egg: the more adopters the more tools will be developed. Because Go doesn't permit dynamic linking, pure Go programs are always a single executable---much easier to deploy than an executable and a bunch of libraries.

Go comes with a build tool called go, although there are also third party build tools such as gb; and of course you can teach existing tools (make, scons, etc.) how to build Go programs. Most of the other tools have plugin architechures although you'd have to do your own plugins.

Go provides its own JUnit like testing (and benchmarking) tools.

I can't predict how long (or even if!) there'll be more support for Go. But as I said in another posting, I think that Go will quietly be adopted, gradually displacing C, C++, and Java for systems, backend, and server applications as more developers discover how much easier to use Go is---especially for concurrent applications.

[Junilu Lacar]

I guess the question of how long was really rhetorical. It took only a few years for Java to rise to the enterprise level. I worked on my first J2EE project in 2001, barely 6 years after Java first came out. I don't have any real-world statistics but just from my own limited world view, languages like Ruby and Groovy seem to have had a much longer adoption curve in the enterprise (talking about Fortune 500) although in recent years, adoption rates appear to be accelerating. I'm going to be involved in a Ruby on Rails project in the next few months in a predominantly Java/C/C++ environment but it is sort of a "skunkworks" project, outside of the normal IT-governed enterprise development ecosystem. Just based on that and how hard it is to get IT to adopt and support anything new, I doubt I'll see this skunkworks project graduate to full enterprise application status any time in the next few years. I imagine Go would have a similar kind of adoption curve in the enterprise unless it gets crazy adoption rates above the likes of Ruby and Groovy. What have you seen?

[Rick Goff]

Junilu Lacar wrote:Not that it's anything to go by -- pun intended -- but I watched the feature intro video at http://golang.org and found it intriguing enough to download and install Go. I try to do the pragmatic programmer thing and learn a new language each year. Not very successful at doing it but I think I'm going to give Go a go this year (sorry, pun overload). The Stringer and Marshaler interfaces alone are going to be quite a bit of exploring and experimenting. I love those XML and JSON examples.

I wonder, did the guys at Google pick that name on purpose just to see how far people would go with the puns? It's like you can't help it when you talk about Go.

Once you've grokked its beauty, you'll ogle Go code.

Poorly structured Go code will be known as Goo.

Just sayin'. For now.

[Igor Mechnikov]

Mark Summerfield wrote:
You can do functional style programming in Go, but it certainly isn't a functional language. In fact, no functional language has proven to be successful outside academia.

Could Erlang be an example of a functional language successful outside academia?

[Mark Summerfield]

Hi Igor,

No, Erlang can't be considered to be

an example of a functional language successful outside academia

because it is a multi-paradigm language which includes a functional subset; it is not a pure functional language like say, ML or Haskell.