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

181–190 of 384 posts

Re: Program your next server in Go

#181

Post by mappu »

brobinson wrote: post #173
shurcooL wrote: post #129

I like slide 41 [0]. What just happened? In just a few simple transformations we used Go's concurrency primitives to convert a - slow - sequential - failure-sensitive program into one that is - fast - concurrent - replicated - robust. No locks. No condition variables. No futures. No callbacks. It's the ability to make these kind of transformations effortlessly at any level, whenever I need to, that make me appreciate…

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

Re: Program your next server in Go

#182

Post by capote »

How do the bullet points in "Why does Go leave out those features?" address why Go leaves out the features on the preceding slide?

All it talks about is clarity (important but not the only important thing) and I just don't see how any of the left-out things are inherently unclear. I think you can write clear and unclear code alike with all of those left-out features.

Re: Program your next server in Go

#183

Post by themartorana »

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?

Use godep everywhere. It supports the vendor folder, and I find it's still a great solution (and saves me using submodules).

Re: Program your next server in Go

#184

Post by im_down_w_otp »

davidw wrote: post #151
sushisource wrote: post #147

Earlier quoted context omitted.

You are scared of Erlang because it has uglyish syntax. Only reason I can think of. The "need to do computation" argument is silly. Just call into a C lib from Erlang.

I think you're replying to the wrong person - they just asked a question about when Erlang might be a good fit. > Just call into a C lib from Erlang. That's easier said than done. Certainly possible, but it's not quite as easy as just linking and calling.

I think compared to most FFI API's the NIF interface is extremely clean and straight forward.

Re: Program your next server in Go

#185

Post by takeda »

weberc2 wrote: post #165
takeda wrote: post #146

Earlier quoted context omitted.

IMO switching an enterprise developer from language such as Java to Go is like asking someone who has very developed vocabulary in English to try Toki Pona[1]. Yes, it is simple, and you can learn it fast, you also can also communicate with it, but you will often have to fight with the language to express what you want. That person generally won't be satisfied. Go's shortcomings wouldn't be so bad if in exchange, the…

Your analogy seems weak at best. Go is mostly a subset of Java, so there's almost no difficulty in a Java developer learning Go. A Java developer can immediately read 90% of Go programs, and within a couple of hours, he can write real, interesting programs. I'm not sure that a good analogy could be made incorporating English, nor do I think there's value in doing so.

I don't think you understood my analogy. Go supposed to be Toki Pona.

I'm saying that once you are used to a language that's more powerful you feel constrained.

I know many languages and some bring interesting things to the table, go doesn't really deliver (at least based on the hype). The concurrency supposed to be the killer feature, but it is limited to specific cases.

BTW: The Go is not subset of Java if anything it's very similar to Algol-68 (http://cowlark.com/2009-11-15-go/)

Re: Program your next server in Go

#186

Post by vertex-four »

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.

So as someone who's written some Go, I'd argue that Go is the screwdriver - it's one of the only modern languages which explicitly refuses to tackle the error handling problem, which has resulted in some of my code being more about the failure case than the success case.

Of course, others will disagree - fine. But to argue that e.g. Java is definitely the screwdriver is a subjective judgement.

Re: Program your next server in Go

#187

Post by davidw »

spinlock wrote: post #174
davidw wrote: post #151

Earlier quoted context omitted.

I think you're replying to the wrong person - they just asked a question about when Erlang might be a good fit. > Just call into a C lib from Erlang. That's easier said than done. Certainly possible, but it's not quite as easy as just linking and calling.

I've found dropping down to C to be a pain to set up the first time in any language (Ruby, Tcl, etc...) but once you have the tooling, it's just another workflow. When you think about it, even JavaScript takes a lot of setting up these days (preprocessors, linters, endless debates about why coffeescript is still a good language (hint: it's the existential operator)). But, you amortize the cost of this setup over the…

Dropping down to C is pretty cool in a language like Tcl. To toot my own horn, a bit, I worked on those chapters here: http://amzn.to/1U6sFPN

Erlang is a bit different though: if you're really concerned about being 'robust' with it, you don't want to link in some random C code in the main node. Not only could it crash, it might simply block for an unacceptable length of time, messing up the system's internal scheduler and making it unresponsive to events.

So with Erlang, to do things properly, you need to get the architecture right as well, which makes it that much tricker.

Re: Program your next server in Go

#188

Post by courtf »

dalailambda wrote: post #163
courtf wrote: post #102

Earlier quoted context omitted.

We run a cluster of P2P, GPU heavy machines that use Go to ingest byte streams of raw radar data, store that info in btrees, and render, cache & serve map tiles that are drawn on the fly in response to http requests. We are not using much outside the stdlib (opengl and gdal bindings). Garbage collection has become very fast in recent versions of the language. It's quite painless now, and we did struggle with it in th…

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 GoC 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 drawing more than we need to. It's hard for me to tease apart how much of these optimizations (and others) are ultimately aimed at addressing the cgo overhead, and how many are just typical stuff. The data we work with is cumbersome and my intuition is that there's probably a lot of room for optimization in our drawing even still, regardless of cgo. I wouldn't be surprised if a direct port C/C++ implementation of the rendering pipeline was significantly faster than ours in getting data into and out of the GPUs, but a big part of the project is data storage/networking/serving/caching as well and Go has bridged the gap for us (a small team that needs to build reasonably fast things reasonably quickly :)).

Re: Program your next server in Go

#189

Post by davidw »

im_down_w_otp wrote: post #184
davidw wrote: post #151

Earlier quoted context omitted.

I think you're replying to the wrong person - they just asked a question about when Erlang might be a good fit. > Just call into a C lib from Erlang. That's easier said than done. Certainly possible, but it's not quite as easy as just linking and calling.

I think compared to most FFI API's the NIF interface is extremely clean and straight forward.

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.

Re: Program your next server in Go

#190

Post by jonathankoren »

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…

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

We'll just have to disagree about this point.

Post reply on HN