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

371–380 of 384 posts

Re: Program your next server in Go

#371

Post by brobinson »

gizzlon wrote: post #306
brobinson wrote: post #236

Earlier quoted context omitted.

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

I found switching from channels to plain ol' queues to be an enormous performance improvement in a program sending hundreds of millions of messages, though I do agree in general that most programmers won't need to care about it.

The program was a financial model backtesting framework which I ended up rewriting in Rust because Go was simply too slow for what I wanted to do.

Re: Program your next server in Go

#372

Post by rodrigocoelho »

brobinson wrote: post #371
gizzlon wrote: post #306

Earlier quoted context omitted.

GP said meaningless, not wrong

I found switching from channels to plain ol' queues to be an enormous performance improvement in a program sending hundreds of millions of messages, though I do agree in general that most programmers won't need to care about it. The program was a financial model backtesting framework which I ended up rewriting in Rust because Go was simply too slow for what I wanted to do.

Relevant: https://www.datadoghq.com/blog/go-performance-tales/

Re: Program your next server in Go

#373

Post by brobinson »

rodrigocoelho wrote: post #372
brobinson wrote: post #371

Earlier quoted context omitted.

I found switching from channels to plain ol' queues to be an enormous performance improvement in a program sending hundreds of millions of messages, though I do agree in general that most programmers won't need to care about it. The program was a financial model backtesting framework which I ended up rewriting in Rust because Go was simply too slow for what I wanted to do.

Relevant: https://www.datadoghq.com/blog/go-performance-tales/

This is great, thanks!

Re: Program your next server in Go

#374

Post by mratzloff »

kasey_junk wrote: post #322
mratzloff wrote: post #272

Earlier quoted context omitted.

You must explicitly ignore errors in Go. result, _ := someFunc()

Not if they are the only return value. You should use an analysis tool to avoid this but nothing about the language requires it.

Ah, you are right.

Re: Program your next server in Go

#375

Post by weberc2 »

eropple wrote: post #362
weberc2 wrote: post #359

Earlier quoted context omitted.

> Neither is a coroutine in Java using the Coroutines library (Javaflow used thread-locals, but Coroutines doesn't), or a Lua-based coroutine...I'm not sure what you're driving at here? I'm not familiar with Coroutines or Lua-based coroutines; coroutines are almost always bound to the thread on which they're created, I was pointing out that this is a primary difference between goroutines and coroutines--goroutines ar…

> coroutines are almost always bound to the thread on which they're created Can you provide a cite for this? I'm not saying you're wrong, just that I've never heard this assertion before (and I have been doing really stupid stuff with coroutines for way too long). My understanding of a coroutine is just that it's just a cooperatively yielding function where a yield returns a continuation for later resumption.

I don't have a cite for this; almost no coroutine implementations are multiplexed across threads. I spent quite a while Googling around, and I wasn't able to come across any thing. The stuff that I did come across (without searching for 'goroutine') were comparisons of coroutines and goroutines in which one of the defining characteristics seem to be the ability (or inability, in the case of coroutines) to be multiplexed across OS threads.

In general, the term "coroutine" has come to be pretty watered down.

Re: Program your next server in Go

#376

Post by IshKebab »

pjmlp wrote: post #328
IshKebab wrote: post #324

Earlier quoted context omitted.

Yes there are clearly examples where the loop is less clear than the function. But I think they wanted to avoid complex 'functional' code like this: Averager averageCollect = roster.stream() .filter(p -> p.getGender() == Person.Sex.MALE) .map(Person::getAge) .collect(Averager::new, Averager::accept, Averager::combine); System.out.println("Average age of male members: " + averageCollect.average()); From here: https://…

I can fully understand that example, only someone without FP knowledge would not get it.

Exactly the point. And that was a fairly simple example. I've seen much worse in real code.

Re: Program your next server in Go

#377

Post by pmarreck »

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.

But you still have to check for errors after every line of code where they are possible (if you're covering all the bases), no? Due to lack of a traditional exception model?

Elixir/Erlang at least have pattern-matching which makes checks like that (from functions that return a non-OK value on errors) basically inlined:

`{:ok, val} = call_some_func(with_args)`

If it doesn't match on the :ok (i.e., an error occurred), you get a match error which gets logged, and the process typically gets killed and restarted by a supervisor process in a millisecond.

Re: Program your next server in Go

#378

Post by trustyhank »

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…

Im surprised to hear your issues with Python, even Django can handle decent load depending what youre asking of it.

Re: Program your next server in Go

#379

Post by sdboyer »

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…

dep mgmt, at least, is poised to improve a lot in the coming months. we've got growing consensus around some metadata files, and i'm nearly done with my SAT solver (github.com/sdboyer/vsolver), which will be in glide, and maybe others, soon.

Re: Program your next server in Go

#380

Post by sdboyer »

fideloper wrote: post #139
nvarsj wrote: post #127

Earlier quoted context omitted.

> Dependency management is a nightmare Is it that bad now in 1.6 with vendor support? And a tool like `govendor` makes it easy to stick things inside of vendor. > it just really surprises me how little Google seems to care about the language and ecosystem To be blunt, google's priority is google, not the open source community or other companies using golang. Dependency management wasn't a priority because of mono rep…

is godep relevant still, or is 1.6 making something like govendor a "better" way to go?

it is, and works well enough for individuals, but doesn't make for the friendliest ecosystem.
Post reply on HN