I've been using Go for 4 months now and I'm loving it.

The syntax is elegant, concurrencies consume an order of magnitude less in the memory stack and it has such a good performance benchmarking.

What excites me the most though is the TensorFlow wrapper for Go that Google has recently stated it's developing. It's a huge advance towards high-scale, real-time deep learning.

BTW, in a few days I'm giving an introductory workshop to backend development using Go, I'll talk about some of the examples mentioned for sure.

However, I know that Dropbox is one of the biggest Go users and it isn't in this success stories list. Anyone knows more about it?

> However, I know that Dropbox is one of the biggest Go users and it isn't in this success stories list. Anyone knows more about it?

Maybe the go devs see them as traitors for using rust for their core components. :P They were having memory consumption issues with go, so I'm not sure that would be the best thing to add to a list of success stories.

[1]: https://blogs.dropbox.com/tech/2016/06/lossless-compression-... [2]: https://news.ycombinator.com/item?id=11283685

I wonder what languages you are comparing it to. I wouldn't personally call Go's syntax elegant or its performance good, but it's all relative. Wrappers for C++ libraries are likewise hardly exciting given the ease of creating them for almost any language.

> However, I know that Dropbox is one of the biggest Go users and it isn't in this success stories list. Anyone knows more about it?

they still use go for a lot of things, rust for a niche, which is why i made the other comment in this thread: we need to see more rust success stories (and nim, and elixir, and julia, and R, et cetera) because we need to be able to evaluate the best tool for a particular task. at this point everybody worth their salt in programming is a polyglot. "oh yah, i write everything in Go [but my html templates are all javascript]".

anyway, here's dropbox on go:

https://twitter.com/jamwt/status/629727590782099456

I've been writing Go daily for various security project for over 3 years now, and so far it's been a trusted ally. I can't remember being anywhere as productive in any other language I've used in the past.

But which other languages have you used? I'm genuinely curious.

When I look at Go I see a platform that looks highly unproductive relative to what I'm used to (JVM/Scala/now a bit of Kotlin). So I am often confused what people are comparing Go to that it seems so great. Python/Ruby?

This makes me happy.

Any rust thoughts,aside?

I've been watching Go from the sidelines for 2 years now. I do data engineering work and most of that is on the JVM (Spark, Scalding, Hadoop, Kafka). I wonder if there will ever be a push for Go in that space.

I know NSQ has been implemented with some good success but I see a lot more systems and web server articles about go thank any data engineer or scientific computing.

Why would you pick Go over Julia for that domain? Julia was made specifically for scientific computing, it's performant, has better array and number support, and allows unicode for mathematical variable and function names. It also has excellent concurrency like Go, but most of the work on the language and libraries is centered around data engineering and scientific computing.

People can use whatever language works for them, and Go has it's plusses, but I would hate to see popularity get in the way of a good new language like Julia in a domain it was intended for. It would be like if R were relatively new, and everyone wanted to use Javascript instead for statistical computing. Use the right tool for the job.

People want one tool to do all their work. Which is why Python took off in the ML and scientific computing space. The same language you use for data analytics is the same one you use for ETL, building a web backend, interfacing with the system, etc.

I've looked at Julia once or twice but at the time it wasn't mature enough to do what I needed. Sounds like I should give it another look though.

Have you seen this talk?

https://www.youtube.com/watch?v=D5tDubyXLrQ

I did see this. While interesting, it's pretty rudimentary in the Data world. Google is supposedly developing a TensorFlow API for Go, would be interesting to see deployments of that.

I am starting to use Go in the data engineering space. I use it for ETL processes I am running.

I see Go right now at the stage Python was in 2009 in regards to scientific computing. The libraries are coming into place and the community enthusiasm is there.

Although I haven't tried voth, I feel NATS is better than NSQ from the design view.

Golang big data world still lacks of the core components, such as Hadoop and Spark in Java.

at this point i don't think Go needs any more fluffing. its niche is pretty well established and people should just get on with writing code that does what they need.

go is asymptotically approaching boring and that's one of the goals of its creators. let other new programming language stars shine: i'd like to see the niche rust settles in for example, and that needs code.

I think this page (and other like this, e.g. https://quicknotes.io/n/1XB0) show that Go is no longer a "niche" language, unless you consider python and ruby a niche language.

Go is a general purpose language and people write many different kinds of programs in it: from command-line utilities to network tools like web servers and proxies and file servers to distributed databases to website backends.

As long as you keep calling it "niche" I guess we do need those kinds of articles.

Booo, what's up with the negativity? :)

I would love to see more of these stories but not just for Go, pretty much for anything under the sun, especially "old and boring" languages and technologies. I want to know in which situations people still choose C++ or even C for new projects today, I want to see who's using Pascal (and what for?), I want to see if anyone is dumping, say, Postgres in favor for Oracle.

At my previous job (Rackspace) I had the awesome unexpected benefit of sitting on sales calls with our enterprise team, listening to what well-known tech companies are doing "under the hood" and what problems they're facing and what solutions they're considering. On a number of occasions I've heard folks say "this is super, you should blog about it", so I say: the more the better!

It's just another opportunity to learn, not about "fluffing"

Let's note that Go approaches boring from below; it gives rise to much copy-paste programming and some clever code generation.

It's very easy to pick up, though, especially if you played with Turbo Pascal as a child.

> its niche is pretty well established

What's the niche?

distributed system components talking over the network. this is not my personal opinion.

that said, i use go for everything. although most of the go code I've written has been in end-user applications, tools, and services, I still open up a listening port on localhost and serve web pages for any visualizations that i need to present. get the job done in the most boring way possible. that's its niche.

Been using it for about 4 years. Currently have microservices that have been silently running (without issues) for more than a year. Its the language I use for set and forget services.

I finally came up with an analogy for Go to use whenever talking with someone on the fence of trying it:

"Golang is to dynamic web development what Laravel (and similar) are to Php".

My feelings are that if you're amazing at C++ or Java and you need to write a highly performant and scalable service you are probably best to stick with that. But if you're like most developers and not great at C++ or Java (and perhaps never will be) Golang is a superb middle ground that makes highly performant and scalable services more accessible to developers trying to tackle those problems for perhaps the first time.

I'd be interested to hear what the community thinks of the analogy.

As a C programmer I make a concious effort to ignore the possibility of using C for site specific code on the web, so I find C++ a stranger choice. For Java (or Scala), the problem is the baseline for running a VM. When I think of average Java webapp, I think of intranet apps doing nothing but needing 8GB of RAM. Java allows for good upward scalable design, but in average use it is like airlines buying fleets of spaceshuttles in case a new route is requested.

I think go solves my issues with using C, but introduces two others.. No one writes stubs to interact with go, just C, so I am not writing a permanent "neutral" resource. Go has (had I should hope?) the crazy static linking thing. I reject the possibility of using a static copy of any common code. Everything that could conceivably have a security bug should be forceably swapped by a rude package manager, such that my program breaks before running indefinitely with a disclosed security bug.

I don't want to disdain the success of Go, and I think the whole building of the community from the ground up is an achievement that few can say they were able to do.

However, what I dislike about all this is the generalization issues (like I saw on "Moving from Scala to Go"), which misses the point of history, and what to expect next.

First, saying "look how Go simplified our code by not allowing anything too complex" and using that example is very biased against someone that usually programs using applicative functors and don't really see anything overly complex in that code - besides some overly compacted structure which makes reading a bit hard. And that comes from someone that is not a Scala programmer, BTW.

In fact, from the "applicative functor" guys, most OO code would be deemed overly complex - and TBH with some sound arguments - but the "improved Java" camp would think that reasoning about shared mutable state is easier...

Second, the article tries to reason that it's a matter of being opinated, but it's not a matter of just being opinated: it's a matter of having that particular opinion, which means using simplified concepts without any ways to really elaborate them further, and having a more lax approach about exact semantics, types, etc. Very nice for beginners, as you don't really have much to learn, but most programmers that like it now would start hitting that expressivity ceiling soon.

Which brings me to the history part: it's funny to think that Java was born in a very similar way: no generics, tried to follow the most popular paradigm of the time as closely as possible and stay simple.. then people started using it, requesting improvements, and it became more and more complex after each release - until everyone realized that the very same thing that got everyone using it (simplicity) was not really there, as the complexity moved from the language to your code. Boilerplate over boilerplate, ever-increasing tightly-coupled frameworks, and there you go.

If I had to guess, I'd say 10 or 20 years in the future we may see the same happening with Go (if it tries to become more expressive) or it being put aside as a niche language (if it stays the same). But only time will tell it's fate.

I just simply love Go.

I've wrote a number of projects in go already, there are only a few things I'd love to see:

* A good UI library, there are some projects around Electron/Webkit wrappers, but otherwise only clunky Gtk/Qt bindings

* A good docker library that lets me manage containers on my own with the capabilities I need (my project does not need a FS, it only needs network and secure containment)

* More versatile cryptography options, I find the standard library to be somewhat lacking at times.

edit appendix:

* A more efficient memory allocator, in my experience the default memory allocator sucks. Sucks badly.

I would appreciate blogs about Go being used in MS heavy environments. Interacting with windows dlls is still a black magic to me.

Hi, i have a project in Go that interacts with a VC++ dll.

My approach was to wrap in extern C and use syscall.LoadLibrary() / syscall.GetProcAddress() as described on https://github.com/golang/go/wiki/WindowsDLLs . It was quite straightforward, i don't think there's enough information for a blog post.