Six years of Go

http://blog.golang.org/6years

by jaxondu • 11 years ago

405 286 11 years ago

blog.golang.org

Sphax• 11 years ago

Congrats to the team. Go has never let me down in my work and my personal projects, it's just awesome.

mojuba• 11 years ago

Feel free to downvote me if you want, but I'm skeptical about Go and what caught my attention in this linked article is the picture. Pretty much what I feel about Go. Was it a (sub)conscious choice?

kris-s2• 11 years ago

I picked up the new Go book (gopl.io) and have had a lot of fun going through it. The prevailing feeling of Go is "getting things done".

I also write a little Go program every day as practice. If you want a sample of some Go. https://github.com/kris-s/daily-go

kasey_junk5• 11 years ago

The prevailing feeling of Go is "getting things done".

This is a common refrain amongst go proponents and I find it quite distasteful. It either implies those of us who prefer other languages aren't "getting things done" or those who feel productive in Go aren't smart/hard-working/educated/etc enough to "get things done" in other languages. I don't think either is true.

I think a more accurate way to look at Go is that the language, tools, and standard library make decent design trade-offs when your target software is 1) simple 2) network daemon-y or a CLI and 3) going to be worked on by a wide variety of developers. There are lots of problems that fall into that problem set, and it is very nice to have a language targeted at it, but Go is certainly not a good fit for a huge number of software projects. You will be less productive in those cases using it.

kris-s2• 11 years ago

You are over analyzing that phrase.

geodel2• 11 years ago

"Getting things done" is quite accurate considering large number of popular Go projects in short time compared to allegedly better design languages ( Scala, Rust, Haskell, D, OCaml etc..)

woah3• 11 years ago

It's true though. Go has a small number of language features, and they are only the simplest ones. It can be learned in a day. Other languages like JS, Ruby, and Python have a big fixation on figuring out the prettiest syntax for stuff (JS promises and chaining etc, "Pythonicness", and Ruby's incessant cuteness). In Go, you can't really make things pretty, so you just bang out code.

michaelcampbell• 11 years ago

I think a difference here is not that people don't get things done with other languages, it's that the language was designed with that as a first class metaphor. (Whether or not that is true I can't say, but that's the feeling the poster gets.)

tptacek14• 11 years ago

I agree with you, but there is something to the argument; it's just poorly phrased as "getting things done".

gofmt, for instance, is uncontroversial. Taking the decisions about how to format code away from developers and standardizing it is widely seen as a win (a win Python flirts with as well).

Well, there's a lot of other things in Go that have been pre-decided for you, not just the formatting. The net effect is that you don't have to waste time:

* thinking about designing a DSL for your programming problem (DSLs in Go require parsers)

* designing a class hierarchy to express your programming problem

* choosing between event-loops and callbacks or pools of threads

* picking the right associative container library (do I want a red-black tree? a hash table? a trie?) for routine coding problems

These pre-decisions can feel confining, but I think for a lot of developers Go reveals that those decisions were usually a waste of time. When you actually hit a place where you need a red-black tree, it's not that big of a deal in Go to bring one in. You're just not going to do that for your session store or for a simple lookup cache --- which is, I think, what a lot of people who can't stand Go's lack of generics would be doing.

AnimalMuppet• 11 years ago

This is a common refrain amongst go proponents and I find it quite distasteful. It either implies those of us who prefer other languages aren't "getting things done" or those who feel productive in Go aren't smart/hard-working/educated/etc enough to "get things done" in other languages. I don't think either is true.

It could just be the feeling that Go gets out of your way more than other languages do. (For example, people complain about how much ceremony is involved in writing Java. Go could easily feel like "getting things done" in contrast.)

chrshawkes4• 11 years ago

I'd say after 6 years adoption rate has been rather lackluster

csears• 11 years ago

Compared to what other new language?

chrshawkes4• 11 years ago

maybe not specific to language, but compared to projects like Angular, React etc... Go has much less traction. Swift is a new language and is already much more widely used.

xiaoma• 11 years ago

Java, JavaScript, PHP, C# and ActionScript each got pretty good traction within their first six years as new languages. So did Ruby amongst the language community (of Japanese speakers) it originated from. As others have mentioned, Swift has had a good adoption rate.

sambeau• 11 years ago

That certainly doesn't feel the case where I am. I suppose it may depend on your work field and environment.

kriro• 11 years ago

Go seems like a fun language that has been sitting on my "look into it list" for a while, can't belive it's already six years old.

Since the TensorFlow video post is currently on the frontpage as well...as someone who uses neither C++ nor Go (I can write FizzBuzz level of code in both and read both well enough to get what's going on) I have to wonder how much internal buyin Go really has at Google if the core of such a project is implemented in C++. It's a project they see as valuable in the future and it would lend itself really well to Go as these calculations are done distributed and yet they picked C++.

[I'm not sure how much of the old framework they reused but if the will to Go was really strong I'm sure that wouldn't have been an issue]

kzvezdarov• 11 years ago

I think in the TensorFlow case it is just a purely technical decision - I don't see how they could achieve what they aim for with that project in Go (or really, in anything but C/C++ at this point in time). Right tool for the job, etc.

GrandTheftR2• 11 years ago

+1 for right tool for the job. Also, I can imagine they have large amount code already there in C/C++ since this is the second deep learning system they designed.

and if you watch Jeff Dean's video, he mentioned more front end in other languages, Go is the only example and as the interest from internal.

tptacek14• 11 years ago

Go is a language designed by Google people, but it is very much not the standard Google language. Most things Google does aren't done in Go.

jgrahamc3• 11 years ago

Having said that Rob Pike told me that Go is now one of Google's "official languages".

zaphar3• 11 years ago

It is a standard language at google. It gets used for things like the download service and other high throughput service which is it's sweet spot. The TensorFlow project in previous iterations predates Go's official stamp of aproval at Google I believe and stopping to rewrite is an unnecessary step. It's possible that now something like Go would be used instead.

[Former Googler around when Go got it's start]

microtonal• 11 years ago

It's a project they see as valuable in the future and it would lend itself really well to Go as these calculations are done distributed and yet they picked C++.

Go is not Erlang. Go supports green threads (goroutines) and offers CSP-like channels to communicate between threads. However, it does not have a distributed computing story yet (at least, not compared to Erlang, the usual Java frameworks, etc.).

For a library such as TensorFlow, Go is not really an option yet, for many difference reasons. E.g. the lack of parametric polymorphism makes it hard to parametrize code for single, double, or even half precision. Go does not support anything like expression templates, which exploit laziness to eliminate temporaries. Moreover, a lot of machine learning happens on GPUs nowadays. AFAIK, there are no CuDNN bindings for Go yet.

tl;dr: impedance mismatch

sinatra2• 11 years ago

Go supports green threads (goroutines)

As far as I know, goroutines are NOT green threads (threads managed by run-time environment instead of OS). Go produces native code (no VM). And, the goroutines can be multiplexed (depending on implementation) to OS level threads.

adrianlmm• 11 years ago

Despite the hype in the beginning, it never caught my attention.

lsllc2• 11 years ago

I've used Golang extensively for a few years now anywhere from ARM/Linux to x64/cloud based containers (and I admit, occasionally on Windows!). It's really a great platform, very robust and has an excellent ecosystem. I can't recommend it more highly.

johnydepp• 11 years ago

I tried Goland for two of my personal projects. Initially I thought I will get used to the new syntax, but it never happened. It may have certain performance-edge over other languages but I wouldn't call it a modern language. I find coding in C more fun than Golang..

hahainternet5• 11 years ago

I picked up Go because C frustrated me so much. Can you give some examples as to why you prefer C?

agentultra2• 11 years ago

Not the author...

I prefer C99. A smattering of features I like:

  * Variable Length Arrays
  * Variadic Macros
  * Designated Initializers
  * Anonymous Structs
  * Compound Literals

Some of the meta-"features" I like:

  * No built-in runtime or GC
  * A choice of dynamic vs static compilation
  * A good libc is wonderful but not necessary to get work done fast
  * The tooling is mature and plentiful

I'm sure Go is a fine language. I probably suffer from some sort of first-language bias as I've been using C for a long time and only know a smattering of Go from toy programs, blog posts, and reading the source to interesting projects like CockroachDB.

domrdy• 11 years ago

I love Go. It helped me so much, not only career wise but also on a more personal level, bringing back the excitement in programming I missed so dearly from my early days. Drop by at one of our Golang meetups if you're in the Munich area. http://www.meetup.com/Munich-Gophers-Go-User-Group/

dejawu3• 11 years ago

Started using Go for my latest project (a successor to Evernote). It feels like such a relief, especially having just come out of a node.js project. It's everything I wanted in a (web-app) programming language, and for the first time I can say that a language has actually made my code better. I've never had a codebase this clean before.

thebouv2• 11 years ago

I understand the basics of Go, but do you have any advice on where to start using it for web app development? Any framework that you're using (if one at all)?

lsllc2• 11 years ago

I've used go-martini on a number of projects; it strikes a nice balance between performance (it's by no means the fastest Go web framework) and usability.

dejawu3• 11 years ago

I've picked out the following that I like:

- Gorp[1] for SQL stuff (I like that it "encourages" your program data structure to reflect your DB structure) - amber[2] for templating - gorilla/mux[3] for routing - gorilla/securecookie[4] for login/auth management (they have a sessions and context library too if you want that)

Go also has libraries that handle basic versions of most of these tasks (and these third-party libraries extend them). If you're building something simple they might be sufficient.

[1] https://github.com/go-gorp/gorp [2] https://github.com/eknkc/amber/ [3] http://www.gorillatoolkit.org/pkg/mux [4] http://www.gorillatoolkit.org/pkg/securecookie

deepanchor• 11 years ago

I've found the standard library to be more than capable for most CRUD style apps. You can add in simple middleware chaining using a library such as Alice (https://github.com/justinas/alice) and for passing around request contexts between them, you can use something like xhandler (https://github.com/rs/xhandler). If you want more performant or flexible routing, httprouter (https://github.com/julienschmidt/httprouter) has a nice feature set.

Maybe it's personal preference, but there's something more satisfying about the modular approach of building up an app using only components I need and understand, rather than starting with a magical feature-laden framework but quickly realizing you don't need half of what it does. I think Go aligns particularly well with this philosophy given its emphasis on composition.

cubano2• 11 years ago

I don't mean to be snarky and I'm definitely showing my age here, but isn't that exactly what devs were saying about node.js two years ago?

blub• 11 years ago

It's what devs are saying about any tech that's becoming popular.

It's much more useful to read a competent critique of Go (of which there are a couple) than post after post saying how everything is great. Everything can't be great, it's a basic fact of software engineering!

boomzilla• 11 years ago

Yes, every language/framework is good at something and bad at some other. They are just tools. What matters is what one builds. A lot of technical news these days are about tools, not products.

zaphar3• 11 years ago

I can't remember anyone ever claiming javascript/node made their code cleaner. Speed and throughput were claims but not code quality.

dejawu3• 11 years ago

For what it's worth, I moved to node.js late and even then only reluctantly. I only used it for one project, and found it to be a somewhat difficult experience, like I was fighting the language all the time. (It was still a step up from PHP which I'd been clinging to.)

I didn't realize how much I disliked JS playing "loose and fast" until I used Go with its rigidity.

curun1r• 11 years ago

Perhaps it's because what makes a codebase messy is having written code in it over time.

In the beginning, those Node.JS codebases were clean and manageable. Then came bug fixes, changing requirements and refactors. 2 years worth of that led to something that was quickly becoming unmanageable.

But then came Go and, after a rewrite, everything was clean again! It doesn't matter than the code base is only 3 months old, I'm sure it's going to stay this clean forever!

But hey, should those Go codebases become messy a couple of years from now, I'm sure Rust will have matured into a worthy successor and, after a rewrite, we'll all have the cleanest codebases ever!

elcct6• 11 years ago

I didn't. I tried node.js for a couple of months and it was like a breath of fresh air. But later on drowned on constant promises and never called back ;)

jinst8gmi• 11 years ago

I find it curious that virtually any negative or critical comments about Go get downvoted.

thebouv2• 11 years ago

Have they been constructive, or just random negative noise?

penetrarthur• 11 years ago

Because you don't insult someone when it's his birthday!

lobster_johnson15• 11 years ago

On the other hand, honouring people by roasting [1] them is also tradition. Maybe if the criticisms were funnier.

[1] https://en.wikipedia.org/wiki/Roast_(comedy)

dilap5• 11 years ago

I've been having this vision for a while of making a HN-style site where you have to explicitly tag your comment as 'in agreement' or 'in critique'. (And also maybe a slightly hidden away, 'off topic, but that reminds me...' section.)

Then you could, for example, browse the ed column of birthday wishes & happy usage stories of Go, say on the left hand side, and then also, scroll through the op-ed right column of dissenters and critiques.

There's just something very disheartening about having a bunch of "anti X" dominating what you were hoping would be a discussion of "X"; downvoting is certainly not the right solution -- it's fine to be anti-X, it just needs a little bit of its own space.

steveklabnik• 11 years ago

Slashdot had this concept of modifiers, so you could say "+1 Insightful" or "-1 Troll". "+1 Funny" didn't give you any karma.

codygman2• 11 years ago

I wish the gdb support were better or that delve were more stable. I also had some weirdnesses using cgo on osx. Then I went into #go-nuts on freenode, and I got told I was wrong and there was no problem.

Back in 2009 #go-nuts seemed to be a much different place.

I write Go at work, and I admire many of the same things in Go I admire about Python.

I still wish generics were part of the language and will say their excuses about not being able to do it in a performant way seem to just be away of avoiding the subject.

Ocaml for instance, has a performant generics implementation.

Sometimes the Go community can have an anti-programming language research and anti-intellectual feeling which can be annoying, since in addition to Go I write a good amount of Haskell.

The tooling is nice as people say, however I think more maturing of the platform needs to be done. It's also never talked about how much slower Go's claim to fame of fast compilation got much slower after the 1.3-1.4 switch to a compiler totally in Go. In all fairness, I could be wrong about the last one since I haven't benchmarked it... but I can say it feels much slower than it was around 1.1/1.2.

Concurrency in Go is easy, however I feel like many erroneously think that channels or concurrency primitives like it only exist in Go. There are other languages with rich concurrency and parallelism options as well.

Using lots of interfaces and casting everywhere gets on my nerves since I like to have the strongest guarantees possible via static typing.

Overall though, I can't say I've had a bad experience with Go. I can say it feels like I'm using an okay tool (great in some places) with maintainers who put their hands over their ears to potential improvements (see the generics proposals over the years).

tptacek14• 11 years ago

I've been yelled at on #go-nuts too; I ran into what turned out to be an authentic limitation of Go's I/O scheduling, and was instead chided for _'ing out error results in my minimized example code.

placeybordeaux2• 11 years ago

Yeah I have been bitten by the _'ing errors thing in the go community.

jgrahamc3• 11 years ago

What was the limitation?

sanderjd• 11 years ago

It's really a shame when a community's most visible public channel devolves into "you're doing it wrong"-itude. When I first started looking at Go in 2010 or so, coming from the rails community, I thought it was wonderful how friendly and helpful #go-nuts was. Unfortunately, it seems like an inevitable result of the regulars in a room seeing a deluge of similar questions and increasingly losing their patience. Eventually, everything starts to look like an instance of some annoying newbie pattern with a pat answer, and you have to fight to convince people that there is something novel and non-pat going on.

nickbauman4• 11 years ago

Go's concurrency is limited to the CSP-style and favors share nothing problems. Languages like Clojure can do CSP just fine, but also have powerful language-level support for heterogeneous concurrency problems that are easy to use and easy to understand.

vox_mollis2• 11 years ago

This isn't remotely true.

CSP via goroutines and channels is idiomatic Go, but it's not the only option. Go offers mutexes and other concurrency primitives which, along with goroutines as lightweight thread analogues, allow what you're looking for.

rylee2• 11 years ago

`#go-nuts` is a very angry place.

bsuh• 11 years ago

I tried to go there to ask some questions while picking up the language, and what I got was RTFM, where manual includes the language specification, Effective Go book, and A Tour of Go. Apparently you're unfit to ask a question unless you know everything about the language already. Killed my excitement for learning the language.

lobster_johnson15• 11 years ago

What I don't understand is the people who say Go doesn't need generics. Go already has generics: channels, maps, make(), len(), range, etc. are all generic.

Nobody can argue that generics in Go isn't extremely useful. After all, you couldn't have typed channels without generics. One has to be pretty obtuse to argue that the utility afforded by Go's internal generics wouldn't extend to the language as a whole; that somehow Go's standard library needs to be special.

If you look at the standard library, its authors had to jump through some serious hoops in many cases. Packages like "reflect" (the megatype Value), "builtin" and "sort", to pick a few, are a graveyard of typing awkwardness. The sort package and its special function just for sorting strings is practically a written confession.

Generics being a speedbump is an argument I haven't heard before. Can anyone comment on what the performance challenge is? Nim instantiates unique concrete type instances based on their parameters, couldn't Go do the same?

grey-area• 11 years ago

This is a good summary:

https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX...

aws_ls3• 11 years ago

It was early 2013, when we adopted Go as a default language for all our server side (micro or not) services. Before that we had been using Java for some years. The reason for the move were few:

1) Ambivalence on Java roadmap, in my understanding (gradual build up, since after the Oracle's Sun acquisition). Even the earlier clean java docs, suffered from Oracle branding efforts. Downloading older versions were confusing via a long chain of navigation between sites.

2) Boredom after nearly a decade with Java programming.

3) Memory usage of Java in our conditions was much higher compared to other languages (C, C++, Go)

4) Not Java's problem, but whenever one thinks of hosting a HTTP service in Java, thinks of using a container (e.g. tomcat, jetty, Jboss etc.). Go seemed to have made making services very easy. Its possibly just a perception issue, but its there in my experience.

So we wanted to move, and Go looked stable at the time from all my HN readings. C was too bare bones(even string handling was a pain to me, after a gap), and even C++ would not have matched some of the things which Go has inbuilt. Few examples:

1) Json/XML parsing is the easiest with no work (or minimal) required, you can just have the field names capitalized (or use stereotypes) and it gets done, with a line of code.

2) Great HTTP client and server libraries, which make very easy to write your own standalone services, as well as write http crawlers. (I am quite excited that Go 1.6 will have HTTP/2 support for both, as per this birthday blog).

So, in nearly three years of usage, with largely no regrets[1]. It is what they say it is: a bare-bones, fast (both compile & run) and stable (hardly get any errors after you have coded stuff, one of the stablest programming paradigms in error handling, etc).

Thank you, Go team! Hoping to use it for many years, as default server side language.

[1] Some of the 3rd partly libraries, we use are still not ported over to Go. They have Java, C++/C versions.

eterm2• 11 years ago

You based a business decision to switch language on "boredom"?

What size team are you working with, that you were able to switch from Java to Go?

aws_ls3• 11 years ago

Good question. Small team of 2 developers, so I had that kind of luxury, which I am sure is not there when you have larger teams.

nickbauman4• 11 years ago

Yeah odd choice in that Go is a very boring language (and its enthusiasts consider this a feature).

StevePerkins• 11 years ago

If he were honest, I'm sure the weights for each factor really look like this:

* *

* * * *

* * * * * *

(2) (1) (3) (4) (5) (all others)

skrebbel• 11 years ago

Best reason ever!

Just to push a counterpoint, I never understood those startups with foosball tables, sponsored beer, team workaholidays on tropical islands but god forbid the work itself is any fun.

If a technology choice makes people enjoy their work more, learn new things, help them think differently and thus get more creative, then isn't that a big plus? Sure, maybe it does not weigh up to whatever downsides there are, but it counts! The whole idea that "fun" isn't allowed to be an important argument in a business decision feels horribly outdated to me.

scotty792• 11 years ago

You based a business decision to switch language on "boredom"?

Not just boredom but Java induced boredom. In case of Java boredom is symptom not the essence.

coldtea5• 11 years ago

It was early 2013, when we adopted Go as a default language for all our server side (micro or not) services. (...) The reason for the move were few: 1) Ambivalence on Java roadmap

So, because there was some "ambivalence for the Java roadmap", a language with multiple implementations, a huge community (including open source), and so entrenched in the industry that will be there in 2100 too, you switched to a 3-4 year old language with tiny adoption compared to it (outside of echo chambers), an arbitrary roadmap as set by the core team which might involve anything coming the time for a 2.0 release, and whose majority of development depends on a handful of people Google pays their salaries?

aws_ls3• 11 years ago

Lets just put it this way, I bought onto the basic proposition which was offered, after having read Rob Pike's original blog introducing it, and having watched lots of Go team videos. Some points which also went into decision making:

1) I am not a functional language programmer. No disrespect, just stating fact, after having noticed a Lisp programmer having questioned my choice regarding "boredom". So languages like Lisp, etc were out, and had to look for a C like language.

2) My boredom with Java was also because of years of using, YMMV ofcourse. Also we were seeing issues in containers we hosted on, and that entire deployment paradigm seemed liked that of 2000s. As I said, in another reply, thankfully I had the luxury to choose, which is often missing in Enterprisey setups. And my co-programmers were also excited about it.

3) One thing which I forgot to mention in my parent comment is channels. It really appealed to me as a model, compared to the Barrier style of programming in Java's util.concurrent. We use that feature heavily in our now migrated Go services, and its ultra stable.

4) At the time of the switch, I wanted to move to a more bare-bones language, which is C-like. So did some benchmarks with C, C++ and Go. And Go was found to take a little more memory than C/C++, C was the least. But it was good enough. And as a successful validation of the move, I have been able to recently move to AWS compute instances from the standard instances (m3.large -> c3.xlarge to be precise). So we are getting more compute power, by paying roughly equal, because of lower memory requirements.

So I made due effort to find the right language, outside the "echo chambers" you see. And this "echo chamber" is also not so actually, honestly speaking, I learn a lot from guys like you on a regular basis :-)

edit: typo

scotty792• 11 years ago

I guess if you can't see the future, why not make it interesting?

vox_mollis2• 11 years ago

and whose majority of development depends on a handful of people Google pays their salaries

As opposed to the brilliant stewardship of Larry Ellison?

drumdance4• 11 years ago

Ha. I built my first company on Java back in 1996. It was a terrible decision. Very buggy, lots of BS from Sun & Oracle that was really more about Ellison and McNealy envying Bill Gates. Netscape made a similarly bad decision when they tried to create a pure Java version of the browser.

I'm sure Java is 10x better now, but I'm not convinced it will be here in 2100.

atmosx• 11 years ago

Well, one of those guys who designed the language is Ken Thompson.

That says something about the language to me.

You have a point but they seem pretty happy with their choice.

I believe that happy developers are more important than the tech stack.

donatj• 11 years ago

If Java is still around in 2100 I weep for how little progress was made.

rodgerd• 11 years ago

a language with multiple implementations,

Yeah, where the owner is suing one of those multiple implementations, and playing silly buggers with J2EE certification. That really lends a fuckton of conifidence.

jimbokun• 11 years ago

You left out the key reason cited:

"2) Boredom after nearly a decade with Java programming."

chimeracoder• 11 years ago

1) Json/XML parsing is the easiest with no work (or minimal) required, you can just have the field names capitalized (or use stereotypes) and it gets done, with a line of code.

Obligatory plug - if you're sick of writing out the struct definitions yourself, you can generate them from sample JSON: https://github.com/ChimeraCoder/gojson

This is especially useful when implementing REST servers/clients, because you can simply include an example JSON response which your tests use, and then use `go generate` to autogenerate the struct. Since they're both based on the same file, you don't have to worry about keeping them in sync - if there are any changes to the response structure, you only have to update it in one place.

elcct6• 11 years ago

That is cool! Thanks

jaytaylor• 11 years ago

I've used gojson several times and highly recommend it. Originally I'd planned to make the tool myself but found you'd already created precisely what I envisioned!

/me tips hat to you :)

pjc50• 11 years ago

4) is actually quite important. People wonder why PHP is so popular, and it's because the deployment overhead is tiny compared to, say, Tomcat. Especially on shared hosting.

arbe• 11 years ago

honestly I have hard time comparing go to java and finding any valuable reason to switch from one to another.

Go in my opinion was not mean for writing large/distributed web applications. But instead for writing tools (and fits very nicely in that space) and therefore replace C code base.

If I had to write something like docker, go of course would be a natural choice for it. But If I had to write the next big social network, well Java would be the natural choice.

Java has a much larger community, libraries, tools, ide and a whole ecosystem that makes Java and JVM a solid platform for writing application at scale (large team, large code base).

Roboprog2• 11 years ago

MAYBE. But maybe not: what if your app has a Javascript based rich client, and the back end is primarily micro-services? Does Java still shine for that kind of a stack? (OK, I would still avoid C, but that's not saying much)

yandrypozo• 11 years ago

Thanks for your comment! Thanks Go team !

kitd• 11 years ago

Go is a great language. Building REST servers in Go is a doddle and the related tools have obviously been designed to work well together from the outset which is unusual.

That said, I started learning D at about the same time as Go, and for some reason D has attracted me more. Possibly the C ABI compliance (I was doing some JNI work at the time).

One question that I haven't found the answer to yet though is how well Go apps perform for long running processes, eg weeks or months? Have there been any issues around memory usage or resource handling? Any need for restarts?

pdappollonio• 11 years ago

Go websites are essentially long running processes. I have several websites built in Go, all of them running for about 2 months already with no hiccups.

spotman2• 11 years ago

I can echo this. Have some go processes that have currently been running for over 6 months.

Gurrewe• 11 years ago

I have been running multiple instances of the same Go app on multiple servers without it ever crashing for about a year. The current uptime (since the last release) is about 4 months, no issues at all, and very low resource usage.

GrandTheftR2• 11 years ago

Thanks you, Go team!

Have been using Go for the last few years, from backend, tools, and even complex scripting type of tasks (for things more than I would like to do in Bash). Start using Go for game development as sideline projects recently, it is fun.

Granted there are things I would like to see may not on the road map, but I am very happy with what we have now, the great tools, and the great community.

Keep up good work and looking forward to the future releases!

cdnsteve• 11 years ago

I would have used Go for an API recently until I found out the AWS SDK for Go isn't production ready. Libraries still have some catching up to do but will only get better with more time and testing.

no1youknowz• 11 years ago

I've been working on a huge monolithic project (for 1 person) for the better part of 2 years now. It is in PHP, but the backend segments ported over to various other languages like python, javascript(nodejs), and now to Go.

Having now developed 30 micro-services for Go, which all utilise channels and thus run much faster than any other language I used is just amazing.

Not only has my productivity increased majorly, but also my support time has rapidly decreased.

These micro-services which run in the background just work:

- With PHP they don't run out of memory or the database connection doesn't time out.

- With Python I don't get random crashes due to pool.map.

- With NodeJS I don't have to run multiple instances to get the speed.

I've looked at web frameworks like beego, gin, revel and others. But I'm waiting till something comes out that's more inline with what I have used with PHP. Something like slim framework.

If it ever does come out, it will give me the push to switch 100% to Go. Can't wait really.

tenken• 11 years ago

Having now developed 30 micro-services for Go, which all utilise channels and thus run much faster than any other language I used is just amazing.

Any public code examples ?

placeybordeaux2• 11 years ago

I tried gin, martini and revel and found myself reaching to go back to largely the stdlib after about 6 months of development.

The stdlib with a couple convience functions really is quite good.

elcct6• 11 years ago

Me too. I found that most frameworks actually get in a way instead of helping. stdlib FTW

moehm• 11 years ago

Have you tried the gorilla toolkit?

http://www.gorillatoolkit.org/

https://github.com/gorilla/

japhyr2• 11 years ago

I've never used Go before, so I went to the project's home page. There's an editing window on the home page with a sample program showing, and a few other programs available in a drop down list. I couldn't help but start playing with the language.

I wonder how much the simple presence of an editing window on a language's home page contributes to overall adoption of the language. It sure lowers the bar to "I'll just write a few lines of code and see how this language feels."

ionforce• 11 years ago

Does anyone know how it works? Like does it make requests to a service or is it running in the browser, JS style?

rubenv• 11 years ago

It's the same stuff that powers the playground: http://play.golang.org/

More info here: http://blog.golang.org/playground

japhyr2• 11 years ago

There's a section called A Tour of Go [0] which has a series of code samples with explanations. The last part of the introduction to the tour says a little about what they call the Go playground [1]:

"This tour is built atop the Go Playground, a web service that runs on golang.org's servers.

The service receives a Go program, compiles, links, and runs the program inside a sandbox, then returns the output."

[0] https://tour.golang.org/welcome/1 [1] - https://tour.golang.org/welcome/4

citruspi• 11 years ago

It makes requests to a backend service. You can read more about the implementation of the Go Playground on the blog[0].

[0] https://blog.golang.org/playground

brobinson• 11 years ago

Rust has a similar feature on its homepage: https://www.rust-lang.org

Let's hope this becomes a trend!

baconizer• 11 years ago

All I can say in words is - thank you.

vegancap• 11 years ago

Go made me excited about programming again. Love it.

benreic2• 11 years ago

I'm surprised to not see any mention in the comments about the biggest change coming in 1.6: the package vendoring mechanism. This has been a big missing piece for awhile and I'm glad they're addressing it in an official way.

I was super excited for the cross compilation abilities on Go 1.5 and now I have something else to be super excited for in Go 1.6, can't wait!

dilap5• 11 years ago

I was confused by that. Is this going to be any different than GO15VENDOREXPERIMENT which we have now?

benreic2• 11 years ago

I guess I was hoping for a composer-like versioning system, but I suppose that's not a given?

acomjean2• 11 years ago

I've started working in Bioinformatics. The languages in use and libraries seem to by Perl/Python and some java. Except for the stuff that needs to be fast, then its C. Although I notice some movement to use Rust instead of C (having installed some C based tools having package management would be glorious).

It would seem the concurency model of go would be a great fit for a lot of those existing python/perl tools. My searchingg for projects show it hasn't really taken off in this domain. I might start rolling my own packages.

How is the package management in Go? Data structures and String manipulation? And is does that concurency scale across nodes (al la MPI)?

biomcgary2• 11 years ago

I'm a computational biologist that recently ported our webserver (genestation.org) from Tripal (PHP/Drupal) to Go. The performance gains were huge, but the simplicity of development and deployment was even better. I'd strongly recommend Go for a biology web server. However, Biogo is not remotely as far along as Biopython or Bioperl. Also, Perl beats Go for ease of string handling. Unfortunately, there is no equivalent to Numpy/Scipy in Go. Despite these areas of weakness in the ecosystem, I have switched to Go entirely except for one-liners and one-off parsing in Perl.

acomjean2• 11 years ago

Thanks. They new site is snappy.

Tripal I had never heard of. It uses "Chado" db schema which I have heard of (though flybase) which while flexible isn't always performant.

Performance gains and simplified development are so appealing (I have 12 tools to maintain in Java/perl/php)..

Biogo is what I was looking for. https://github.com/biogo/biogo

howeman2• 11 years ago

Unfortunately, there is no equivalent to Numpy/Scipy in Go.

We're trying! https://groups.google.com/forum/#!forum/gonum-dev github.com/gonum . Bug reports and contributions encouraged.

elcct6• 11 years ago

I have written tons of services in Go. What I love about it is stability. Services written in Go are rock solid.

matthewmacleod7• 11 years ago

I have a bit of a love-hate relationship going on with Go.

On one hand, it addresses many of the pain points I've experienced with other languages. It's easy to build and deploy, reasonably performant, and has a powerful and consistent standard library.

On the other… developing in it feels like a total slog. It manages to be simultaneously far too anal and overly forgiving about syntax. Visibility definition using upper/lowercase is a shite idea. Package names (and packaging generally) are a mess. Magical built-in globals are a huge design smell. The lack of generics, as cliché a complaint as it is, results in loads of duplicated or generated code when building anything more complex than the simplest app. And so on.

I find the whole experience of using it to be unpleasant (rather like using a blunt knife), and yet it fits a set of requirements that mean I keep developing new projects using it – particularly high-performance small services that do things like fling JSON around, for which the built-in HTTP libraries + Gin are brilliant.

I'm looking forward to the point that a (trans|com)piler which smooths over the bad parts is available.

arxpoetica• 11 years ago

CoffeeScript for Go? ;)

k__• 11 years ago

After using LiveScript I wished there was a transpiler for every language to get LiveScript syntax in there...

beering• 11 years ago

Agreed. All of Go's deficiencies are not deal breakers when it is so well suited to network services that shuffle data around. I wouldn't build lots of business logic in Go, but often I just need to proxy data from point A to point B with some data massaging.

bkeroack• 11 years ago

You either "get" Go or you don't. Which shouldn't be surprising given that it is a very opinionated language.

A diagnostic indicator is whether you gravitate towards things like Martini or Gin, which aren't idiomatic Go and seem designed to ease the pain of using Go for those who don't actually care for it much.

lobster_johnson15• 11 years ago

But it's possible to "get" Go and also disagree with its design decisions.

spotman2• 11 years ago

Curious your opinion on what you would advise if not Martini or Gin?

I love martini (and lately gin) and definitely love and use go every day. What about these frameworks is not idiomatic go?

Is there another framework that is? Or you suggest just rolling your own using net/http by itself?

Cheers

Meekro• 11 years ago

After a day of writing Go, I certainly gravitate towards martini and gin!

matthewmacleod7• 11 years ago

I see what you're saying, but I absolutely "get" what Go is doing – you're right that I don't care for the idiomatic approach that much!

I have enjoyed the gin API. In maybe 10 lines of code, I can build a fast HTTP service that can serve up a small single-page app. The same thing using e.g. Negroni feels like I'm writing more boilerplate for no apparent gain – and I'm a great opponent of writing boilerplate code.

lobster_johnson15• 11 years ago

I'm in the same boat. Go's simplicity is initially refreshing, then a huge pain once you find yourself writing the same thing over and over again.

A good example is errors being values — which is a great idea. But then you realize every single function needs to be littered 1-10 cases of

  if err != nil {
    return nil, err
  }

It's an extremely common pattern. It's tiring to write, over and over. Tiring to refactor, too: If you change a signature (to add an error, or add another return value, for example), every error check has to be updated.

Unfortunately, Go doesn't offer any abstractions that might allow you to avoid such boilerplate. Functions that return errors cannot ever be chained, for example: If you have "func bar() (MyStruct, error)", you cannot do "foo(bar())". You must always assign the result to an intermediate variable. You could embed the error in the MyStruct struct instead, but that goes against Go's grain.

I find myself wishing for some magic macro that is smart enough to extract a value and return the error for me. Something like:

  try! value, err := bar()

...would expand to:

  value, err := bar()
  if err != nil {
    return
  }

I'm with you on upper/lower-case names. It results in schizophrenic-looking programs. Unless I'm writing a library, I tend to just export anything that isn't obviously an internal implementation detail, for consistency.

I'm also up in arms about ":=" assignment behaviour. I've run into several bugs caused by shadowing inside blocks. You have to be careful when refactoring so as not to cause shadowing issues; really, editors should have their syntax highlighting set to highlight ":=" in blinking bright yellow or something. It's so hard to miss.

It's also inconsistent with how you (or, at least, I) want it to behave. It will shadow existing variables by default if there is at least one new variable on the left-hand side, but that's the least conservative behaviour, and feels contrary to Go's strictness — a language, after all, that considers unused imports to be a compilation error. Recently I've started avoiding ":=" in favour of vars, just to avoid falling into that trap by accident.

To be fair, I love many aspects of Go: Compilation speed, relative performance, ease of concurrency, static strictness. But after working with Go for a while and being quite productive with it, I'm at the same time seriously pining for a better language to replace it.

plexicle• 11 years ago

I'm not an expert in Go, but can't you inline a statement before the conditional?

  value, err := bar(); err {
    // there was an error
  }

I like how that looks, personally. Obviously YMMV.

vruiz• 11 years ago

If you have "func bar() (MyStruct, error)", you cannot do "foo(bar())". You must always assign the result to an intermediate variable. You could embed the error in the MyStruct struct instead, but that goes against Go's grain.

Chaining does work, but obviously the function needs the same signature as the return values, which limits things since most APIs don't accept errors as input. But within your code you can structure it to get error values for things you know you will be chaining. Or create wrappers to make your types chainable.

http://play.golang.org/p/5LHXdJlfIM

pconner2• 11 years ago

Have you seen this blog post by Rob Pike?

https://blog.golang.org/errors-are-values

jonesb63• 11 years ago

If there a paradigm for handling multiple potential errors in a function?

I'm usually stuck using:

  reply, err := redis.Givemethevalue(key)

  if err != nil {
    return err
  }

  thing, err2 := postgres.getById(reply)

  if err2 != nil {
    return err2
  }

czbond• 11 years ago

I agree, but i create Fatal and not fatal functions.

func checkErrPanic(err error) { if err != nil { panic(err) } }

func checkErrNonFatal(err error) { if err != nil { fmt.Println(err) return } }

mixmastamyk• 11 years ago

It's odd, they've written that they were influenced by Pascal, which is where the operator " := " comes from. But it doesn't work quite right in golang...

In Pascal you would use := every time you wanted to assign a variable, and a single equals when testing, such as "if (x = 5) then...". It is slightly more like math than most languages, which I appreciated. But, golang only allows it on the first assignment, the reasoning perhaps that it is a declaration?

I don't feel that this third way of doing it with no advantage was a benefit, choosing one C of Pascal rules would have been better and less to think about.

tptacek14• 11 years ago

I felt very much the same way about Go's error handling; that, coupled with straight-line synchronous-style socket programming, made me feel like I was writing the same dumb C code I did when I was a teenager in the mid-90s.

I've come to believe that slicker error handling is a bit of a false economy, at least compared to other "informal" languages like Java, Ruby, and Python (all bets are off if you want to compare Go to Haskell; I concede everything in advance there).

I feel like a lot of Java and (especially) Python/Ruby code is easier to read... until it matures enough to handle errors properly, at which point its just as crudded up. It's much easier to start sketching out code in Ruby and wrapping everything in blanket try/rescue blocks. But that code always breaks and always gets trickier before it's ready to ship.

Lots of people I've talked to have had the same experience coming off C, Ruby, and Python as I have: when the Go compiler stops spitting out errors, your program tends to work --- usually not perfectly, but still far better than a first-run Ruby or C program does!

Also, when people think about Go error handling compared to Ruby and Python, they rarely factor in the density of unit tests required for the Ruby and Python code.

codemac• 11 years ago

particularly high-performance small services that do things like fling JSON around

:/ Their json system reflects and allocates like a mad-man. It's probably one of the slowest parts of the std library.

lobster_johnson15• 11 years ago

Do you know of a faster JSON library? I've been struggling with this. My particular use case is that I don't want any fancy struct unmarshaling; I just want the equivalent of map[string]interface{}.

matthewmacleod7• 11 years ago

Yes, this is a good point (and I've hit this in the builtin XML unmarshalling too). I should point out I'm mostly looking at go in comparison with Ruby rather than the C, so the JSON implementation is still high-performance by that metric :)

skybrian• 11 years ago

I'm skeptical that "feels like a slog" has much to do with language features you complain about. Better IDE support would go a long way here.

Java can be terribly verbose at times and the culture often makes it worse, but it often doesn't feel like a slog in practice because errors are reported as you type, with quick fixes. Editor plugins for Go will tell you some of the errors, some of the time.

matthewmacleod7• 11 years ago

I'm not sure about that. I don't tend to use an IDE, but the Go plugins for Sublime seem to do a pretty good job of identifying unidiomatic code and errors even before saving, which is certainly a benefit. Gofmt is fabulous.

The slog seems to be in the frequent feeling of 'why do I have to do this – surely the computer should be doing it for me?'. This is mostly around things like list comprehension, where it feels like using stone-age tools. It sucks, because the development story around e.g. goroutines and channels is so elegant in comparison.

eluusive• 11 years ago

You really should check out vibed. It meets most of hte requirements of slinging JSON around, being easy to build and deploy, has a powerful and consistent library. And it's not terrible to work in: http://vibed.org

tptacek14• 11 years ago

It's like most languages: if you go in hoping to write in the style of your favorite previous language, the language is going to resist you. Python does the same thing to you if you want to write in functional style. Ruby also punishes you if you want custom data structures (it's the Rails community that coined the term "golden path", right?). If you've got loads of duplicated code due to lack of generics, you may not be leaning as much on the design of the standard library as the language wants you to.

We've got a limit-order-book market with a FIX API and an HTTPS/JSON API, a bunch of market makers, an AVR emulator, a dispatcher to handle thousands of AVRs concurrently, a C compiler, HTTPS/JSON APIs to implement debug stubs for all of that, and a bunch of other random stuff --- and we have one (1) custom data structure --- the red-black tree we use for the order books themselves.

I'm a recovering C++ programmer and do not doubt for a moment that if Go had generics, I'd have availed myself of them. I'm not sure my code would be better for it, though.

existencebox• 11 years ago

I don't disagree with your conclusion necessarily, especially given that I'm speaking from a position of ignorance with respect to Go, but I'm surprised by your statement about python and functional style. Coming from Ocaml, I found python to be one of the more accommodating languages in terms of maintaining the style I had built up in the former. (I do certainly acknowledge many examples for which this contradicts, immutability being a major point, but I can think of more situations where I was able to use similar design patterns than when I wasn't.) What in particular did you find lacking?

This all may be the ramblings of someone basing their opinions on "code I've written that has worked" and not on some higher standard of design patterns, so feel free to ignore if that's not productive :)

This ties into other thoughts I have rattling around about treating languages as specialty tools with well prescribed patterns, vs the trend to implement some subset of common lisp as the saying goes, but not well formulated enough to expound on them here. Broadly; I'm not sure which paradigm I prefer. (Having a big toolbox of specialty tools is nice, but if one tool can easily eat the functionality of another tool, I tend to side on considering that option.)

kasey_junk5• 11 years ago

Your code in Go almost certainly does use generics. Just not user defined ones. I don't particularly want to argue the generic point as I believe it is beat to death. But I could use a good concurrent map in Go in dozens if not hundreds of places.

I could use a lock free ring buffer in dozens of places. I could use promise/futures in dozens of places. I could use anything but the big honking lock that is channels in dozens of places.

I could use proper variance rules in the generics Go does provide in dozens of places. I could use monadic style errors and options in dozens of places.

Now, I agree that I generally don't need to write my own generic code very often, but if the blessed generic writers on the go lang compiler team don't write these things for me, I don't have a fall back option in Go (other than code gen, which people are starting to fall back on). It just seems unsustainable to me.

matthewmacleod7• 11 years ago

I agree to some extent; different languages require different coding styles – that's totally fine. But that doesn't mean that there aren't valuable features to be taken from other languages, nor that they the language's design doesn't have problems. I strongly feel we should resist the temptation to believe that just because an idiomatic design design exists means there is no room for the language to become even better!

I won't harp on about generics in Go, because I think it's far from the biggest issue – but the hardcoded magic generics show that such a feature is useful. I'd love a simple set implementation, for example – but I often find myself reduced to writing dumb, ugly, difficult-to-read code to work around the fact that it's not possible.

SICP famously says "programs must be written for people to read, and only incidentally for machines to execute." And I can't help but feel, whenever I'm writing Go, that I'm spending far too much time telling the computer what to do – and nowhere near enough telling future developers what I wanted to do.

Sevzinn• 11 years ago

Perhaps you are not smart enough.

ogezi• 11 years ago

Golang and I have had a mainly wonderful relationship. I think that the performance and concurrency features that it brings to the table are unparalleled. No that Golang is just 6 years old and probably has a few more decades of relevance. Although they need to do something about the compilers as the compiled binaries get more bloated with each release.

nodivbyzero• 11 years ago

Happy anniversary.

I replaced python with go in my projects and i'm so happy!!!

xenihn• 11 years ago

Anyone happen to have a link to a good guide/tutorial for building a mobile backend in Go with gin? Or know of a public github repository with a good sample project. I've never done any backend work, and I'd like to build a backend for a simple iOS app to start.

fixermark5• 11 years ago

I recently implemented a RESTful resource mapper in go, which just accepts some basic parameters and an exemplar of a storable structure and wires up all the HTTP endpoints necessary to give users CRUD access to the resource.

I'm honestly very happy with how straightforward it was, even lacking generics---I solved the problem of no generics by basing the resource creation and management on JSON and a "Storable" interface that just defines key() and newEmpty() methods (so I have to write five lines of boilerplate for every struct that will be a resource... shrug). I didn't parameterize the storage logic, basing it on only a single NoSQL backend (BoltDB); however, parameterizing that side shouldn't be harder than wrapping the database access behind another interface.

I like the ability to switch between tight static typechecking and freer runtime typechecking on-the-fly, without having to build a large, complicated framework for either within the language. It may not be the most innovative language of the decade, but I think it's a pretty good combination of features for practical, high-performance web server development.

jstoiko• 11 years ago

Would you care to share some code example?

fixermark5• 11 years ago

Happy to; I'll share the whole thing.

http://pastebin.com/qBh6NRXc

It's not cleaned up for easy reading (hell, I haven't even run `go fmt` on it ;) ). But it has unit tests and seems to work. ;)

One thing worth noting is that it relies on the Storables to also be tagged with necessary JSON. It occurs to me that I could also have used tags instead of the key() function in the interface to specify which field in the Storable should be the resource name; key() is a bit more flexible in that the function could calculate the name using any method though.

jonesb63• 11 years ago

I've used Go for a couple years but am only just writing my first production system in Go. I think one of the major complaints is that it's use-cases are ambiguous to beginners. Go, IMO, is a systems language and should not be the first thing you pull out when someone says "write a web app".

I think Go has a very limited use case, but it is incredibly good for that use case. If I had to define it right now it would be along the lines of "Highly concurrent micro-services (re: small code bases) that requires decent performance (memory + speed) in a somewhat distributed fashion". Obviously it's not perfect but it's the feeling I've developed recently.

jayflux• 11 years ago

Really agree with this. Its not my go-to language for many things that could be done with a simple script, but its good to have it in the toolbox when i do have those sort of problems. I think if i was writing a high-performance API i would use Go

aikah• 11 years ago

Go started as a niche language and worked well for that niche, but like all niche techs that become dependencies, they tend to get bigger overtime. Go success is undeniable and is reaching a critical mass where there will be no going back.

There are alternatives but most of them aren't backed by a big corp like Google, so they will have to succeed in their respective niche before getting widely adopted. I wish that wasn't the case cause languages like D,Nim or Crystal are really good and way more enjoyable to write in my opinion. Out of all of these(including Go) one will be the next big language, no question as people move from dynamic or VM backed languages (for good reasons).

pythonist• 11 years ago

Thank you! Go has made me enjoy programming once again.

lilinmeng• 11 years ago

呵呵

Six years of Go

Related Stories