Live data from Hacker News

Program your next server in Go

talks.golang.org

61–70 of 384 posts

Re: Program your next server in Go

#61

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…

You would like to write an entire server without using a GC?

Presumably he is complaining about the GC implementation's characteristics, not its existence. You can read a description of the team's design decisions here: https://blog.golang.org/go15gc but a simple summary would be: memory is cheap and getting cheaper, so focus on making GC fast rather than small memory footprints.

Re: Program your next server in Go

#62

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…

To be fair, Go's GC got A LOT better over the past few versions and it's getting much better still.

What I would really like to be able to do though is be able to write unmanaged blocks when I need them and know better than the compiler rather than having to "run my own heap" on top of a buffer like I typically have to do in managed languages that don't have that opt out.

Re: Program your next server in Go

#63

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 means having Rob Pike over your shoulder telling you how to write code. And he made sure you can't escape that fact since there is no place for "ninja coding" with Go.

Re: Program your next server in Go

#64
post #20
post #13

What are some cases where I would choose to write a server in Go instead of in Erlang?

When you want to hire developers.

The last place I worked, we built a system that included Erlang. When it was time to hire someone, we found a guy who was curious about Erlang, and although he didn't know it pat, he was a good hire, as he was a smart guy, hard worker, and curious not only about Erlang, but a lot of stuff.

That's the kind of person you want to hire anyway, unless you are super crunched for time in getting someone up to speed.

Re: Program your next server in Go

#65
post #9

Earlier quoted context omitted.

Visual Studio Code has a visual debugger that is close to being on-par with Chrome's JavaScript debugger, at least for me.

And it works with Go, resolving some or all of the issues mentioned?

I tried to get it to work the other day (with delve) for a few minutes and I could not. So even if it does it does not do so cleanly.

Re: Program your next server in Go

#66
post #61

Earlier quoted context omitted.

You would like to write an entire server without using a GC?

Presumably he is complaining about the GC implementation's characteristics, not its existence. You can read a description of the team's design decisions here: https://blog.golang.org/go15gc but a simple summary would be: memory is cheap and getting cheaper, so focus on making GC fast rather than small memory footprints.

Hasn't go been improving the GC with it's rounds of updates to the language?

Re: Program your next server in Go

#67

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…

What is "ninja coding"? Sounds stupid.

Re: Program your next server in Go

#68
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…

Bad programmers are always going to be bad programmers, no matter what their age. Bad programmers are inflexible and unadaptable; unable to keep up with new languages or idioms. Ken Thompson is about as old school as they come and he wrote much of Go.

Re: Program your next server in Go

#70
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…

I've been running into this phenomenon a lot and its not isolated to java developers. We recently had a class on Clojure 101 and the main audience was Obj-C/Swift developers. A lot of the developers went into the class actively trying to prove Clojure was dumb and the way they were doing it was better.

I think any language one it reaches a critical mass attracts people who are not problem solvers but memorizers. There is a correlation between people who rely on copy pasting existing code and SO answers and people heavily invested in their language.

Point being most people who have trouble adopting other languages tend to be memorizers vs problem solvers and become insecure when working in a poorly defined environment. Pulling them into something new after others have solved the hard problems and created best practices tends to be easier and more productive for everybody.

Post reply on HN