[cs648]

Seems to be an ever increasing trend to replace Python components experiencing high load with ones written in Go. Is this Go's niche? Definitely a language I will be learning in the near future, it doesn't seem like it will be going away any time soon.

[enjo]

I've settled on Go to replace a worn out Java mess (otherwise a Python shop). We need the computational performance, and I do like the general feel of the language. I think this is something you're going to see a lot of going forward. It's the same niche Scala has been filling to an extent, but I personally think Go is a much better option (unless you need the JVM of course).

[kasey_junk]

Is there evidence that Go is better than Java in computational performance? Truly curious are their links?

[burntsushi]

You might have misunderstood the parent, I think. It seems like he was saying that they used Java (and then Go) in lieu of Python because of the performance.

But to answer your question, the Language Shootout seems to suggest Java and Go are on the same plane in terms of speed. Take that with however many grains of salt you like.

[zik]

It's also interesting that according to the Language Shootout Go uses a fraction the memory of Java - meaning you can save a lot of money by deploying it on cheaper machines or VMs and get similar performance to Java.

[JulianMorrison]

I just checked out the language shootout. Go has really pulled ahead from where it used to be. Faster than SBCL or Ocaml or Free pascal on quad core 64-bit - that's impressive.

Clojure's done some impressive improving, too.

[jackielii]

And be aware that Go is quite young compared to Java, the optimisations will be better and better

[rubinelli]

I wouldn't use Go for high-frequency trading systems yet. But you get 80% of the performance with a lot fewer type declarations.

[kasey_junk]

I can use Scala and not pay that penalty. I'm looking at Go to replace components of my system where I don't want a full bore JVM, but I have to be thoughtful about latency. I prefer C for this (C++ seems to be the standard there). Would love to move to something like Go once I can.

[karaziox]

Well some persons are ready to trust Go even for this http://andrewwdeane.blogspot.de/2013/05/the-reliability-of-g...

[TylerE]

I'd say Go's niche is pretty much any sort of network server. Right combination of high performance, easy multithreading, and making it hard to shoot yourself in the foot (no buffer overflows, for instance)

[bayesianhorse]

I've heard this several times. But the success stories are mostly concerned with smaller parts under heavy load. Go still is a lot harder to work with than Python if you know Python and its tools well...

With Go you don't have anything comparable to Django, Numpy, Pandas...

[up_and_up]

> With Go you don't have anything comparable to Django, Numpy, Pandas...

Given the age of the language I would assume building out its associated toolchain is only a matter of time. Python didnt ship with Django, Numpy, Pandas...

[adw]

Python is rapidly becoming the lingua franca of data science; but there the vast majority of your inner loop isn't Python (numpy, scipy, pandas, numba, theano; C, Fortran, assembler, Cython, LLVM, CUDA...).

Basically Python is the glue language data people wanted, it turns out.

[MetaCosm]

The best parts of python... are C.

[nostrademons]

The most-frequently-executed parts of Python are C. The best part is being able to glue all those together easily.

[bayesianhorse]

It will be a matter of years. I for one, am developing stuff today.

[up_and_up]

As are most of us lol. I would say if you want to use golang for a serious project and need additional libs you have to ready to write it yourself, which grants the opportunity to give back to the community and contribute to open source etc.

[mattrobenolt]

This is very true. We're definitely looking at Go for "services", not as something to replace our entire Django app with.

[caycep]

Will this change with time? I know numpy, pandas and matplotlib are likely relatively large projects, but my assumption is someone will likely put together data analysis / matrix math libraries to perform some of these functions.

[jre]

I think Julia (http://julialang.org/) might be a better alternative to Scientific Python than Go. I'm not sure you can get the same flexibility/expressiveness you get in Numpy/R/Matlab in Go.

[dom96]

I find it rather annoying that everyone seems to be advocating Go, it may be a good language, but I can't help but feel that the only reason it's being used is because Google's behind it. You guys should look into alternatives like Nimrod (http://nimrod-code.org/), which is in fact a lot closer to Python than Go will ever be.

[MetaCosm]

People are advocating Go because it delivers. It has great concurrency primitives (channels), it is "boring" language syntax wise, and it is fast.

Beyond that, it deals with a lot of the 'ugly' things around the edges of other languages. Dependency management, build management, deployments... all these IMHO are much more well thought out in go.

[Araq]

It delivers? Lol. The GC used to suck for 32 bit systems and it still sucks for realtime. As opposed to Nimrod's which pretty much guarantees a maximum pause time of 2 milliseconds -- independent of the heap size. And that's only the start: Go also lacks generics and meta programming in general. And its memory/concurrency model is just as racy as Java's.

[karaziox]

Go was never designed for "realtime". Also, 32 bits wasn't the main compiler focus, 64 bits was. This problem being mainly fixed with the 1.1 release, this is a non issue now. The memory model seems pretty well defined without being too restrictive, with the recent addition of the race detector.. Go looks well equiped for this kind of problems and some pretty interesting projects are there to prove it.

[MetaCosm]

You are correct on some points. 32 bit was broken, realtime is a non-feature. It does (by design) lack generics and meta programming (Pike talked about these at length at one point).

I have to disagree on the concurrency model, I think message passing channels are a much more natural primitive to model concurrency in, and goroutines are exceptionally light.

EDIT: When you talk about nimrod, you might go ahead and mention you are the designer of nimrod... it might color your judgement.

[mwcampbell]

"Nobody is smart enough to optimize for everything, nor to anticipate all the uses to which their software might be put." -- Eric Raymond, _The Art of Unix Programming_

Go's primary niche is server software, and in that niche, it is gaining in popularity and has the backing of a large company. For servers, neither support for a 32-bit address space nor real-time support is important.

Does support for generics really matter when the language has built-in support for the most common collection types?

The allowance of shared mutable memory between goroutines does worry me somewhat.

[sergiotapia]

Personally, having it backed by Google makes Go better in my opinion. I feel a ton of smart, very insane individuals are working on it and it can only get better.

Nimrod? Never heard of it or the person backing it.

I'm _not_ a language snob, trust me! I'm just a regular, family guy, software developer and I try to put my proverbial eggs in reliable baskets.

Go doesn't seem to be going away any time soon and it's really really fast.

[dom96]

If you want to put your eggs in reliable baskets then why not use Java, or C#, or even C++. Those languages are most definitely not going to go anywhere anytime soon.

[sergiotapia]

Because I already know C#, and why waste time learning Java which is very similar; what would I gain?

I chose Go over C++, because it looks easier.

[dom96]

What do you gain from learning Go?

[sergiotapia]

Obscene speed and learning a language built with concurrency in mind.

[genwin]

Go's goroutines are superior to threads in C#.

C++ is harder and there's no garbage collection.

I now have to yet again close my apps and restart my computer for an IT-forced Java runtime update, for some app I rarely use. For that reason alone I'd not consider Java.

[dom96]

From what I can tell Go's goroutines are pretty similar to C#'s await functionality.

But I don't want you to use C#/C++/Java, I want you to use Nimrod.

[genwin]

I forgot that C# added more asynchronous stuff since I last coded in it. I used to love C# but it's more verbose than Go and I'm weary of the obfuscated MS documentation that pushes me straight to blogs. Also I gave up on using Windows for web development.

This is the first I've heard of Nimrod.

[Paradigma11]

Plus there is rx reactive, tpl and tpl dataflow.

[mwcampbell]

If I'm not mistaken, that's a fallacious slippery-slope argument. I'm still undecided on how to weigh language popularity against other factors, but surely relative popularity is an important factor in things that have a big effect on real-world software development, such as availability of libraries and tools. For now, at least, Go is much more popular than Nimrod, and also has more people working on the language implementation and surrounding tools.

[nobleach]

Perhaps. But in my travels, I have yet to find anyone really pushing Dart just because it's google. (perhaps it's still too early)

[hcarvalhoalves]

I believe Go purpose is exactly that of replacing more familiar languages with a static compiled version that is palatable. It's fulfilling a niche where, otherwise, one would resort to C/C++.

[mattrobenolt]

If you're CPU bound, I think it's a good option to at least check out. It can work with real threads, and doesn't compete with the GIL. In our case, our actual CPU was low, but due to the high concurrency, any little bit of CPU work requires a context switch and contends with everything, for a little work. We alleviated that by just using a bunch of processes.

Will it replace all of our Python? Highly doubt it. Some very specific pieces? Probably.

[james4k]

Do you know about GOMAXPROCS? Sounds like tuning it could help.

[mattrobenolt]

I was referring to our Python processes being CPU bound. Not Go. :) Yes, I'm familiar with GOMAXPROCS.