Live data from Hacker News

Program your next server in Go

talks.golang.org

161–170 of 384 posts

Re: Program your next server in Go

#161
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,…

> 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 perspective, Go is mostly a subset of Java. The features Go adds are mostly related to concurrency, and I've not heard anyone say Java does concurrency better than Go.

Re: Program your next server in Go

#162

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?

I would not like to write a server with GC.

Source: I've written many servers in both C and Java and given the choice will never use a GC language again for a server. Holding out some hope for Rust..

Re: Program your next server in Go

#163
post #102

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

Re: Program your next server in Go

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

I switched to Glide, a vendor-focused package manager, on 1.5. I think the community has already decided in favor of this approach. Post 1.5, Godeps' workflow just feels weird and unnecessary.

Re: Program your next server in Go

#165
post #146
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…

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.

Re: Program your next server in Go

#166

Earlier quoted context omitted.

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.

I think dismissing anything invented after 1960/not invented at Google counts as "inflexible and unadaptable; unable to keep up with new languages or idioms".

Many folks come to Go from "modern" languages, Python and Java in particular. I don't think this can be considered "dismissing".

Re: Program your next server in Go

#167
post #34
post #13

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

As an Erlang fan, my guess is that Go is a bit faster for many things, whereas Erlang's concurrency, fault tolerance, and distributed stories are "better". Not everyone needs all those though. Go is probably a bit more 'generic' - you can do anything with it. Erlang has always felt like it's a tool designed to do a few things really, really well.

I've not used Erlang, but I've also heard comparisons that prefer Go to Erlang for its familiar syntax and comprehensive standard library. Obviously I can't vouch for these claims.

Re: Program your next server in Go

#168

Earlier quoted context omitted.

Also to add on this... All of my lambda functions are a thin Node wrapper on top of Go applications. The go application is simply a command line accepting JSON via stdin (from the Node wrapper). It is a Joy to test, you can run it locally/independently etc... [Edit]: Typos fix

Do you use a library or toolkit for this? Or is there an example of this that you can point me to? This sounds useful with or without Go

https://apex.sh is nice

Re: Program your next server in Go

#169
post #34
post #13

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

As an Erlang fan, my guess is that Go is a bit faster for many things, whereas Erlang's concurrency, fault tolerance, and distributed stories are "better". Not everyone needs all those though. Go is probably a bit more 'generic' - you can do anything with it. Erlang has always felt like it's a tool designed to do a few things really, really well.

[deleted]

Re: Program your next server in Go

#170
post #83
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…

This is because using Go feels very much like going back in time to Java 4.

Not necessarily. I think by providing native slice and map types Go reduces the need for generics already by a large margin. Other things that often use generics (higher order functions, future types, ...) are no idiomatic Go which leans more to the imperative way of doing things. In total I have not really missed generics in Go up to now (but I have up to now only written about 20kloc in it) - while I certainly missed them in early Java and C# versions.
Post reply on HN