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

201–210 of 384 posts

Re: Program your next server in Go

#201

Post by davidw »

im_down_w_otp wrote: post #198
davidw wrote: post #189

Earlier quoted context omitted.

See my other reply though: it's not just about the API, which is nice, but about getting the architecture right. It does make the system more robust, but it requires more thought and planning.

Sure. Once you cross that barrier, you now have unlimited ammo and all the feet that ever were or will be, so you have to be a lot more diligent about what you're doing.

I guess my point is that in, say, Tcl, you pretty much just worry about calling out to the C code and if it takes 2 seconds to process an image or whatever, so be it. You merrily go about your business once the call returns. In Erlang there's more to think about.

Re: Program your next server in Go

#202

Post by IndianAstronaut »

hesdeadjim wrote: post #144
spriggan3 wrote: post #54

Earlier quoted context omitted.

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…

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

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.

Re: Program your next server in Go

#203

Post by enneff »

MustardTiger wrote: post #55
nimmer wrote: 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.

The go devs are very careful to avoid mention of all the other languages that compete in the same space and are significantly better.

bradfitz created that graph from his subjective experience, and he was talking about the state of things in 2009.

FWIW, here's the Go project lead congratulating Rust on their recent birthday: https://twitter.com/_rsc/status/732379957129826305

Re: Program your next server in Go

#204

Post by enneff »

mappu wrote: post #181
brobinson wrote: post #173

Earlier quoted context omitted.

>No locks. I'm sure the author means there's no explicit locking done by the programmer, but readers should be aware that channels are actually implemented internally using locks (which are 4x slower than using a sync.Mutex yourself).

>channels are actually implemented internally using locks (which are 4x slower than using a sync.Mutex yourself). Is that for both buffered and non-buffered channels?

Channels are implemented using locks, but "4x slower" is a meaningless microbenchmark number.

Re: Program your next server in Go

#205

Post by tracker1 »

nameless912 wrote: post #74
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.

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.

GC has gotten significantly better the last few releases, I don't think most applications will notice.

Re: Program your next server in Go

#206

Post by im_down_w_otp »

davidw wrote: post #201
im_down_w_otp wrote: post #198

Earlier quoted context omitted.

Sure. Once you cross that barrier, you now have unlimited ammo and all the feet that ever were or will be, so you have to be a lot more diligent about what you're doing.

I guess my point is that in, say, Tcl, you pretty much just worry about calling out to the C code and if it takes 2 seconds to process an image or whatever, so be it. You merrily go about your business once the call returns. In Erlang there's more to think about.

I think that's technically true in Erlang as well... it's just that it makes all the other stuff that people expect from Erlang to mostly stop working smoothly. :-)

Re: Program your next server in Go

#207

Post by namelezz »

spinlock wrote: post #172
nimmer wrote: 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.

I'm just amazed that yavascript wound up on top.

JavaScript and Perl are fun to write. Not sure about maintaining large code base though

Re: Program your next server in Go

#208

Post by kkirsche »

mattetti wrote: post #105
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've been running splice.com on Go for 3 years now and handle 5TB of audio/binary data per day. Our memory usage is around 10-15MB per server and the GC pause time has been really low. You do need to stream your IOs instead of reading everything in memory. In regards to dependency management, we honestly had no issues and now with vendoring, it's even easier. We do use a main repo with lots of smaller packages and o…

Could you elaborate on what you mean by stream your IO? Is this just using buffered io it is there a concept I could read up on here?

Re: Program your next server in Go

#209

Post by reverius42 »

namelezz wrote: post #207
spinlock wrote: post #172

Earlier quoted context omitted.

I'm just amazed that yavascript wound up on top.

JavaScript and Perl are fun to write. Not sure about maintaining large code base though

Agreed. The definition of "fun to write" completely changes with respect to the size of the codebase, and the number of people working on it.

Re: Program your next server in Go

#210

Post by _ph_ »

pvelagal wrote: post #114
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…

Slide 13 ( https://talks.golang.org/2016/applicative.slide#13 ) is interesting. I was expecting Go to be very close to C/C++ on the X axis (fast/efficient) as it doesn't use VM, but it is more close to Java ?

Ideally, Go should be pretty close to C, but currently there are reasons for it lagging behind (though there are also Go programs which perform better than their C counterparts):

- The Go compiler certainly isn't as sophisticated as the better C compilers. It looks that the code produces by Go 1.7 is quite improves vs. 1.6 with the SSA compiler and I would expect further gains in future releases.

- The Go compiler does not offer optimization levels and overall is optimized for compilation speed to, so these tradeoffs could be limiting.

- While the Go GC is very good and improving, so that the pauses are very low, it does use CPU, also while running in parallel to the program. How much exactly very much depends on the allocation behavior of the program, but should be accounted for.

Post reply on HN