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

241–250 of 384 posts

Re: Program your next server in Go

#241

Post by pmarreck »

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…

Have a look at Elixir and Phoenix. GC is per-process so no global slowdown. Extremely fast response times and uptimes. Many other features that mesh nicely with webserving (some courtesy of Erlang's VM).

And a completely opposite philosophy from Go when it comes to error handling. Erlang/Elixir embraces failure (and immediately logs and restarts the process); Go seems to ignore it (unless you explicitly check, which to me seems... insane. For reasons why failing fast is better than failing silently, read https://blog.codinghorror.com/whats-worse-than-crashing/ .)

Re: Program your next server in Go

#242

Post by slimsag »

courtf wrote: post #188
dalailambda wrote: post #163

Earlier quoted context omitted.

How do you find the cgo overhead? Specifically with something like OpenGL, it seems like it would be a big pain point for rendering.

I don't have great measurements for this, but we have done optimizations to reduce the data flowing over the Go C interface. One of our key measurements that does make a big impact on performance is how often we need to upload data (that's not already over there) to the GPUs. So that's something we have worked on reducing (buffer reuse, compression). We also have a series of caches on the other side, so we aren't dra…

FWIW I did measure the CGO call overhead a while back: https://github.com/slimsag/cgo-batching

Re: Program your next server in Go

#243

Post by kasey_junk »

weberc2 wrote: post #161
kmiroslav wrote: post #101

Earlier quoted context omitted.

> you have to first unlearn your existing ways of thinking and then you will have a place for it. Unlearning is not always acceptable, especially when you have to unlearn sound and proven practices, which Go often requires to do. I think it really depends where you're coming from: people coming from dynamically typed languages like Python and Ruby are quite happy with Go since it's a small ramp up on the type ladder,…

> especially when you have to unlearn sound and proven practices, which Go often requires to do. Such as? I'm not really sure what "sound and proven practices" a Java developer would have to "unlearn" to adopt Go. Most of the differences between Go and Java amount to removing features that 20 years of Java experience have proved to be unsound or unnecessary (inheritance and exceptions, for example). From a feature pe…

Java absolutely does concurrency better than go. The only place the conversation is even close is the Golang scheduler.

But as far as abstractions, collections, libraries, profiling, error handling, etc the Golang concurrency options are worse than Java's.

I've come to the opinion that concurrency is a weakness of go, not a strength.

Re: Program your next server in Go

#244

Post by zalmoxes »

pmarreck wrote: post #241
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…

Have a look at Elixir and Phoenix. GC is per-process so no global slowdown. Extremely fast response times and uptimes. Many other features that mesh nicely with webserving (some courtesy of Erlang's VM). And a completely opposite philosophy from Go when it comes to error handling. Erlang/Elixir embraces failure (and immediately logs and restarts the process); Go seems to ignore it (unless you explicitly check, which…

To any Go programmers ignoring errors is insane. I haven't seen code outside of simple examples ignore errors, and even there it's discouraged.

Re: Program your next server in Go

#245

Post by kkirsche »

hobo_mark wrote: post #157

I might have strange requirements for a server, but I need rdma, verbs, libfabric... Is there any way to use them in an idiomatic way in go?

Not that I know of. That sounds like it goes against much of what Golang builds around and the areas I've had to hook into low level areas such as the kernel for NetFilter required me to go down to C

Re: Program your next server in Go

#246

Post by beders »

eternalban wrote: post #130
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…

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.

Re: Program your next server in Go

#248

Post by ThrustVectoring »

kmiroslav wrote: post #142
yanilkr wrote: post #112

Earlier quoted context omitted.

The good programmers I know are not attached to their tools. They prefer to use the right tool for the job. Many other programmers want to solve the problems using tools they know. There is nothing wrong with that. A company with good programmers who could do similar things more efficiently will add to competitive advantage.

Again, we all agree about the motto. If you need to screw something and you have a choice between 1. A screwdriver 2. Electric drill A 3. Electric drill B you will certainly look funny at someone considering the screwdriver over the alternatives. Someone who automatically narrows this choice between the two electric drills is not "attached to their tools", as you say. They are just picking the better tool.

I'd use a different analogy - there are definitely circumstance where you'd want the screwdriver over the electric drill. Screwdrivers can't run out of batteries, are lighter weight, and give you more feedback and control while being used. If I was going to be in a crawlspace for three hours doing wiring and knew that I'd need to drive in a screw at some point, I'd rather have the screwdriver on me than lug around or go back for the drill.

Re: Program your next server in Go

#249

Post by [deleted] »

zalmoxes wrote: post #244
pmarreck wrote: post #241

Earlier quoted context omitted.

Have a look at Elixir and Phoenix. GC is per-process so no global slowdown. Extremely fast response times and uptimes. Many other features that mesh nicely with webserving (some courtesy of Erlang's VM). And a completely opposite philosophy from Go when it comes to error handling. Erlang/Elixir embraces failure (and immediately logs and restarts the process); Go seems to ignore it (unless you explicitly check, which…

To any Go programmers ignoring errors is insane. I haven't seen code outside of simple examples ignore errors, and even there it's discouraged.

[deleted]

Re: Program your next server in Go

#250

Post by kyrra »

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…

Google has some fairly specific style guides for all languages used: https://github.com/google/styleguide/blob/gh-pages/README.md

Go to me feels like they implemented the Google Java and C++ style guides as a language.

Post reply on HN