Hacker News new | comments | show | ask | jobs | submit login
Go 1.1 beta 1 Released (groups.google.com)
161 points by geetarista 1341 days ago | hide | past | web | 181 comments | favorite



I think this is an amazing milestone; I contributed to Go in the early phases and was very excited about the project. I even had Rob Pike OK some of my patches (which was a huge nerd ego boost, obviously).

However, the direction the language took ended up being quite predictable and somewhat of a bore. The problem with Go is that it doesn't seem to fit any particular niche. Some other design decisions were questionable (no exception handling, for one).

I kind of like Go, but I haven't used it for years. There's no real reason to NOT write something in C (or, rarely, C++) or Java, or if I need some serious scaling, Erlang (or just use either something like libevent for C or Kilim for Java).

Go is very D-like. D, like Go, can't really find its niche. If Go or D were more idiomatic, perhaps they would be adopted in early programming classes (high schools and colleges -- like Python, for example), but even though goroutines, channels, and fast compilation are interesting concepts, they aren't really enough to detract from writing in the many other languages that do just about the same thing (and are a lot more popular).


Have you used it since 3 days after it was launched, more than three years ago? (That's when you contributed.)

The language, libraries, and ecosystem are miles ahead of where they were back in 2009.

Why not use C? Because C has no sensible packaging system, is unsafe, requires manual memory management, and offers a degree of control that is unnecessary for most tasks. Why not use Java? Because it is verbose and picky and basically forces you to use an IDE to get anything done, etc etc. If there were nothing wrong with these languages (they're the main ones we use at Google) we wouldn't have developed Go.

Use Go more! You'll see why people love it, and why we created it.


I'd love to use Go to replace some projects I've written in C and Java.

I evaluated Go last week (2013-03), but there is no meaningful Eclipse IDE support. goclipse doesn't work half as well as CDT, and not a patch on JDT.

I won't move away from eclipse workflows and project management, the context switch is more expensive than any language benefit.

I'll keep checking for comprehensive Go support in Eclipse, but until then it is a showstopper.


I use GolangIDE[1] after getting fed up with Eclipse. It's really nice as it's a much lower memory footprint, yet basically does everything you need an IDE to do (ie edit code, debug, etc)

[1] http://code.google.com/p/golangide/


I second the recommendation for LiteIDE

More common main page: http://code.google.com/p/liteide/ Downloads: http://code.google.com/p/golangide/downloads/list Code: https://github.com/visualfc/liteide


Third. It works and is actively being developed.


Obviously you're free to make your tool choices however suits you, but I think you are putting a pretty severe artificial limit on what tools you'll be able to use by basing so much of your analysis on deep Eclipse compatibility.

You're letting your tool own you rather than you owning your tool.


I write go in eclipse and the experience is pleasant. What is the showstopper for you?


Debug attach points are basically just gdb (okay for a simple app, but needs to be in debug perspective to compete with CDT, JDT )

Autocomplete / suggest broken on Windows. There is something about a fix by running an external server. I gave this a go, sending a few hours piecing together forum comments, but couldn't get it to work 100%.


I am one of the owners of the GoClipse plugin you are referencing. I apologize if you feel frustrated by the user experience on windows and I am glad you found a workable alternative. I always hoped to make GoClipse more of a community project where developers would improve it as they ran into issues, but most of the time people seem to be too busy. That has been my problem as well; too much to do with too little time.

edit: oops, I misread your comment. At first, I thought you found an alternative. I'd be open to working with you to improve the experience. I do not use windows personally.


"There is something about a fix by running an external server"

It is called gocode (https://github.com/nsf/gocode). Pretty much all Go environments require gocode - the directions for Eclipse (which I don't use anymore) are pretty clear too: http://code.google.com/p/goclipse/wiki/GocodeIntegration


Those are the instructions that I followed... look at the bottom and you'll see 27 confused comments. It works for some, not others (myself included)

At some stage the context switch becomes too high and you give up. As I said "meaningful Eclipse Support", and digging around to get gocode working harms this effort.


You addressed two of those questions, but what I really, really want to know is the answer to the third one. Why not use Erlang? It seems like the kind of thing Google would like, and yet I'm not familiar with any Google projects done in it.


Erlang is a very different paradigm of language. It's much easier for someone familiar with C++ or Java to learn Go than it would be to learn Erlang.

Erlang has a great concurrency model, but it's fairly clumsy for writing procedural code of any complexity, which makes it harder to pick up too.


While I do like me some Erlang, anybody would admit it has some rough spots. The big two that come to mind are awkward syntax and the inability to number crunch. Lest we forget, Erlang is declarative/functional and is a significant paradigm change for most programmers.


The error messages are an additional rough spot.


>The language, libraries, and ecosystem are miles ahead of where they were back in 2009.

The libraries maybe (and the runtime). The language, as per semantics and syntax, is more or less the same.

>Why not use C? Because C has no sensible packaging system, is unsafe, requires manual memory management, and offers a degree of control that is unnecessary for most tasks.

But is absolutely essential for most tasks C is used. For all the others, why not use a higher level language like Python?

>Why not use Java? Because it is verbose and picky and basically forces you to use an IDE to get anything done, etc etc.

Some people are not "forced": they choose to use an IDE, and wouldn't have it any other way. It is like telling some Smalltalk guy: "Smalltalk forces you to use the smalltalk image editor/environment" -- so what? He is perfectly fine with it. Heck, lots of people even like using dynamic languages with an IDE (and more would, if there was better type inference and assistance).

>If there were nothing wrong with these languages (they're the main ones we use at Google) we wouldn't have developed Go.

Well, the main reasons for Go, as stated in the official pages (the Golang FAQ), are not very convincing or exciting: No header files, faster compilation, parallelism, garbage collection, lighter type usage.


>But is absolutely essential for most tasks C is used. For all the others, why not use a higher level language like Python?

What C programs are you thinking of? Thinking of significant C programs that I have used (bash, apache, gcc, and many more), I can only think of a few that wouldn't be easier to write and maintain were they written in Go, without suffering a meaningful performance penalty. Funnily enough, a lot of the uptake of Go has been from former users of Python, Ruby, and other dynamic languages; they attracted to Go's simplicity, safety, and speed.

But really there's a lot more to Go the faulty dichotomy of "dynamic vs static" (or Python vs C, whatever). This is worh reading: http://talks.golang.org/2012/splash.article

>lots of people even like using dynamic languages with an IDE

Agreed, and I have nothing against IDEs. I have just found that I can't comfortably write Java code by hand. There's way too much boilerplate. In my experience an IDE is essential writing Java code efficiently, and I don't think that's a good thing.

>not very convincing or exciting

Depends on your definition of exciting. Since I've been writing Go code I've been more excited about programming than ever before.


You'd really be OK with gcc being 2-3x slower?

As much as I love high-level programming, many of the most interesting and important problems are ones where a "small" constant factor is the difference between great and mediocre.


I don't think it would be 2-3x slower.


Why thought? By all we know, it would be.

On most algorithmic benchmarks Go is 2-3 or more times slower than C/C++.

And parsing something like a large C++ codebase with a GC language like Go would result in tons of memory used (and slowness).

Heck, even Go compiling Go programs gets OOM'ed sometimes in Linux.


To be fair, I haven't used it since 2011 and I'm sure a lot has changed. I've read plenty of valid criticisms however which (after having used it for several projects) deterred me from using it again.

For a project a couple of years ago, I needed to use OpenCV and the Go bindings were quite immature. I just switched to C++ (for that project) and never really returned.

But now that I think about it, whenever people that are interested in being introduced to coding (it happens a lot on campus) ask me "what language should I learn?" I've never answered Go. I'm not sure if most people would.


While I don't think it's really a harsh criticism to say that Go shouldn't be your first language... I'd be interested to know what you think a good first language would be.

Certainly not C or C++, if you're discounting Go. I'd also discount Java and C#, since they're syntactically quite similar to Go. Certainly not erlang.

So... python? ruby? While I like those languages, I feel that the lack of a compiler is a pretty big hindrance to new programmers. Statically typed languages can catch many errors that produce some truly strange error messages in dynamic languages.


Honestly, I mostly share(d) your opinion, but am starting to see Go in a different light. The problem is that the community pitches it against C/C++, where Go, with its GC, just doesn't fit well, and Java, whose runtime and libraries is still miles ahead (fast GC, for one).

However, Go seems to be very good at what Python/Ruby/Node.js/Perl are good at. It provides a simple, clean language with more guarantees and better runtime (mainly the cheap goroutines). I see Go taking some of their role for web development, simple tools (Go programs produce a single binary - very easy to distribute).


I think you may be right, and I completely understand the problematic benchmarks that always crop up. I don't pretend I'm smarter than the people at Google (because I'm not), but some questionable decisions were made (there's plenty of literature out there written by reputable people) -- and I think that's why Go hasn't seen more of the lime light.

Apart from Google (who uses it for Youtube), Go hasn't really been used in large projects. Maybe 1.1 will change that. I might give it another shot, too!


> Apart from Google (who uses it for Youtube), Go hasn't really been used in large projects.

I don't know how large each of these projects is, but a growing number of companies are using it for serious projects:

Iron.io: How We Went from 30 Servers to 2 with Go http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2...

Behind the Scenes: Big Data at Torbit http://torbit.com/blog/2013/02/19/big-data-at-torbit/

pool.ntp.org DNS server in Go http://news.ntppool.org/2012/10/new-dns-server.html

Juju at Canonical http://www.reddit.com/r/programming/comments/18atce/juju_can...

Go at bitly http://word.bitly.com/post/29550171827/go-go-gadget

CloudFlare blows hole in laws of Web physics with Go and Railgun http://arstechnica.com/information-technology/2013/02/cloudf...

dl.google.com now served by Go https://groups.google.com/forum/?fromgroups=#!topic/golang-n...

Go At Conformal https://www.cyphertite.com/blog.php?/archives/7-Go-at-Confor...

Go at Novartis https://plus.google.com/114945221884326152379/posts/d1SVaqkR...

Go at the BBC http://www.quora.com/Go-programming-language/Is-Google-Go-re...

Go at SoundCloud http://backstage.soundcloud.com/2012/07/go-at-soundcloud/

Go at CloudFlare http://blog.cloudflare.com/go-at-cloudflare

Go at Heroku http://blog.golang.org/2011/04/go-at-heroku.html

Building StatHat with Go http://blog.golang.org/2011/12/building-stathat-with-go.html


Has a claim as coarse-grained as "There's no real reason to not write something in C" ever made any sense past the immediate attention-bait value? I mean, different languages have different use cases and you can't pretend to make a case for a language on your own perception of it, let's be serious a second.


I suspect that the kind of scaling Go was intended for was programming scale. A lot of the design of the language seems specific for large scale projects (statically compiling everything, not having unused variables, explicitly naming all imports, fast compiler, test and benchmarking as builtins, code changing via go fix).

These are problems I have seen with larger java projects with unused imports, unused variables, library dependencies, long compile times, etc. I think that Go's niche is for extremely large projects, but it remains to be seen if it will work.


> I suspect that the kind of scaling Go was intended for was programming scale.

Your suspicions are well-founded! http://talks.golang.org/2012/splash.article


> Go is very D-like.

I think it's very D-unlike. It's very small and simple.


I agree Go and D really can't find its niche. They both are very interesting languages, but is there any really impressive application where those languages would rock? Something that when asked for, the only obvious answer would be "use Go"? Being a better C or a better C++ is IMHO not enough.

Want high performance and full control? Use C (or C++). Want your code to be easy to maintain by an average Joe? Use Java or C#. Want your code to be concise? Use Clojure. Want extreme typesafety? Use Haskell. Need to use both OOP and FP? Use Scala. What question to ask so the obvious answer would be "Use Go?"


>What question to ask so the obvious answer would be "Use Go?"

I basically see it as a midpoint between C and python, that offers most advantages of both.

From C: Low memory use, fast execution, type safety/ compiled.

From python: Easy/fast to learn/read/write, no slow compile, GC, memory safety, good standard libraries

It also does concurrency better than python (/anything else?). What would you say better fits these criteria? Certainly not the JVM languages (memory) or Haskell (accessibility).


Go is a low level language compared to Haskell though. It's like walking back to 1982.


Go is a low level language compared to Haskell though. It's like walking back to 1982.

I was immediately dismissive of Go when I first heard of it a few years ago. I only started looking at it again a couple months ago when I ran across the 'splash' article. [1] The attention to detail with regards to the language, the standard library and the tooling really impressed me.

Yes, in many ways Go is low level. It doesn't break much new ground from a programming language design perspective. It doesn't provide a lot of features, but what it does have is well integrated. At every turn, language features were added or left out based on the larger software engineering perspective, rather than what can produce the most succinct or elegant code.

[1] http://talks.golang.org/2012/splash.article


    What question to ask so the obvious answer would 
    be "Use Go?"
Writing services in a SOA tech stack.


Go is C programming for the average Joe.


I kind of agree with you (being an 'average Joe'?), but surely Go offers some advantages over C even for a C programmer; faster to write and compile, more readable code, concurrency, memory safety.


Except those advantages were already possible back in 1978 with Modula-2, nothing new.


If it helps bringing these advantages to modern day programmers then I'm all for it. A lot has been lost during the 90's with the rise of C++ and Java.


I agree, but I see Rust, D or even C# better suited for that purpose as Go, since it throws too much away.


What's the Modula-2 equivalent of the goroutine concurrency primitive?


Co-routines, Modula-2 was one of the first languages to have native support for such constructs.

The only things that Go has over Modula-2 are interfaces, single declaration modules and GC.

Single declaration modules and GC were part of Modula-2 successor, Oberon in 1986, while Active Oberon in 2001 added Tasks and Interfaces to the Oberon language family.

All of these languages were used to built operating systems used for real work at Zurich's Technical University.


Yep, I miss me some M2. That's the most satisfying programming I've experienced so far.


"easy to maintain by an average Joe" and "Java" don't belong together


Seen any other language used and maintained by more average Joes?

Because that's exactly one of the niches of Java -- enterprise programming by average Joes. It was even a stated design goal of the language back in the day.


Lack of exception handling is the biggest reason I haven't used Go for much. The other reasons are that it's just so plain/boring (yes, I know that's subjective), nothing about the syntax is interesting. Learning go is like eating cardboard. The other issues are that IDE support is very primitive and that Java and Scala are both faster and better supported in terms of tooling. Go seems rather nice, just very boring and not very compelling vs. many other tools.


I thought lack of exceptions was a deal killer for me, until I started using Go... and then I realized how much better multiple returns is. You never have to worry about your code suddenly exiting out of the middle of a function if you don't want it to. If something returns an error... it's just a value returned. Hi error! How's it going?

In languages with exceptions, potentially any function call you make could throw, and you don't know, because it could be 6 levels deep in the call stack. (Even Java's checked exceptions don't help, since someone down the line inevitably just rights "throws exception" and the screws everyone up the stack).

Go is really fast to pick up, it's pleasant to write code in, and yes... it's boring. I think that's it's biggest feature. It gets out of your way so you can produce a product. Why does the language need to be interesting? Isn't it more important that it can build interesting things quickly and reliably? Go does that.


It seems silly to have to check the error return code with an if for every method I call. Surely a try { } catch around a block makes more sense than littering my code with if (errorHappened) in every second line.


How do you know what failed, then? A try/catch around the entire function simply tells you "something failed". Often times that is not good enough in a real program. You can't handle the error, since you don't know what function call it came from, so you're probably just logging it and swallowing it.

It also means that you don't know how much of your code executed. Have you written that file to disk yet? Maybe you need to clean it up now? Is that socket still open? or maybe you didn't get that far in the code?

In code that cares about handling errors, you end up with a lot of try/catches around individual functions that you know can throw... this is no different than go's if err != nil code.

  try {
    v = ThisCanThrow()
  } catch (Exception ex) {
    // handle this specific failure
  }

  v, err := ThisCanError()
  if err != nil {
    // handle this specific failure
  }
Because Go forces you to handle the error at the site where it is produced, error handling ends up being much more robust and specific. You can't just "let 'em fly" and make someone else deal with random exceptions up the stack. This almost always produces better code in the end.

Believe me, I understand where you're coming from. I've been using exceptions for 13 years in production code. I initially skipped Go pretty much solely because of the lack of exceptions. But I am really glad I gave it a second chance, because, damn, it is good.


This is a fairly minor point: but I also like how idiomatic error handling in Go only indents the block that handles the problem.

Because of multiple returns, the normal flow of execution isn't indented. I find that this makes it easier to skim Go code in practice.


Thanks for the explanation. In most cases cleanup is handled in finally blocks and the unit of work fails if any of N calls fails, in most case it makes no difference which one failed. Where the difference does matter it's probably in a different method etc.

Your explanation does seem to make the case for this type of error seem somewhat sensible, maybe I'll give Go another try. Are methods which return errors and the types of errors returned clearly documented/visible?


Methods' declarations indicate which ones return an error value. E.g.:

    func Demo (s string) (string, error){...}
When called, that is guaranteed to return a string and an error value (OR nil).


It seems silly, but it's simple, powerful, and removes a large class of ambiguity from your programs.


> Lack of exception handling is the biggest reason I haven't used Go for much.

Go does exception handling with panic, recover and its reflection syntax.


Using panic and recover is strongly discouraged, and in the rare cases where it makes the code significantly simpler, panics should never cross package boundaries (which is to say, you should never have a public API that can panic, unless you fully expect the panic to take down the process).


Using panics for control flow or having panics cross library boundaries is strongly discouraged, otherwise they are fine. Go's own standard library uses them internally in several places.

Even then discouraging panics is very different from not having them.


So if I'm reading from a file I should use panic recover and not return code checking?? That's not what I've seen in the docs.


You seem to be missing the difference between "can you do it" and "should you do it". The reason that you should not is because doing so is not idiomatic Go. You are completely able to do so though.


Of course it has it's niche. It is fun, organized and simple to write like ruby, but It is a statically typed, compiled language. There you go.


Of all the languages you compared to Go, only 1 has native green threads: erlang. So why didnt google just use erlang? Well Go solves lots of problems that erlang doesnt, and maybe they also didn't want an interpreted functional language with no variables.


I can't really agree with a single word of this and I've been writing Go weekly for 8 months.


I'm a C++ and python programmer with some basic experience in JavaScript. I started learning Go, as I looked into D some years ago, an was a bit puzzled by some design choices.

I don't understand the need to enforce the use of { } and that the if of for line must end with a {. I don't like this writing. My preferred syntax is the one of Pythons, which is the most concise and clear. It seem Go could have used : and indentation as in python instead of { }.

Another puzzling choice of Go is slicing which differ from Python's and D's. In Go slicing is limited by the capacity and not by the number of items it contains. Returning 0 as default value looks to me like an open door to silent bugs.

The way Go handles errors looks original and interesting, but I'm lacking experience to determine how it compares to exceptions from the usage perspective.

From what I saw, I would say that Go is a better C and D is a better C++ where better means also closer. As a consequence Go seams simpler than D to learn and use. Thus I expect we will see much more Go programmers than D programmers in the future. Simplicity has been proven many times to be trump.


> I don't understand the need to enforce the use of { } and that the if of for line must end with a {. I don't like this writing. My preferred syntax is the one of Pythons, which is the most concise and clear.

This article explains the reasoning behind lots of Go's design choices: http://talks.golang.org/2012/splash.article

"Some observers objected to Go's C-like block structure with braces, preferring the use of spaces for indentation, in the style of Python or Haskell. However, we have had extensive experience tracking down build and test failures caused by cross-language builds where a Python snippet embedded in another language, for instance through a SWIG invocation, is subtly and invisibly broken by a change in the indentation of the surrounding code. Our position is therefore that, although spaces for indentation is nice for small programs, it doesn't scale well, and the bigger and more heterogeneous the code base, the more trouble it can cause. It is better to forgo convenience for safety and dependability, so Go has brace-bounded blocks."


My personal opinion on the subject is that you should not obsess about those things. It is good that Go that enforces one consistent style. In practice it does not really matter for your productivity what that style is.

That said, I don't consider this a convincing argument. They basically say "We had some problems in the past with embedding Python code in Java files". This is a very specific problem and I could think of at least 4 different specific solutions for this specific problem. I don't think this arguement can support very broad conclusions like "Spaces for indentation does not scale to big and heterogeneous code bases and compromises safety and dependability for convenience".


> My personal opinion on the subject is that you should not obsess about those things. It is good that Go that enforces one consistent style. In practice it does not really matter for your productivity what that style is.

My qualm with Go here is that it does not enforce a consistent style. (note: I use Go quite frequently). Trailing semicolons, parentheses, curly braces should either be valid or invalid. There are instances in the languages where either is fine.


A particular style is enforced automatically by go fmt.


There are many cases of style that are not.


Its convinced if you consider that Go was made to solve most of Google's problems.


The formatting has been well thought out. The main problems with Python formatting are copy and paste problems, source control merges, and relying on the count of invisible characters to determine indenting. Any time you're merging two bits of code, it's very easy for the indenting to get messed up. In go, that's not a problem, since the braces are the only thing that matter. This is also what allows gofmt to format your code for you.

I think you misunderstand slicing. It's very similar to python's slices, except that python makes a copy of the list and Go does not. This is a really nice feature for reducing data copies.

The default values are very useful in many situations, and code is often designed around the fact that uninitialized variables have specific values.

As for error handling, Go's error handling is one of its biggest strengths, in my opinion. You never have to worry that your function will exit out in the middle unexpectedly. This is really great when dealing with third party libraries, since you don't have to know if something 6 levels deep is going to throw an exception... if something returns an error, you can deal with it right there. I find I write much more reliable code in Go, because error handling is so much simpler.


I find that the braces and termination policy forcibly avoid stuff like:

   for p = initial; p.next != nil; p = p.next;
       doSomething(p);
This is a whole class of pain I've had to debug before. Better to be explicit.

I'm not really a fan of python indentation as I've had to clean up a couple of messes before.


So use Nimrod instead: systems programming with indentation based syntax. It also has unmatched meta programming facilities, a realtime GC and checked exceptions done right (however, not in the 0.9.0 release).


Interesting, I hadn't heard of it before: http://nimrod-code.org/


It looks it could be another language to use for writing native code across iOS, Android and Windows.


Indeed. In fact Nimrod has already been used on Android (http://forum.nimrod-code.org/t/61#319) and iOS devices.


> The way Go handles errors looks original and interesting, but I'm lacking experience to determine how it compares to exceptions from the usage perspective.

Having done a lot of straight C programming in my life, the error handling in Go is very familiar. Most C code returns errors and doesn't use exceptions (though I have used setjmp()/longjmp() fairly successfully at times).

In practice, the code is more verbose with Go's style of returned errors, but requires you to think more explicitly about errors and recovery, resulting in potentially better code overall.

However, since Go doesn't have an RIAA like C++ and doesn't have "goto" like C, it makes cleaning up from errors more ugly and repetitious (and potentially error prone). File handling, in particular, is causing me headaches right now (getting files closed on errors). I am admittedly a Go newbie, so I may be missing some style that makes it cleaner.


Getting files closed on errors should look something like:

    file, err := os.Open(filename)
    if err != nil {
        // handle the error however you see fit
    }
    defer file.Close()
    // continue working, knowing that file.Close() will be called when the surrounding function returns
See: http://golang.org/doc/effective_go.html#defer


Ah! Thanks! I had seen panic/recover but hadn't caught "defer". That will make my code much better.


"defer" is 50% of the reason I use Go. Open some resource, then defer close it the next line and move on. No more giant, nested try/finally blocks.


In addition to defer, Go actually does have goto.


I find it acceptable, since they did away with semi-colons, which always offended me a lot more than braces.


...since they did away with semi-colons, which always offended me a lot more than braces.

The semi-colons are still there, but in most cases they can be inserted automatically when the program is being compiled.


I've been using Python almost exclusively since 2004. Go is the first language that has made me want to switch. I can't put my finger on it, but it's fun to work with. Actually, I'll try to put my finger on it:

1) Fast build times

2) Goroutines. If you've tried using any async library in Python or are waiting for Tulip to come into mainline Python around v3.4 - stop wasting your time. Goroutines along with channels just works (TM) and is unbelievably easy to use. No callbacks, no threadpools, no having to CTRL-C your way out of a bug. It's a pleasure to work with.


What's the standard graphics library for Go That Just Works(tm) ?

I'm looking for something for Go like PyGame is for Python. I like to get surfaces rendered on my screen in pretty much no time as I like to learn a language by doing simple graphical demos and experiment from there.

There are few SDL bindings for Go but none of them worked. One of them did work to some extent after a lot of tweaking without the help of many examples. I quit learning after I realized I'd have to learn more how the graphics bindings were written than how to program in Go.


Sadly that's mostly still work in progress.

OpenGL bindings are at https://github.com/go-gl

For 2D graphics there's promising project at https://github.com/skelterjohn/go.wde which provides interface that you can use together with http://golang.org/pkg/image/draw

(Issue worth noting is that none of the platforms specific parts in go.wde yet have hardware acceleration so it's not yet ready for game development etc. It's quite possible that that'll change in the future though :) )

And for ascii graphics we have https://github.com/nsf/termbox-go

There are bunch of other libraries as well but these are the ones that I'm more or less constantly using. go.wde is probably closest to what you were looking for but also the one that still requires hardware acceleration before it can properly be used as fast canvas for experimenting with games etc.

Note: None of these count as "standard library", all of them are third party projects by gophers around the world.


Like zemo said, pygame is not a standard 'graphics library', it's more like a game making framework which builds upon SDL (which is a low level graphics/input/sound library).

There are Go-bindings for SDL but I haven't tried is myself so I can't vouch for it. I have done some tests using the Go open-gl and glfw bindings though, and I encountered no problems when using them.

As for game frameworks, there's sadly nothing mature like pygame available, but I have seen a couple of such projects in development. One I came across recently and which also seems to be worked on in a regular fashion would be the GarageEngine,

https://github.com/vova616/GarageEngine

There are a couple of example videos on youtube:

http://www.youtube.com/watch?v=iMMbf6SRb9Q http://www.youtube.com/watch?v=BMRlY9dFVLg

Like you I would love to have a game framework for Go in the style of pygame/flashpunk/flixel/löve etc, but I feel hopeful that this will arrive in due time as Go picks up users.


there is none, just like there is none in Python. PyGame is not a standard library package. Did you install PyGame by hand, or did you use their installer? Internally, it actually has a lot of moving parts; not only does Go not have PyGame itself, it'll be a while before we even have the parts that PyGame requires to make something like it in Go. Python was nine years old by the time PyGame started, and it was another few years before it achieved traction; Go isn't nine years old now, so... it's not surprising that there's nothing quite like PyGame. We don't have that level of maturity with Go. Those things will likely come in time, but for now, that's a trade-off.

Anyway, there are rumors that you can use OpenGL from Go, but I've never tried it.

https://github.com/go-gl

and if you really want graphics, why not use Processing, OpenFrameworks, Cinder, or one of the languages supported by Unity? Go tends to really shine for writing servers. Of course, you could always use Go to write a game server for a multiplayer PyGame game.


It's called "net/http". It's cross-platform, has network-transparency and all that stuff. But you need a client called "browser" to view the graphics. A great example is hosted at http://tour.golang.org/, which makes learning and playing around very easy.


building a "standard graphics library" into a language that is not part of a write once run anywhere managed environment is a terrible idea and has never worked.

On the other hand a more solid native 2d drawing library like java2d would be more welcome.

Weekend project #34532


[deleted]


> "write once run anywhere managed environment"

that is not even remotely what that is.

A sufficiently advanced graphics library will do considerable amounts of non trivial interaction with system dependent and even hardware dependent libraries. The parent cited SDL. Which sits atop other libraries. Which imposes certain runtime constraints.


You're now talking specifically about SDL, where as I was commenting about your generalisation about Go as a language (which was the context of your previous comment).

I'd already said Go lacks any kind of standard graphics library and never tried to argue otherwise. But the standard packages that are included with Go's SDK are cross platform. I can (and frequently do) write Go applications using just the standard libraries that I then run on different platforms (both in terms of OS and CPU architecture) without any code changes what-so-ever.

Anyhow, even that being my point, I don't agree with it myself. Thinking properly about it, Go's base packages are little more equivalent to ANSI C than JRE; Go isn't managed and thus base packages are really just a set of standard libraries rather than a runtime environment.


FWIW, I benchmarked a basic Revel web app. Go 1.0.3 = 2850 req/sec ... 1.1 = 10928 req/sec.


Any chance you can post the code you used to benchmark? That's an insane difference.


It was a basic newly generated Revel app running in production mode.

Not hitting a DB. Benchmarked with 'ab -n 10000 -c 30 http://localhost:9000/some_action.

See also: https://github.com/davecheney/autobench BenchmarkHTTPClientServer 373216, 52646 -85.89%


    bench old_ns/op new_ns/op delta
    "BenchmarkHTTPClientServer 373216, 52646 -85.89%" 
That bench is 7 times faster in Go 1.1 than 1.0.3.


Sigh. Sorry about the mess.

I opened the thread first thing after waking up this morning, commented before having cup of coffee and resulted in misreading the whole point of that comment.

I'll try to drink more coffee from now on. Sorry knotty66.


Ha ha, no worries. I'm sure my lazy English contributed with the 'see also', too.


Uh? They are two separate benchmarks, that's why I said 'See also'.


[deleted]


The sources don't contradict each other? 1.1 is several times faster then 1.03 in both benchmarks.


His comment doesn't not make sense just because "See also" isn't "usually" used that way.


The new data race detector looks great. I have a script I run daily that panics maybe once a month. I've never been able to figure out where the problem is. One run after building with -race and I now have a juicy data race report. Awesome!


Turns out exec runs two goroutines, one for Stdout and one for Stderr, and if I run both into the same bytes.Buffer, that's a data race. No wonder I couldn't find it, I was looking in my own code for the goroutines. Thanks go1.1beta1!


The changes concerning function returning[0] are really welcome. The merits of implicit vs. explicit else blocks were debated, but I think everyone should be glad to get rid of forced panic("unreachable").

[0] http://tip.golang.org/doc/go1.1#return


Very cool.

I don't see a tip in the hg repo for go1.1beta1. Anyone know what the right revision is? I'd rather install the known beta source than whatever's at the tip.


The beta isn't tagged. As mentioned in the article, beta1 is cut from revision 267bb9854177.

But as only fixes will be submitted between now and the 1.1 release, it's definitely better to use tip.


Ah you're right, I missed seeing the 267bb9854177 in the mail. But I guess I'll use tip if that's better. Thanks.


Is there a decent web framework using Go can that be competitive to Rails or Django someday?


There's enough built into Go that frameworks feel very unnecessary.

The only thing I'd strongly recommend is Gorilla Mux: http://www.gorillatoolkit.org/pkg/mux

And you can get an idea of how people build websites using Mux and Go by looking on github: https://github.com/jimmykuu/gopher

If you're very new to Go, then reading that last link repo you probably want to read these files in this order: https://github.com/jimmykuu/gopher/blob/master/src/server/ma... https://github.com/jimmykuu/gopher/blob/master/src/gopher/se... https://github.com/jimmykuu/gopher/blob/master/src/gopher/ur... and then to take a look at the files in this folder for the handlers and html/template calling: https://github.com/jimmykuu/gopher/tree/master/src/gopher


Second the Gorilla recommendation. Great toolkit.


In older versions there seemed to be a websocket package, but I can't find it anymore - do you know what hapenned to it?


    go get code.google.com/p/go.net/websocket
The html processing lives in there too:

    go get code.google.com/p/go.net/html
If you see people refer to go.net, they mean that repo.


http://robfig.github.com/revel is at least aiming for that. Can't vouch for or against it (yet) though.

Gorilla toolkit is also very neat, but it's a handy tool-box for web work, rather than a kitchen-sink framework.


Great stuff, looking forward to the final release, thanks to the Golang developers for all the hard work.


Exciting stuff! Can't wait to see Go 1.1 in the benchmark games.


I'm interested to see if it is still going to be clobbered by Java and Scala the way Go 1 was.


Curious downvote for a factually accurate post...

source: http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t...


Probably downvoted for not providing a link to the benchmarks that show Java and Scala out-performing Go 1.0?

I know of Collin VanDyck's web service showdown (http://boundary.com/blog/2012/09/17/comparing-go-and-java-pa...) which showed that Java had lower latency and higher throughput for highly concurrent tasks based on a very simple code base, but net/http performance in Go 1.0 wasn't a high priority. It seems that it has since been bumped up the priority list and a lot of work has been going on (https://groups.google.com/d/topic/golang-nuts/zeLMYnjO_JA/di...).

The thing is, Go isn't just for writing web apps. If you have a look at some of the real world use cases for Go (there's a list in another comment here somewhere) you'll notice that these aren't just web apps.

Every bit of Go code I've written (web app, mp3 database generator, encryption library) has been blisteringly fast, and it seems Go 1.1 will bring substantial performance improvements again.

Oh, and I didn't down-vote you, I don't yet have that privilege.


Thanks, I've added the link now.


This one is more applicable for most people (it is 64 bit) and Go does a little better: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...

Also, don't forget at the time of this posting that page is showing Go 1.0.3 not 1.1 beta.


fwiw

    binarytrees#3 18.576s (go1.1beta1 17.298)

    binarytrees#1 114.303s (go1.1beta1 121.446s)

    binarytrees#5 123.890s (go1.1beta1 138.230s)

    chameneosredux#5 4.984s (go1.1beta1 4.482s)

    fannkuchredux#1 98.413s (go1.1beta1 73.698s)

    fasta#1 10.620s (go1.1beta1 6.937s)

    fastaredux#2 2.164s (go1.1beta1 1.964s)

    knucleotide#1 308.240s (go1.1beta1 213.563s)

    knucleotide#5 75.117s (go1.1beta1 77.791s)

    mandelbrot#6 75.166s (go1.1beta1 46.689s)

    meteor#1 0.159s (go1.1beta1 0.136s)

    nbody#1 32.135s (go1.1beta1 22.867s)

    pidigits#4 4.016s (go1.1beta1 3.329s)

    regexdna#1 161.505s (go1.1beta1 157.733s)

    revcomp#3 1.573s (go1.1beta1 1.455s)

    revcomp#1 1.188s (go1.1beta1 0.997s)

    revcomp#2 1.495s (go1.1beta1 1.311s)

    spectralnorm#3 22.727s (go1.1beta1 15.706s)

    threadring#5 9.893s (go1.1beta1 12.919s)
http://benchmarksgame.alioth.debian.org/u64/go.php#about


Awesome! Thanks.


http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...

Yeah, it's pretty much the other way now.


Kudos to the team. Go is going from strength to strength. I'm about to start a small project with it.


What makes Go so cool?


It: is small, is natively compiled, has great tools, has a great stdlib, is concurrent, is parallel, is gc'd ... and has well implemented features including closures, channels and structural static typing.


Google staff upvote every article about it.


I am guilty of upvoting every Go post. But my work has nothing to do with Google. I just really love the language and want it to succeed.

Go maps very closely to how I think about programming. It has more useful features than other languages, like channels, slices, and range. Yet despite this it is a beautifully simple language. It has fewer keywords than C and you can express the same operations with less code.


Me too. I'm also not a Google employee, just love the language.


The golang-nuts mailing list has nearly 9k members, so there is more than enough interest to justify a few dozen votes on Hacker News.


It is made by Google.


Kind of like Google Wave was cool then?


Yes, still waiting to see if it will follow Reader and Wave's fate.


A nonsense comment. Go is an 100% open source project.


Lets see how far it goes if Google stops giving money to the core team.


1. Google isn't going to stop giving them money, as Go solves a ton of Google's problems with C++.

2. There are over 300 non-google contributors already

http://golang.org/CONTRIBUTORS


>1. Google isn't going to stop giving them money, as Go solves a ton of Google's problems with C++.

So the Go team says. But Google is still using Java, C++ and Python as it's main languages. And Go wasn't especially planned by Google execs to use for "solving their problems" -- it is a grassroots project by some Google guys to solve those problems. Which is something different than a mandated to use language.

>2. There are over 300 non-google contributors already

The level of contribution matters a lot. If Google staffers do all the core language, runtime, compiler, tooling etc, and the rest just do little stuff here and there in the libs, add documentation, etc, then it's not like this matters much.


And Go wasn't especially planned by Google execs to use for "solving their problems" -- it is a grassroots project by some Google guys to solve those problems. Which is something different than a mandated to use language.

Thats the best way that problems get solved. Go needs to win in the marketplace (even in Google's own internal marketplace) on its own merits. That's the best kind of win.

Corporate mandates end in committees with no sense of design or minimalism. I've seen enough of that to not want any more.


>Go wasn't especially planned by Google execs to use for "solving their problems"

Go may not have begun as an executive mandate, but we now have high level executive support. More than a year ago Go was made Google's 4th "canonical language", which is an mandate that requires infrastructure teams to support the language. Some large teams are migrating to use Go exclusively, and the rate at which Go code is being written at Google is increasing dramatically.

> If Google staffers do all the core language, runtime, compiler, tooling etc, and the rest just do little stuff here and there in the libs, add documentation, etc, then it's not like this matters much.

Except that is not the case. We have many contributors who do core stuff. In fact, some of our hardest problems have been cracked by these guys. I love our community!


"Go wasn't especially planned by Google execs to use for solving their problems"

How do you know that is the case? I don't know the Google executive plans but it seems like to get Robert Griesemer, Rob Pike and Ken Thompson together to create a language might have/need some executive level involvement.


"We returned to our offices after the talk. I started another compilation, turned my chair around to face Robert, and started asking pointed questions. Before the compilation was done, we'd roped Ken in and had decided to do something." http://commandcenter.blogspot.de/2012/06/less-is-exponential...

"Began as a 20% project" http://talks.golang.org/2012/go1.slide#5

I have no reason to assume that they are lying.


Great info guys, thanks for sharing.


>How do you know that is the case?

Because they have described it themselves (the Go guys). From the language FAQ:

"Robert Griesemer, Rob Pike and Ken Thompson started sketching the goals for a new language on the white board on September 21, 2007. Within a few days the goals had settled into a plan to do something and a fair idea of what it would be. Design continued part-time in parallel with unrelated work. By January 2008, Ken had started work on a compiler with which to explore ideas; it generated C code as its output. By mid-year the language had become a full-time project and had settled enough to attempt a production compiler."

>I don't know the Google executive plans but it seems like to get Robert Griesemer, Rob Pike and Ken Thompson together to create a language might have/need some executive level involvement.

The agreement to let them work on it by some exec, is different than Google deciding "we need a new language, you guys go build one that fixes our pain points, and we will migrate stuff to that".

V8 or Dart for example are cases of this. Google decided the need to have those created, spend money on marketing and getting top people to work on them, built full-on documentation, marketing material, benchmarks, tools and sites for them, etc. It's the same kind of focus MS had for .NET and SUN had for Java.

Whereas Go is more like how Google had a team work on Unladen Swallow, or Apple had MacRuby, etc, mostly peripheral stuff, like a 20% project that grew up.


Fortunately it's an open source project and it will be continued long after Google loses interest in it.


Is Go a good choice to create a CRUD web app? between the stdlib, gorilla toolking and the pg driver seems it wouldn't be so much of a pain, but the pg driver doesn't look ready for production use.

https://github.com/bmizerany/pq


I wrote the outline of one[0] a while back with gorilla and it wasn't too difficult. Be warned that some of the code is less-than-idiomatic, since I began it while I was still learning Go. There's definitely some refactoring that can be done, etc.

However, as you can see, it's not too difficult to write a basic CRUD app with authentication, even if you're starting completely from scratch (which you don't have to; I did it more as a learning exercise).

I disagree with jbooth; I find Go's templating language to be incredibly mature, and I also find it much easier to develop with gorilla than something like Flask, if for no other reason than the static compilation and incredibly thorough code analysis/other checking done at compile-time (unused lvalues, etc.)

[0] https://github.com/chimeracoder/go-server-bootstrap


For just plain CRUD, you'll probably get where you want to go faster with Django or Ruby -- they get you up and running faster, and their template engines are more mature than anything in Go.

Once you're beyond just plain CRUD to the point where the language you're using matters more than how fast you can get going with defaults, then you might like Go more (or less) than Ruby/Python.


For someone who wants to spend a week hacking on a project in Go, what kind of project do you recommend?


The only real way to get hobby projects is to find a problem you've been having and solve it. So what are your problems? :-)

Here are some of mine, that I turned into Go code: (restricted to "week long hacking" or less)

    A simple blog application.
    A command that when run, sends the output of other commands to your email.
    An image viewer.
    A simpler interface to `xrandr`.
    A parser for the new TOML configuration format.
Or, you could pick a small program that you wrote in another language and port it.


Still no generics :(


You aren't going to see any radical changes to the language in the 1.x series.


To explain that a bit further: the core Go team is not against generics by definition, they just believe that no generics is better than bad generics (where "bad" admittedly is subjective, but see Russ Cox' article on the topic[1]).

If/when they find a solution that fits their strict criteria, it in all likelihood will require breaking changes to the Go language, and the point of having the 1.x series was a promise that this would not happen.

[1] http://research.swtch.com/generic


I'm wondering how long it will take until people will either stop linking to blatantly false articles or start reading more than the first 5 paragraphs of it.


Apologies, I quickly Googled and pasted the link like you implied I did. I remember a longer, more deeply reasoned article than this one, and by quickly skimming I mistook this for that - it probably was somewhere on the go-nuts mailing list.

The problem is that the topic of generics has come up so many times on that mailing list it will require quite a bit of digging to find that again.

That said, the discussion below the article does get across the standpoint of the Go developers on the topic, doesn't it?


Sadly, the mailing list debates often don't contain much more than linking to this article and repeating unsubstantiated claims.

The points brought up in the comment section below the article were not answered at all.

Russ Cox: “I would be happy to learn about implementations that somehow manage to avoid all three of these bad outcomes [...]”

First comment: “How about C# implementation? It lets you use primitive types.”

Second comment: “The massive gaping hole in your list of approaches is .NET: reified generics, but in a reference-type oriented language. [...]”

Third comment: “http://msdn.microsoft.com/en-us/library/ms379564(VS.80).aspx talks about the .Net Generic implementation in a bit more detail.”

Russ Cox: ⁎crickets⁎


I don't see how this solves the generics dilemma. From the MSDN article:

"If the client specifies a value type, then the JIT compiler replaces the generic type parameters in the IL with the specific value type, and compiles it to native code. However, the JIT compiler keeps track of type-specific server code it already generated. If the JIT compiler is asked to compile the generic server with a value type it has already compiled to machine code, it simply returns a reference to that server code. Because the JIT compiler uses the same value-type-specific server code in all further encounters, there is no code bloating."

So .NET has chosen number 2 with duplicate elimination:

"This slows compilation. It generates a lot of code, much of it redundant, and needs a good linker to eliminate duplicate copies. The individual specializations may be efficient but the program as a whole can suffer due to poor use of the instruction cache."


That's pretty much wrong on all accounts. I recommend getting a basic grasp of the topic before trying to defend Go in such an awkward way.


No, it's not wrong. The .NET JIT generates specialized code once for each value type that some code is used with, which is pretty much what C++ does, although not at compile time, but at runtime (JIT compile time).


And since it's at runtime, strike out the "much of it redundant, requiring a good linker.." bits. Which leaves it sounding pretty good.


Even if one thinks that it's okay. Go is a statically-natively compiled language without an intermediate language and without runtime code generation. I don't think it would fit Go's design very well.


.NET is as well, ever heard of NGEN, Bartok compiler, mono -aot or the native compilation when targeting Windows Phone 8?


http://my.safaribooksonline.com/book/programming/microsoft-d...

"With NGen, there can't be anything "lazy" about how generics are instantiated. Instead, NGen must create representations of every generics instance it could encounter. The CLR won't be around to JIT anything. So, after all the discussion of avoiding code bloat and taking advantage of CLR's run-time optimizations, NGen takes all those values and turns them on their collective heads."


Except that is .NET 2.0. Do you also want to compare Go with K&R C compilers for that matter?


Do you have any indication that this has changed? If yes, how, without runtime code generation?


I don't have information, but by focusing on NGEN for .NET 2.0 you forgot all the other implementations I mentioned.

Bartok compiler for Singularity uses another approach of code generation.

http://en.wikipedia.org/wiki/Bartok_%28compiler%29

http://singularity.codeplex.com/SourceControl/changeset/view...

Windows Phone 8 only runs native code. .NET IL gets compiled down to native code when uploaded to the Windows App Store, by making use of an optimizing IL to native compiler.

http://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-and...

http://channel9.msdn.com/Events/Build/2012/3-005

Mono also compiles to native code on iOS and other systems as well

http://docs.xamarin.com/guides/ios/advanced_topics/compilati...

The IL2CPU compiler used in the Cosmos project, which is still not fully implemented

http://www.codeproject.com/Articles/220071/Csharp-Open-Sourc... http://cosmos.codeplex.com/SourceControl/changeset/view/1011... http://cosmos.codeplex.com/SourceControl/changeset/view/1011...

Going back to the runtime code generation (JIT), there is also SPUR being used at Microsoft Research

http://research.microsoft.com/en-us/projects/spur/

Don't mix languages with their implementations.


I didn't find anything useful about generics in any of your links.


I have no idea whether you or the person you responded to is right (note that my earlier comment just stated the Go developer stance without any value judgement of my own), but please let's not allow ad hominems to muddy the discussion!


Could you please identify the ad hominem? I don't see it.


There's only two sentences, should be pretty obvious... but ok: the second one is a thinly veiled - to give the benefit of doubt, probably not on purpose - ad hominem.

You're putting yourself into an authority position where you write him off as incompetent:

"Do your homework! What you say is wrong and awkward!"

That's an attack at him personally, and completely unnecessary. Simply providing the facts showing that he's wrong would have sufficed. You haven't done that, btw.


That is a common reaction, see this Plan9 response to a user that wanted more functionality out from ACME.

http://9fans.net/archive/2008/08/134


The user didn't ask for more functionality, he asked what the ACME way is.


And you'll never get them because they're unnecessary.


The Golang authors had to create a custom keyword (make) for the two generic types in Go (slice and map). The reason they give for implementing a native map type is that a map type written in Go would be cumbersome (!).

If you want other types with generic functionality (e.g. caches) that perform well (interface{} does not), then you have to use external code generators.


Then why is everyone asking for them?


I think that asks for some further explanation, considering that Go even ships with hard-coded, built-in “generic” data-structures and the topic comes up pretty much every other week on the mailing list.


I get a 404 at the changelog link they provide...


The correct link is in the first reply on Google groups.


I think this is really the one language/tech that's going to take off. It's just too early, but it's going to make it's splash.


[deleted]


Nope. This is the announcement that Go 1.1 has reached beta status.


That's the go1 changelog. There's nothing about Go 1.1 in there.


Oops, wrong copy paste!



Unrelated (Google's Webkit fork -- zilch to do with Go 1.1 beta)




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: