Go 1.1 beta 1 Released

https://groups.google.com/forum/#!msg/golang-nuts/sbjJDgxLqiE/xqWJ1ybaiKoJ

by geetarista • 13 years ago

161 174 13 years ago

groups.google.com

phasevar• 13 years ago

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

trailfox8• 13 years ago

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

trailfox8• 13 years ago

Curious downvote for a factually accurate post...

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

dscrd• 13 years ago

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

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

VeejayRampay2• 13 years ago

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

frou_dh2• 13 years ago

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

creativityland• 13 years ago

https://news.ycombinator.com/item?id=5489054

dualogy2• 13 years ago

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

eridius4• 13 years ago

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.

enneff8• 13 years ago

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.

eridius4• 13 years ago

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

glitch273• 13 years ago

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

dualogy2• 13 years ago

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.

buro92• 13 years ago

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

stock_toaster• 13 years ago

Second the Gorilla recommendation. Great toolkit.

swah• 13 years ago

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

LAMike• 13 years ago

What makes Go so cool?

frou_dh2• 13 years ago

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.

pjmlp13• 13 years ago

It is made by Google.

coldtea6• 13 years ago

Kind of like Google Wave was cool then?

p0nce2• 13 years ago

Google staff upvote every article about it.

oofabz• 13 years ago

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.

enneff8• 13 years ago

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.

dvt3• 13 years ago

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).

afhof• 13 years ago

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.

enneff8• 13 years ago

> 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

enneff8• 13 years ago

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.

dvt3• 13 years ago

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.

derefr• 13 years ago

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.

tezza3• 13 years ago

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.

coldtea6• 13 years ago

>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.

obilgic• 13 years ago

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.

vladev• 13 years ago

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).

dvt3• 13 years ago

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!

mseepgood10• 13 years ago

> Go is very D-like.

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

drivebyacct2• 13 years ago

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

VeejayRampay2• 13 years ago

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.

smegel• 13 years ago

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.

pkolaczk• 13 years ago

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?"

kyrias2• 13 years ago

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

pjmlp13• 13 years ago

Go is C programming for the average Joe.

polshaw2• 13 years ago

>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).

redbad2• 13 years ago

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

Writing services in a SOA tech stack.

trailfox8• 13 years ago

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.

EdiX2• 13 years ago

> 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.

NateDad7• 13 years ago

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.

eridius4• 13 years ago

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!

eridius4• 13 years ago

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!

pjmlp13• 13 years ago

Still no generics :(

dsymonds2• 13 years ago

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

vanderZwan4• 13 years ago

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

kyrias2• 13 years ago

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

happy_dino5• 13 years ago

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.

Oodiey0h• 13 years ago

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.

p0nce2• 13 years ago

Then why is everyone asking for them?

knotty664• 13 years ago

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

conroy• 13 years ago

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

knotty664• 13 years ago

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%

groundCode• 13 years ago

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

AcessoNegado• 13 years ago

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.

chmike• 13 years ago

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.

mseepgood10• 13 years ago

> 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."

ma2rten• 13 years ago

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".

hp50g• 13 years ago

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.

dom962• 13 years ago

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).

trailfox8• 13 years ago

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

pjmlp13• 13 years ago

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

NateDad7• 13 years ago

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.

TylerE• 13 years ago

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

ansible3• 13 years ago

...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.

__david__2• 13 years ago

> 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.

timewasted• 13 years ago

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

g3orge• 13 years ago

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

mahmoudhossam• 13 years ago

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

yason• 13 years ago

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.

easytiger• 13 years ago

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

errnoh3• 13 years ago

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.

zemo• 13 years ago

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.

JulienSchmidt• 13 years ago

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.

gillianseed• 13 years ago

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.

truebosko• 13 years ago

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

burntsushi• 13 years ago

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.

derengel• 13 years ago

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

jbooth• 13 years ago

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.

chimeracoder• 13 years ago

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

waterside81• 13 years ago

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.

Go 1.1 beta 1 Released

Related Stories