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

101–110 of 384 posts

Re: Program your next server in Go

#101

Post by kmiroslav »

yanilkr wrote: post #41

I once tried to convince an enterprise java developer to give golang a try. The guy passionately hated it and the reasons were very very petty. The other younger engineers who did not have prior bias loved golang and they were productive so fast. The person truly had a java supremacy attitude that was very difficult to deal with. Golang is a kind of shift in thinking that you have to first unlearn your existing ways…

> 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, but anyone who's used to static types and generics will usually see Go as a step back and refuse to take that step (for good reasons in my opinion).

To draw an analogy, imagine a Go developer is being asked to switch to Python and in order to convince them, you tell them they just need to unlearn a few things. To them, you are asking them to give up types and other practices that makes their code more robust, so it's not an acceptable argument.

Re: Program your next server in Go

#102

Post by courtf »

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 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 the past. I'd take the current GC over dealing with other strategies unless you are a very specific, >60fps kind of situation. We literally don't think about the GC anymore.

Random stats from one of our busier nodes, over the past 20 min: 40GB currently in use, 391GB allocated (and freed) in the last 20min average of 2.6ms GC pauses every 70.6s 95th percentile on GC time is 7.26ms

For dependency management, there's a lot of tools that make things more automated and I think probably offer people what they are expecting/used to from other environments. This has been a sticky point for sure. I've settled on a bare bones solution that seems to work well: just using git submodules in the vendor directory within the project repo. Does everything I need (pin to version of a fork, build immediately after a clone and a submodule update --init). As of Go1.5, the vendor directory is supported by the compiler, and it will look there first to resolve dependencies. While this does work with recursive dependencies, you will want to flatten the dependency graph as much as possible if types are being used across multiple deps because types are distinguished by their full import paths. This encourages breaking things into modules so I'm ok with it.

First-tier support is a problem I have no doubt, but not one we've suffered from personally.

I'd say that debugging comes up a lot too, and Go doesn't have an official, reliable option for debugging. The Delve project is getting close to that though it looks like. I personally debug with the stdlib pprof package (provides an http server that prints stack traces for all goroutines currently active, allows cpu/memory/blocking profiles to be requested), print statements, general testing/experimentation and newrelic.

Re: Program your next server in Go

#103

Post by phpDie »

harikb wrote: post #23
phpDie wrote: post #7

You lost me at not being able to navigate your slides with my mouse. That a Go feature?

You can also use left right keys to navigate. Just doesn't work with scroll wheel, if that is what you were expecting.

It doesn't work well being a user. Which is what i was expecting.

Re: Program your next server in Go

#104

Post by robohamburger »

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 would contend that java should be considerably lower on the fun scale. Maybe they are counting other languages that target the JVM?

Also perl is apparently as fun for humans python which I also find suspect after maintaining perl 5.x code.

Turns out this subjective made up graph is subjective and made up I guess.

Re: Program your next server in Go

#105

Post by mattetti »

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 only a few 3rd party dependencies that are vendored or available via private git repos. We don't use Google cloud but I heard they have 2 repos, one that has auto generated code and one that has hand written code (but less complete).

Re: Program your next server in Go

#106

Post by yanilkr »

kmiroslav wrote: post #97
yanilkr wrote: post #41

I once tried to convince an enterprise java developer to give golang a try. The guy passionately hated it and the reasons were very very petty. The other younger engineers who did not have prior bias loved golang and they were productive so fast. The person truly had a java supremacy attitude that was very difficult to deal with. Golang is a kind of shift in thinking that you have to first unlearn your existing ways…

That's odd. I think the absence of generics in Go is a reasonable answer for a JVM developer to justify they are not interested. No need to go petty.

This feeds into language supremacy mindset. There is no universal best language nor there will ever be the one.

Right tool for the job is a better flexible mindset. If you are a master painter, you could paint something amazing with anything you have got. Same thing applies to programmers.

Re: Program your next server in Go

#107

Post by fpgaminer »

naivepiano wrote: post #91

I'm afraid HN has a serious problem with downvoters. Why -in heavens name- is the above a question that deserves downvoting? UPDATE: whoray - I got downvoted too. Gee man. Just not worth it. Buy and thanks for the fish.

I'd venture to guess because it has an unnecessary negative tone to it. Specifically the "Sounds stupid" part. That two word postfix is unnecessary to ask the question and adds a negative and dismissive attitude to the discussion. A good gauge for any comment here is "Would you say this at a business meeting?" I believe the answer here is that the snide remark "Sounds stupid" would be left off when speaking amongst professional company.

Re: Program your next server in Go

#108

Post by kmiroslav »

yanilkr wrote: post #106
kmiroslav wrote: post #97

Earlier quoted context omitted.

That's odd. I think the absence of generics in Go is a reasonable answer for a JVM developer to justify they are not interested. No need to go petty.

This feeds into language supremacy mindset. There is no universal best language nor there will ever be the one. Right tool for the job is a better flexible mindset. If you are a master painter, you could paint something amazing with anything you have got. Same thing applies to programmers.

> There is no universal best language nor there will ever be the one.

I never made that claim, I just emphasized the widely accepted fact that having types is better than not having them.

To a Java developer, Go feels like the Java of ten years ago in that respect, so you will encounter some justified push back.

> Right tool for the job is a better flexible mindset

Of course, but not all tools are equal. In programming languages, languages that have a static type system have an insurmountable advantage of dynamically typed ones.

Re: Program your next server in Go

#109

Post by jdmichal »

yanilkr wrote: post #106
kmiroslav wrote: post #97

Earlier quoted context omitted.

That's odd. I think the absence of generics in Go is a reasonable answer for a JVM developer to justify they are not interested. No need to go petty.

This feeds into language supremacy mindset. There is no universal best language nor there will ever be the one. Right tool for the job is a better flexible mindset. If you are a master painter, you could paint something amazing with anything you have got. Same thing applies to programmers.

> Right tool for the job is a better flexible mindset. If you are a master painter, you could paint something amazing with anything you have got. Same thing applies to programmers.

I find the opposite for practical arts: The better the practitioner, the more reliable their tools must be, not less. A beginner painter might not be able to point out a bad brush from a good one; a master absolutely will. Furthermore, a bad brush won't necessarily hinder a beginner painter, but it will absolutely hinder a master painter. There are simply some techniques that the master will not be able to execute unless the brush is of a good enough quality.

Re: Program your next server in Go

#110

Post by akavlie »

erikpukinskis wrote: post #84
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…

> They autogenerate all API libraries for golang, which means they're not idiomatic, are convoluted to use, and the documentation is a jungle. Are idiomatic API libraries really a good thing? If an API is used heavily throughout your application, doesn't that mean it's time to wrap that part of the API in some idiomatic wrapper code that is meaningful in your domain? Functions are idiomatic in all languages. Personal…

You're arguing that it's good to (intentionally) break with common code idioms for certain classes of libraries??

Also, have you actually seen the auto-generated APIs he's referring to?

Here are the Godocs for the BigQuery API: https://godoc.org/google.golang.org/api/bigquery/v2

Here's some example code demonstrating the API's bad habits -- such as deeply nested struct pointers, and Do() methods everywhere: https://github.com/google/google-api-go-client/blob/master/e...

Post reply on HN