Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Program your next server in Go

talks.golang.org

Post reply on HN
Print view View original

71–80 of 384 posts

Re: Program your next server in Go

#71

Post by skybrian »

spriggan3 wrote: post #63
fpgaminer wrote: post #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…

> 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. Go is certainly a language that is used at Google, but AFAIK a lot of "Googlers" don't really like it and don't use it. It certainly not the "official language at Google", given the weight of C++ and Java there. But that's the consequence of being opinionated. Using Go me…

It is one of the official languages. Google is too big a company to have a single official language.

Re: Program your next server in Go

#72

Post by kasey_junk »

stincity wrote: post #66
asolove wrote: post #61

Earlier quoted context omitted.

Presumably he is complaining about the GC implementation's characteristics, not its existence. You can read a description of the team's design decisions here: https://blog.golang.org/go15gc but a simple summary would be: memory is cheap and getting cheaper, so focus on making GC fast rather than small memory footprints.

Hasn't go been improving the GC with it's rounds of updates to the language?

Yes, with an emphasis on speed not memory.

Re: Program your next server in Go

#73

Post by nameless912 »

mseepgood wrote: post #67
spriggan3 wrote: post #63

Earlier quoted context omitted.

> 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. Go is certainly a language that is used at Google, but AFAIK a lot of "Googlers" don't really like it and don't use it. It certainly not the "official language at Google", given the weight of C++ and Java there. But that's the consequence of being opinionated. Using Go me…

What is "ninja coding"? Sounds stupid.

I think it refers to the Perl-era idea that good code should be somehow "clever" rather than maintainable. It's how bad programmers who spend hours agonizing over how to reduce their line count (presumably to save disk space?) justify their behavior.

Re: Program your next server in Go

#74

Post by nameless912 »

asolove wrote: post #61
devsquid wrote: post #57

Earlier quoted context omitted.

You would like to write an entire server without using a GC?

Presumably he is complaining about the GC implementation's characteristics, not its existence. You can read a description of the team's design decisions here: https://blog.golang.org/go15gc but a simple summary would be: memory is cheap and getting cheaper, so focus on making GC fast rather than small memory footprints.

And in my opinion, this is a great tradeoff. Ultimately, adding more RAM to a server (or clicking a button on the AWS console) is a very easy fix. However, reducing latency is almost never easy. If they can prevent GC stuttering, I'll take the higher memory overhead every time.

Re: Program your next server in Go

#75

Post by iagooar »

asimuvPR wrote: post #3
avitzurel wrote: post #2

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 applicati…

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).

Re: Program your next server in Go

#76

Post by nameless912 »

tokenizerrr wrote: post #6

What about debugging? This is the major pain point for me. I've tried using GDB, but... > GDB does not understand Go programs well. The stack management, threading, and runtime contain aspects that differ enough from the execution model GDB expects that they can confuse the debugger, even when the program is compiled with gccgo. As a consequence, although GDB can be useful in some situations, it is not a reliable deb…

There's actually a couple of native go debuggers these days. I don't remember what they're called off the top of my head, but the couple I've played with are very good, bordering on awesome.

There's also a go frontend to GDB that's okay, but going native is going to be a better choice in the long run I think.

Re: Program your next server in Go

#77

Post by avitzurel »

ketralnis wrote: post #25
avitzurel wrote: post #4

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

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...

Re: Program your next server in Go

#78

Post by callumjones »

I think "Program your next server in Go" is a little too broad, the specific language features that Go explicitly leaves out makes it hard to build an extensive backend server. Go is best suited to use cases listed in these slides: simple services that do very focused things.

I love Go and used it to build some very useful web hook and CLI tools. It just doesn't lend itself to something where you expect to have a vast set of APIs under one Go project.

Re: Program your next server in Go

#79

Post by sudhirj »

PeCaN wrote: post #51
yelnatz wrote: post #33

Earlier quoted context omitted.

When your server has to do some computations to return results. Erlang is bad at that.

Such as what exactly? "Computations to return results" is rather generic, to say the least (and, if ‘computations’ includes handling requests, something that servers tend to always do).

C is best at problems that are CPU and memory bound, Go can handle problems that are CPU bound-ish and goroutines help with IO bound problems. Erlang handles problems that are MASSIVELY IO bound.

Re: Program your next server in Go

#80

Post by avitzurel »

kasey_junk wrote: post #44
avitzurel wrote: post #8

Earlier quoted context omitted.

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.

Agreed. Check out my comments on this threads...
Post reply on HN