Ask HN: Who is using Go language?
I read a lot about Google Go on Hacker News. Is it as good as we read here? What are its benefits?
Is anyone using Go language in real world projects?
Is anyone using Go language in real world projects?
as well as heroku: http://blog.golang.org/2011/04/go-at-heroku.html / https://github.com/ha/doozerd
edit: more here http://go-lang.cat-v.org/organizations-using-go
(dont have time to watch it right now)
Interesting talk by the way.
Porting large projects is lots of work, especially when there's plenty of stuff to do that directly impacts the customer. New projects are a different story.
I recall reading somewhere that Go was used for some other internal projects, but never heard what exactly for. So maybe it was just someone talking about some greenfield "20% time" projects or something.
The first project is a Google Music player app for Chumby devices (and other similar ARMv5/v6 class devices... will probably port to Raspberry Pi if/when I ever get one). The project is pure Go at this point with its own UI toolkit based on an mmaped /dev/fb.
The second project is a web service API for mobile apps plus an associated webserver.
I hope more companies adopt Go, making it a viable language for commercial programming. Using it is the most fun I've had coding in years.
Anyone know if it's a dealbreaker? I'm planning on running a webserver on it, so I imagine a GC bug would likely manifest after running long enough.
There is also work underway to make the GC more precise which will avoid this problem in future.
I'm still using Lua in embedded projects. It's nice, nixio libs make is very nice and integrates with C ever so easily when needed.
x64 is still the best supported arch, but everything should work on ARM fine (and quite a few optimizations have gone into that port recently, but you will need to build from the tip for that).
It has worked out great so far. Might write about our experiences once it has a few miles on it.
We leave our processes running for months and memory usage stays quite low and stability good which is surprising considering the minimal time spent in development (note: we run on 64 bit linux). (Actually the other day I realized we had generated 24 gb log file because no one had restarted the master process in months.)
We still use other languages for linear algebra heavy things or things that benefit from a more complete webframework (in terms of both features and documentation) but I am hoping the go ecosystem develops in those areas.
Golang is also a better term, due to the fact that "Go" means a lot of different things and is extraordinarily difficult to search for.
In the specific case where X is Go, requiring previous experience is a signal that the company might not be hiring skilled developers. Skilled developers can learn Go quickly because of the language's small size and consistency.
Don't forget that the Go suite contains C compiler and assembler as well for multiple platforms. In the Inferno version it was very easy to do cross-platform compilations.
https://chrome.google.com/webstore/detail/hdahlabpinmfcemhcb...
There is also Windows build if you prefer that over Chrome: https://www.carbongames.com/download.html
I was already planning on rewriting the authentication to work with more than just twitter so it seemed like a good time to try rewriting it in go. Also go is supposed to have a really nice mongodb db interface so I wanted to give that a try as well.
http://www.anchor.com.au/blog/2011/08/the-automation-waltz/ https://github.com/anchor/Orchestra
I would also prefer to have a single executable as opposed to a run time that has to be installed first, especially since I want to be able to sign the executable.
Are there any other options out there that fits the bill? I don't consider C or C++ safe. Python, ruby and others are safe, but they aren't wrapped up as conveniently (especially on Windows). C# would work on Windows, but is less than ideal on OS X and Linux (but it is a contender, thanks to Mono).
Since you asked, you may be interested in Rust as well. It's designed for exactly this use case, with a focus on safety and real-time requirements. However, be warned that it's not at all mature yet.
There's also D, which has quite good Windows support from what I hear.
We were using it also for our web page (a custom blog engine made on go), but, we left it on alpha, and Go 1 changed a lot, gofix didn't fixed and priorities made us choose another tool for our web page.
Still, i think go only needs a desktop GUI toolkit to become popular. It has a lot of potential.
I have a few apps in production already and I'm only doing new stuff in Go.
Actually the "all performance benefits of C" is not quite true. Go ranks slightly slower than Java, and 2-3X the speed of C/C++.
Haven't had time to benchmark against c.
The standard HTTP/networking libraries and goroutine model are fantastic.
C - pain.
[+ps]: well, the concurrency model is quite nice, too.
Just as importantly, what's bad about it? Or if you don't want to say something like (e.g.) syntax can be "bad", what do you dislike? What changes would you make if you were designing it?
* integers overflow
* sharing memory between threads isn't safe
* mutable state/ shared state
* nil pointers
* block scoping can lead to multiple different variables with the same names within a function. Sometimes confusing.
* value types limit certain conversions. eg. you can't convert an []int to an []interface{} directly because an int and an interface{} are different sizes in memory.(http://golang.org/doc/go_faq.html#convert_slice_of_interface)
* Error handling can become quite verbose if you don't design your code to limit the places errors can come from.
* gofmt is awesome, but in some rare situations the default format makes code less clear, so you have to change your style of code to fit the formatting.
* 'go get' is awesome, but it's lack of centralisation makes it harder to find the good 3rd party libraries amongst the bad/incomplete ones.
* The current goroutine scheduler is really simple and moves goroutines between threads and CPUs. This leads to lots of cache misses, so running on many threads can become slower than running on a single thread.
Block scoping, too?
Block scoping is confusing for many people coming from the dynamic languages where scoping is usually function level.
If you want a feature that allows you to signal and catch errors, than:
* you can return Error as the second parameter from a function,
* you can panic and later defer a recover call (more info: http://blog.golang.org/2010/08/defer-panic-and-recover.html )
func Blog(ctx app.Context) {
data := models.GetPosts(ctx,10)
ctx.Render(app.Templates+"blog.html",data)
}
Whenever speed is key, I use Go. Its concurrency primitives are dead simple. It has excellent support for cutting-edge technologies like WebSockets and SPDY (these libraries/"packages" were written by Google), as well as MongoDB (see "mgo").
I'm using Go in production (for an almost-complete MVP). For a telephony app I had to dial 100 simultaneous phone numbers to bring people into conference calls. Trying that in Python maxed out my EC2 instance's resources. I had to kill and restart it from the AWS web interface.
Then I rewrote that part in Go. I was staring at the output of htop (similar to top) when it ran and thought something was wrong; it used a few megs of RAM, no noticeable CPU, and finished in 0.59 seconds _on a micro instance_. Now you can see why Google wanted such a language!
I never appreciated static typing ("who wants to go from Python to Java or C++?") until Go, which makes very heavy use of type inferencing. The upshot is you'll find yourself declaring types 0 times instead of twice in Java. In Python and Ruby you don't declare them at all, resulting in type errors _all over the place_ and programs that run ~20 times slower; see http://shootout.alioth.debian.org/u64q/benchmark.php?test=al....
The Go compiler tells me which lines contain the type errors. Usually my program is correct once these errors are gone. Can't say the same for Python, whose apps can run for days before a corner case is hit, exposing a type error that would've been caught at compile time in Go.
It's interesting that you mentioned Clojure. Well, it's powerful alright, but I found it to be extremely complicated (does a language _really_ need 4 kinds of concurrency and to consist of literally 500 functions?)
If you believe as I do -- as do most who appreciate small, simple, but extremely powerful languages like Python and C -- that simplicity is a feature, you will love Go. If you love Java, C++, D, and other huge languages, consider those or something like Scala or Clojure instead. IMO, doing so means giving up clarity/comprehensibility for a longer list of features, almost all of which _can_ be useful, but all of which make mastering the language much more difficult.
Go has been my favorite language for about a year now. Its only weakness is lack of library and/or framework support, which is an occasional bummer.
That said, I very strongly recommend giving Go a try if you haven't already. I played with Clojure for months till it finally made sense and I saw how powerful it _could_ be, but I still couldn't do anything with it that I couldn't do in Python.
After 2 hours with Go (1.5 years ago), I wrote my first ever concurrent program... _trivially_. This can not be stressed enough. Want a function call to `f` to be non-blocking? Type `go f()`. Yes, it's that simple. Launch a couple functions like that, and bam, you're doing extremely efficient concurrent programming.
If you want the convenience of Python or Ruby plus the speed and type safety of C++, give it a shot! http://golang.org
I could not have imagined writing this in Python or Ruby and I don't know Clojure at all.
Go was good because it's close to a systems language and has great concurrency mechanisms. The program makes extensive use of goroutines and channels for communication. I also make use of a large number of packages from the Go library as well as one external package for memcached integration.
The total code is about 4,000 lines.
Did you run into any difficulties managing 4000 lines of code?
We were actually having a talk today about using it here on an embedded Linux device we produce. I'm not very confident anything will come of it but I think it would be a good fit.
Mono also offers the possibility to fully AOT your .NET application.
Most Java VMs can be made to fully JIT the code, bypassing any interpretation with flags similar to -XX:CompileThreshold in Hotspots' case.
If you prefer compile Java directly to native code, you can make use of gcj, Aonix Perc or Excelsior JET.
Language != Implementation
> The biggest benefits over python/ruby are static typing and that it is compiled.
Yes, it's awesome. :)