Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



The toolchain part of Go is very interesting (I only know the basics). Go doesn't use GCC, LLVM or other existing compilers. Go's compiler/linker originated from the Plan9 C compiler (that Rob and Ken worked on)[0]. Because of this, it allows you to create binaries for any target platform from any platform you have the Go toolchain on. So from my OSX macbook, I can compile Windows and Linux executables.

When you start diving into it a a bit more, you'll see that Go has it's own ASM language[1] that your code is first compiled into (which then can be translated into specific os/platform asm).

This has it's own ups and downs. Debuggers don't work all that well on Go generated executables (gdb is the closest, even that one isn't all that great). You also don't have the years of optimizations that GCC and LLVM bring to the table. But the Go team has tight control of the tools, which allow for quick compilation and allow them to pick their own direction.

[0] https://golang.org/cmd/gc/

[1] https://golang.org/doc/asm


Yeah, a lot of magic lives at the tooling layer, and Go is going to leverage that with Go Generate in Go 1.4+. A lot of great tools already leverage that core.

I like that fact that a lot of the tooling/editor support is not picking a winner nor demanding an IDE. Tools like errcheck, goimports, gorename (announced today), oracle, gocode, godef, godoc, gofmt, golint, gotags, ... (on and on) ... all can be leverage by IDEs, emacs, sublime, vim and others equally... or just used from a console or in your own stacks.


There's gccgo, and it certainly has a reputation for beating gc/6g in numeric computation, but IIRC it didn't have a huge edge overall.


Gccgo misses out on some key optimizations, like escape analysis IIRC, and therefore on real world tests usually is not as fast as gc. Also, since gc is the de facto standard, it has a LOT more real world testing. Gccgo has a few bugs (I forget exactly, something about embedding an interface or something just causes a panic - avoidable, but frustrating).


> There are no buffer overflow vulnerabilities in Go applications

Actually there are in certain cases [1], but there's a good reason for that.

1. http://stackoverflow.com/questions/25628920/slicing-operatio...


But that's not a buffer overflow. You can't access uninitialized memory (well, without unsafe anyway).


Without unsafe or a race condition. http://research.swtch.com/gorace




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: