Official Go support

The comparison to C has always struck me as strange. It has curly braces and pointers, but few semicolons, no pointer arithmetic, garbage collection, and tons of high level language primitives (maps, slices, channels, select, goroutines, a userland scheduler).

Many people, myself included, find it a wonderful language suitable for all sorts of service development whether it's data processing systems or web APIs.

Like any other language, there're some pros and cons with Go. For example, C gives you complete control at a very low level, but can make higher-order operations more complex. On the opposite end of the spectrum, Python removes a lot of that friction at the cost of doing more things behind the scene, which obviously affects performance. I regard Go as somewhat in-between -- it provides you with some of the lower level constructs (like pointers) but also reduces complexity (by giving you goroutines, for example).

Specifically about garbage collection, I'd recommend taking a look at what's coming up in 1.4:

https://docs.google.com/a/stripe.com/document/d/16Y4IsnNRCN4...

Go was originally pitched as a better C, but it seems to be finding a niche as a better Python or possibly a better Java. Go binaries have built-in GC, and Go will probably never reach C levels of performance. There is a lot to like about Go and it is working out very well for a lot of people, but it isn't appropriate for every situation.

If you want a better C, better to look into Rust: http://www.rust-lang.org/

Go is a very pleasant language to develop software products in.

Unlike the dynamically typed languages, it doesn't trade speed for beauty of syntax. This means that sometimes syntax can be a little non-uniform, but there's always a reason. Unlike C and C++, it doesn't trade safety for speed of execution. There are no buffer overflow vulnerabilities in Go applications. It treads a fine line of where to let the language do the lifting and where to make you do it. In general, it does a really good job of finding the pragmatic side of the line to sit on in any particular situation.

I don't know of any widely used C garbage collection libraries. The benefit of it being a language-level is that everyone uses it, which means your code works the same as everyone else's, so you can easily just reuse other people's code, without having to restrict your search to some small subset of repos that use your particular GC Library.

Also, in Go, unlike most other garbage-collected languages, there is a stack, and you can pretty easily write code that only uses memory from the stack, and never needs to run GC.

Finally, Go's tooling is really phenomenal. Testing, doc generation, performance reporting, code coverage, linting, package distribution, code formatting, refactoring, cross-platform compiling, and soon, pre-processing, are all built-in and really well done.

A C garbage collection library generally has to be very conservative because most C code is written with the assumption of not being garbage-collected. Having GC built in allows you to do more aggressive collection without worrying about breaking code that assumes it has precise control over memory. There's a reason why even people who like garbage collection don't tend to use garbage collection when they write C.

The Golang FAQ will help answer your questions about some of their design principles[0]. Rob Pike also has some interesting views on why Go seems to attract Python and Ruby devs rather than C and C++ devs[1].

[0] https://golang.org/doc/faq#What_is_the_purpose_of_the_projec...

[1] http://commandcenter.blogspot.com/2012/06/less-is-exponentia...

Go's syntax and semantics seem ad-hoc, hard to remember, and inconsistent, but that's because Go was designed from uses cases and experience by prominent thought leaders such as Rob Pike and Ken Thompson, and Google. For example, sometimes you'll get Unicode code points, but sometimes you'll get bytes of UTF-8. The language was designed to give you the right one in the right case. UTF-8 is coupled with the language because it's the most useful choice. Another example is that pointers are automatically dereferenced, but not when you have pointers to pointers, because that's less useful. If any thread runs in an infinite loop that doesn't call built in functions, the entire runtime will freeze. But this is by design. You're meant to do actual useful stuff in your loop such as calling IO functions (which will yield to the scheduler) or calling GOSCHED.

It was designed to compile fast, and compiles faster than most languages and still has near C-speed. It doesn't have a GIL so it has better concurrency (Java style memory model). It has no complicated features like generics, instead you just use type assertions when you need. It also has impeccable tooling.

For me, touting a language as being "Python, but with X" is a big turnoff.

I worked for about 2 years in Python and hated most things about it - from the whitespace sensitive indentation that led people to write really long lines and the limited expressive capabilities forcing people to do meta voodoo in their libraries leading to incomprehensible DSLs, to the legacy that sticks like "old-style vs new-style classes", to the performance problems and the sad state of libraries in the ecosystem, let alone the complete cluster-fuck that is dependency and deployment management on top of Python.

So you know, I want to hear about languages that are not like Python.

Go is a slower C[1] with worse syntax and oversold ideas.

Stockholm syndrom is a builtin feature that comes with it and not much else. It doesn't provide basic stuff like generics, warnings, or exceptions because the authors want to make a bold statement about how they are in the Right and their potential users are wrong.

Meanwhile system software will continues to be built in C and C++ since Go addressed some real problems with system programming but created new ones.

Go was explicitely created for the average programmer like is said in videos talks. It is a dumbed down language to address the maintenance problem through tools instead of through better craftmanship. Go isn't very successful at Google but in startups who could do technically anything and still have the same outcome.

As always with the HN hype: Do. Not. Listen.

[1]: http://benchmarksgame.alioth.debian.org/u64q/go.php

If I had to summarise Go; I'd say it does most things better than most languages but doesn't do anything significantly better than specific languages.

Which isn't very exciting but it is generally what people want. Something that's a good enough multi-purpose language to cover normal use cases. And in the rare examples they need something more niche, then there's other languages that will serve those functions better.

Interesting - I thought it'd be red/green, but it's blue/purple (which I thought were colors chosen for the color blind).

Is blue/purple color blind less common? Can you differentiate between red/green?

Please excuse our ignorance. We've updated the chart to try and help you differentiate between the two.

Tools like Color Oracle[1] are great when checking UI color design for its color safety. Some monitor software also has similar features. E.g. NEC monitors' MultiProfiler tool supports a number of different color vision emulation modes; see the "Color Vision" pane in that app.

[1] http://colororacle.org/

Right, just look at August! Although I wish there were numbers on that graph. Was there a conference talk? Glad to know there'll be lots of fellow devs using it anyway.

Go's JSON parser ignores fields that aren't present in the destination type, so the addition of new parameters shouldn't be a problem.

(Stripe's Go library dev here)

There's a tradeoff space here, as that tweet indicates. Doing things generically makes the library less idiomatic, but means developers don't need to churn their library dependency as often. Go's a different language from Java, and it's less common to have to deal with casting, etc. As that tweet conversation indicates (particularly https://twitter.com/JimDanz/status/511732603884294145), we're also considering changing the Java library implementation in the future.

Honestly parsing json as map[string]interface{}, rather than using a struct is a major pain in the butt.

I'm currently doing a project that takes json, with no predefined structure, or at least very varying struct and transforms it. Dealing with checking for keys and doing type conversion it's that much fun. The same project need to parse an XML file, with a clear and defined structure, it took something like five minutes and work on my first try.

I don't think you would need to update the Go library in the case of just adding new parameters, not if the parameter can be excluded. The json parser should just skip that value, it won't be available to you of cause, but it should break the parser. Given that I haven't touched Java in 10 years I don't know how Java deals with unexpected parameters.

That was porting from Ruby. Go is particularly good for any application where you want to get better utilization out of your CPU, or want to cut down on memory usage.

Most of the code we've been porting has been infrastructure: parsers, reverse proxies, and the like. We're still getting a feel for what it's like writing complex application logic in Go, but what we've seen so far has been promising.

(Stripe dev here)

You're probably already aware of this, but there are 3rd party[0] libraries, including one for Lua[1]

[0]: https://stripe.com/docs/libraries#third-party [1]: https://github.com/wsummerlin/stripe-lua

Out of curiosity: Where would this be used? The only places I ever hear the word "lua" being used are with "embedded in a game as a scripting language".

Is this the case here? Does lua have a lot of use elsewhere?

So I'm gonna make a wild guess here and assume you haven't written in Go. If you had, you'd probably find it fun and convenient. Not revolutionary, just fun and convenient. That's enough for me to like it better than python or ruby or perl.

I'm not the greatest fan of Go; the pain points of api weirdness and generics are too irritating for me.

...but you've got to admit: look at the graph. That's an exponential increase in people using go to access the service.

If you're a service based company you can't just ignore the people who use your service.

If people are using go? Provide a go library.

If you see an exponential curve of people accessing it using lua, write a lua library.

It's pretty obviously the right thing for them to do.

I write Go on a daily basis, and the lack of generics support is really not high on the list of problems that I encounter. I think it's a great tradeoff between C & say Java for the kind of programs that I write -- backend server software with moderate to high performance requirements.

People often ridicule what they don't understand. People who haven't written real code in Go don't understand why it's good. And what makes it good isn't that it has X feature, so it's hard to explain to people who haven't used it.

Missing generics is not a major problem. Yes, it means you can't write a generic red black tree in the language that doesn't require type-casting. However, for real software solving real problems, you don't often actually need generics. I work on Juju, which is a couple hundred thousand lines of code, consisting of a client and networked servers deployed across an arbitrary number of machines in the cloud. The number of times we might have wanted to use generics in the codebase is approximately 2... and only one of those pieces of code is actually used by more than one type.

Sure, some software really benefits from generics. But most of the time, generics just complicate the code with little to no benefit. Many things people do with generics can be accomplished with interfaces and just writing code that has fewer assumptions about the outside world.