Live data from Hacker News

Program your next server in Go

talks.golang.org

41–50 of 384 posts

Re: Program your next server in Go

#41
I once tried to convince an enterprise java developer to give golang a try. The guy passionately hated it and the reasons were very very petty. The other younger engineers who did not have prior bias loved golang and they were productive so fast.

The person truly had a java supremacy attitude that was very difficult to deal with. Golang is a kind of shift in thinking that you have to first unlearn your existing ways of thinking and then you will have a place for it. Some people are not willing to take that leap of faith unfortunately.

Re: Program your next server in Go

#42
post #30
post #13

What are some cases where I would choose to write a server in Go instead of in Erlang?

First thing on duckduckgo when you search for how to write a server in erlang: http://20bits.com/article/erlang-a-generic-server-tutorial That's just ridiculous. Erlang looks like php and python had an unholy child.

If all you dislike is the syntax, you can use Elixir instead.

Re: Program your next server in Go

#43

Earlier quoted context omitted.

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

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

Re: Program your next server in Go

#44
post #5

The only place I would want to use Go is for a server tbh. It isn't all that great for anything else imho.

It is amazing for dev tools and CLIs. Perfect example for this is Hashicorps products, taking out Vagrant it is 100% written in Go. Having a single executable tool that you can download and run anywhere is super powerful. You develop once and you build it for every system. It's the definition of delight to me.

I'd argue that CLI tools are really a better example of what Golang is good at.

Most of the things purported to be major wins for Golang on the server side are available or better in other environments.

For CLI programs that need to be a little more sophisticated than bash Golang is quite nice.

Re: Program your next server in Go

#46

Earlier quoted context omitted.

> 5000+ developers across 40+ offices That's an enormous amount of manpower.

That doesn't matter. Only growth of manpower matters. The fundamental problem stays the same regardless of how many people you have. If you add code and revise 50% of it every month, the code base is bound to grow and the share of time spent on maintaining the old code grows as well until development of new code grinds to a halt. Unless of course there is massive growth in hiring. But that isn't sustainable. [Edit] W…

https://www.theatlas.com/charts/4ySTybWY

(Can't vouch for accuracy.)

Re: Program your next server in Go

#47
post #30
post #13

What are some cases where I would choose to write a server in Go instead of in Erlang?

First thing on duckduckgo when you search for how to write a server in erlang: http://20bits.com/article/erlang-a-generic-server-tutorial That's just ridiculous. Erlang looks like php and python had an unholy child.

Actually, it was more like Prolog self-pollination with a dash of acid. ;)

But seriously, the syntax is not that big a deal once you've understood it (and being permeable to the history behind it helps).

Re: Program your next server in Go

#48
post #41

I once tried to convince an enterprise java developer to give golang a try. The guy passionately hated it and the reasons were very very petty. The other younger engineers who did not have prior bias loved golang and they were productive so fast. The person truly had a java supremacy attitude that was very difficult to deal with. Golang is a kind of shift in thinking that you have to first unlearn your existing ways…

I program go full time and have for a couple of years. My biggest complaint about it is that there is some magical shift in thinking required to use it.

The only shift I've found is moving on when the Golang way isn't as good as other tools you are used to. Because the ecosystem & language really are not on par with other environments I've worked in.

Re: Program your next server in Go

#49
All of the server backends at my company are written in Go. This was a result of me writing a couple servers in Python a few years back, ending up with lots of problems related to hanging connections, timeouts, etc. I tried a couple different server libraries on Python but they all seemed to struggle with even tiny loads. Not sure what was up with that, but ultimately I gave Go a swing, having heard that it was good for server applications, and I haven't looked back. It has been bullet proof from day one and I am overall happy with the development experience.

That was the good. The bad? Garbage collection, dependency management, and lack of first-tier support in various libraries. Garbage collection makes the otherwise lightweight and speedy language a memory hog under heavy loads. Not too bad, but I have to kick the memory up on my servers. Dependency management is a nightmare; honestly the worst part about it. The lack of first-tier support in various libraries is a close second. AWS's API libraries had relentless, undocumented breaking changes when we were using them, all on the master branch of their one repo (breaking Golang's guidelines for dependencies). Google itself doesn't actually have any real API libraries for their cloud services. They autogenerate all API libraries for golang, which means they're not idiomatic, are convoluted to use, and the documentation is a jungle.

We continue to use Go because of its strengths, but it just really surprises me how little Google seems to care about the language and ecosystem.

Re: Program your next server in Go

#50
post #32
post #31

I'd love to see Nim on this diagram: https://talks.golang.org/2016/applicative.slide#13 - it could be close to the top right corner.

Absolutely. It's unfortunate that Nim is relatively unknown - here's hoping it gets a large backer sometime soon to boost its popularity! I'd also add D (above C++, level with Java) and Rust (above C++, close to Go).

And Crystal (http://crystal-lang.org/).
Post reply on HN