Hacker News Reader

Comment by avitzurel | Hacker News Reader

I love Go.

It has become the default Go-To (pun intended) language for me for almost anything that needs to be small and portable.

However, I don't see myself writing a full server with it, I would still prefer a dynamic language like Ruby/Python for that and use Go for micro-services CLIs and the rest.

For example:

Our main application is Rails, it communicates with SOLR as the search index, in between the application and SOLR there's a proxy server that backups the documents onto S3 and also does Round-Robin between slaves.

One other thing is that we use Go to communicate with all external APIs of 3rd parties, the application code is rails and it communicates transparently with a Go server that fetches the data from 3rd parties and responds to the main application.

View on HN

Go type rigidity makes Go code tedious to write. Instead of thinking "How can we solve that problem" developers writing Go end up thinking "How can we make the problem fit Go type system". I'm not even talking about concurrency here, I'm talking about Types. Saying otherwise would be dishonest, unless one has never used anything but C... Anybody who doesn't believe me just has to look the reflect package. Reflection packages are usually a good indication of language capabilities when it comes to statically typed ones.

It doesn't make Go a bad language,it has a some good percs, it's just frustrating that its authors conflated simplicity with rigidity. Also I hate when languages have hidden APIs, i.e. things the language can do that the programmer can't. Go is full of these (for instance append which is a parametric function since it knows the proper return type no matter what type of slice you pass it, but you can't write your own? ).

It's good think that it requires very little investment to get started, but it becomes highly frustrating when one stumbles on its limitations.

I've been writing Go daily for almost two years now and outside of wishing for generics a few times I've never struggled to fit a solution into the type system. I've certainly never considered going back to a duck typed language like Python or Ruby. Not once. Not ever. We have slowly replaced even our glue scripts that are written in Python with Go versions because maintenance and understandability trump any perceived speed advantage of writing something in Python.

As soon as a system reaches a given size, not having static types becomes unwieldy. Go's type system is great. Though my code still uses the var type declarations.

The further I get away from Python the smaller that given size limit becomes. After two years? It's at about 100 lines...

To me, the power of Go's simplicity is almost always underestimated by the language's detractors. I can look at code my team wrote two years ago and with a few <leader>gd's in Vim I know what's going on. Obviously Python fails this test, but even a high-level static typed language like C# can suffer greatly from all the magic one can invoke (Linq being a great example).

What it comes down to is that Go doesn't give you many ways to be clever. Younger me who loved template metaprogramming in C++ would scoff at this statement, but if you go back and have to reverse engineer your own cleverness enough times you really, really start to dislike the practice.

Yeah, I find that Go has influenced my code structure for the better in other languages. I'm much more likely to think carefully about a problem and consider alternative approaches for simplicity before just dropping a `template` keyword in C++, for instance. In Ruby, I am far less inclined to reopen classes. Etc.

Exactly what I tell people I like most about Go, even when there are magic things happening (looking at you, Kubernetes source code), it's not NEAR the level that a language like Ruby makes the code look like arcane magic.

Python is in between, I can find myself pretty damn well in a big Python codebase after awhile but Ruby... Ruby is a pleasure to write first and get lost later, I've done too much of it to like, all of the metaprogramming is gonna come back and bite your mind chunk by chunk when the codebase gets big enough. Few times I've been more frustrated in my life than when debugging Ruby and thinking "where the hell is this function defined at?" to find out it was some sort of generator stuff spitting out code.

All languages require investment. Zero sum game, with some opting for syntactic simplicity that entails a long term investment of "idioms", subtle semantics, post-processing, etc., and others present a high initial investment and subsequent clarity, regularity, and possibly robustness. C/Go/Java/C# are in the former category. Scala, Haskell, Rust, for the latter.

(C++ uniquely bites you at both ends :)

It is not a Zero sum game. The moment you actually need to maintain a large codebase for years, strongly typed languages are much more cost-efficient.

Finding out, with absolute certainty, which code calls which code under which circumstances is a life-saver.

Any modern IDE for JVM languages accomplishes that.

It's not enough for your code to be readable. It needs to be statically traceable.

> absolute certainty

I completely agree with your overall point, but typically reflection will inhibit truly 'absolute' certainty.

Also to add on this...

All of my lambda functions are a thin Node wrapper on top of Go applications.

The go application is simply a command line accepting JSON via stdin (from the Node wrapper). It is a Joy to test, you can run it locally/independently etc...

[Edit]: Typos fix

Do you use a library or toolkit for this? Or is there an example of this that you can point me to? This sounds useful with or without Go

Quickly open sourced as promised:

https://github.com/KensoDev/sns-lambda-notifier-golang

It's simple enough to understand with absolutely no documentation. But here's the gist.

You develop in Go, you can run tests or run it independent from the lambda and then, when you want to deploy you run `release.sh`.

This is perfect for web callbacks, SNS notifications etc...

Let me open source something real quick. Wouldn't call it a toolkit but might be useful for some people.

https://apex.sh is nice

Likewise. I use for set and forget services. Once a Go application has been properly tested it runs quietly like a mainframe in the corner of a datacenter.

Same experience here. Writing tiny, focused, small footprint services with Go has been a blast. It really has its niche. Especially since learning to write (and read) Go is a matter of hours, more than days (or even weeks).

I have been running multiple programs on my DO vps, my uptime is 305 days. 1 program was updated in Feb to accommodate an API change another was updated in Dec 2014.

It's amazing how good they perform with minimal memory usage.

Given the low API limits on most services, what was the reason you went with Go for those integrations as opposed to ruby / rails?

I wrote a bit more in length about it here: http://www.avitzurel.com/blog/2015/06/13/scaling-gogobot-usi...

In this blog post the previous solution is presented using Nginx, now it's Golang similar to Templar (mentioned in the post).

Reply on news.ycombinator.com