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

301–310 of 384 posts

Re: Program your next server in Go

#301

Post by etatoby »

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…

Just a quick note about dependency management: we use "go get" to download / update dependencies, integrate / test, and then just include them all in the project's git repo. Never had an issue.

Re: Program your next server in Go

#302

Post by piaste »

spinlock wrote: post #171
nameless912 wrote: post #73

Earlier quoted context omitted.

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.

Personally, I think "cowboy coding" is the best derogatory name for this. IMO, what all of these ninjas have in common is that they don't realize that software development is a team exercise. Berkeley did a study on BSD and found that a file was opened 10x more often for reading that writing (i.e. people read code 10 times for every time they make a change). To my mind, "cowboy" conveys the proper amount of ignorance…

"Cowboy coding" already has a distinct meaning - it refers to writing code as fast as possible without concerns for technical debt.

The archetypal form of cowbody coding is the copy-and-paste: faster than any code reuse technique, but a booby trap for the future.

"Ninja coding", on the other side, refers to coding for cleverness' sake, at the cost of legibility and ease of use. No self-respecting ninja would simply copy-and-paste.

Re: Program your next server in Go

#303

Post by amelius »

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…

> 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

Could the problem have been the "global interpreter lock"? The GIL makes it impossible for multiple threads to simultaneously perform certain basic operations, effectively making the system single-threaded.

Re: Program your next server in Go

#304

Post by pjmlp »

dalailambda wrote: post #214
courtf wrote: post #188

Earlier quoted context omitted.

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…

That's interesting. The cgo overhead was the only thing holding me back from considering it for games, since I didn't want to write a lot of C wrappers around the C libraries I want to use just to have them be more efficient, which is a shame, since Go is pretty nice, barring the C interop in some cases.

When I used to frequent gonuts, I raised the issue why they didn't went the FFI way as D, Rust, .NET, Delphi, FreePascal do, but sadly they rather use cgo as solution.

Re: Program your next server in Go

#305

Post by amelius »

weberc2 wrote: post #259
infogulch wrote: post #156

Earlier quoted context omitted.

How do you do this? I didn't know there was a way to temporarily disable the GC for specific blocks.

You can toggle the GC with https://golang.org/pkg/runtime/debug/#SetGCPercent . Turn it off before you enter your block and enable it again at the end of your block.

But can you guarantee that the GC actually makes progress that way?

Re: Program your next server in Go

#306

Post by gizzlon »

brobinson wrote: post #236
enneff wrote: post #204

Earlier quoted context omitted.

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

You're welcome to benchmark it yourself. I got it from [1] which is a pretty recent comparison. [1] http://www.jtolds.com/writing/2016/03/go-channels-are-bad-an...

GP said meaningless, not wrong

Re: Program your next server in Go

#307

Post by pjmlp »

cryptos wrote: post #292

There are some questionable statements: > Go differs from Java in several ways > Programs compile to machine code. There's no VM. This tries to imply that having a VM is a bad thing. > Simple, concise syntax The syntax is simple, but not overly concise. For example the lack of generics leads to a lot of repetition. > Statically linked binaries You can have them with Java, too. > Built-in strings (UTF-8) Should this s…

Java also enjoys AOT compilers to machine code, but the fact that only commercial JDKs support it makes many ignore that little fact.

Maybe with the upcoming AOT compiler in Java 10, more people will become aware of it.

Sadly it appears to be a commercial feature.

Re: Program your next server in Go

#308

Post by dalailambda »

pjmlp wrote: post #304
dalailambda wrote: post #214

Earlier quoted context omitted.

That's interesting. The cgo overhead was the only thing holding me back from considering it for games, since I didn't want to write a lot of C wrappers around the C libraries I want to use just to have them be more efficient, which is a shame, since Go is pretty nice, barring the C interop in some cases.

When I used to frequent gonuts, I raised the issue why they didn't went the FFI way as D, Rust, .NET, Delphi, FreePascal do, but sadly they rather use cgo as solution.

I'm pretty sure the problem is Go's use of segmented stacks and runtime, which makes it hard to properly interface with C efficiently.

Re: Program your next server in Go

#309

Post by fortytw2 »

egeozcan wrote: post #293
FlyingSnake wrote: post #291

Earlier quoted context omitted.

> Rust over Go Rust: Best suited for writing OS, network stack, embedded systems, and webservers like Nginx. Go: Best suited for writing micro-services, CRUD apps, API servers etc pick your poison

I did write a CRUD app with Go and after that experience, IMHO, for CRUD apps, one is better off with a dynamic language (JS, Ruby, Python) or a static one which supports generics (C#, Java) or Macros (Nim).

Right on. Go is best suited for network-heavy, concurrent applications (infrastructure systems, databases, OS-tools), or software that needs to be dead easy to set up / deploy (single static binary, free cross-platform compilation).

If you want to go build a CRUD app, use RoR/Django/Whatever(tm) and be happy with it

Re: Program your next server in Go

#310

Post by pmontra »

slmyers wrote: post #283
mahyarm wrote: post #252

Earlier quoted context omitted.

In my experience programming speed goes like this: - 1x benchmark - C / static C++ - 2x slower - pure virtual C++ / objective-c - 3x slower - statically typed GC languages (java,go) - +6x slower - dynamically typed GC languages (js, python, etc) After a well optimized implementation, speed comes down to manual vs GC memory management, static vs virtual function dispatch, dynamic vs static typing and heap vs stack all…

Sorry, but I feel like I'm a little confused by your post. How can it be 6 times slower to program in JS or Python than C? Isn't this very much contrary to the conventional wisdom?

I think OP wrote programming speed but meant running speed.
Post reply on HN