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

81–90 of 384 posts

Re: Program your next server in Go

#81

Post by ridiculous_fish »

squiguy7 wrote: post #18

> Clarity is critical. When you need to write high performance code this is a great maxim. I enjoy the simplicity of Go and the guarantees it provides. Being able to reason about code and not having to guess is a win for any development team.

IME, clarity and reasoning are weak points of Go, relative to other systems programming languages (but perhaps not to dynamic languages):

1. Slices make it hard to reason about aliasing. bar = append(foo, val): does bar now alias foo? The answer is the worst possible: "sometimes."

2. Closure semantics make it hard to reason about thread safety. I converted this serial loop to parallel using goroutines; did I introduce a race condition? I have to look at each variable to decide. (Any sort of const capturing would go a long way here).

3. Goroutine leaks can be hard to reason about. For example, a channel that is not sufficiently buffered can result in a leak.

4. Nullable maps and channels reduce clarity.

5. The "redeclare" semantics means := sometimes does not introduce a new variable

Re: Program your next server in Go

#82

Post by iagooar »

One important niche I see that Go serves very well is in distributed, fault-tolerant deploy platforms (aka schedulers), like Kubernetes or Mesos. If you look at the amount of tooling that uses Go, you almost feel there just is no other choice out there.

I would not adventure to say state-of-the-art schedulers would not have been possible without Go, but for sure Go fits the requirements pretty well.

Re: Program your next server in Go

#83

Post by readams »

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…

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

Re: Program your next server in Go

#84

Post by erikpukinskis »

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. Personally, I'd rather APIs mostly stick to simple functions, and let the application developer build idioms around them if they like. And if the API call involves a web request, I am happy to just make the HTTP call myself. Half the time you need to understand the interchange format to debug your code anyway. My experience is that wrappers rarely protect you from that.

I guess if your application is 90% calls to an API, and you use a huge range of different functions in that API then you'd want a good, complete library. But how common is that?

Re: Program your next server in Go

#85

Post by haberman »

devsquid wrote: post #57
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…

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

People do it all the time. For example, in C++ with modern owning pointers like std::unique_ptr and std::shared_ptr it's really not that bad.

Re: Program your next server in Go

#87

Post by im_down_w_otp »

freyr wrote: post #20
PeCaN wrote: 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.

Never had a problem finding or training great Erlang engineers, and even had a few cases where the absolute best of the candidates were only interested because they'd get to use Erlang.

(shrug).

Re: Program your next server in Go

#88

Post by matthewmacleod »

Go has been great for me at providing things like simple microservices, network plumbing, CLI tools and that kind of thing. The C integration is also super simple and makes it easy to wrap up third-party libraries.

It's also a bit tedious to write in practice. It's dogmatic, and that's obviously a benefit in some ways but comes with the cost that quite a lot of time in my experience is wasted fiddling around with program structure to beat it into the way Go wants it to work. Dependency management is better with Glide but still not perfect. The type system is quite annoying, and although it's a cliche the lack of generics is quite annoying. Lots of silly casting to and from interface{} or copy-and-pasting code gets old quickly.

Still, it's a great tool for its niches and I really think everyone should pick it up and use it - the idea of simplicity it promotes is actually kind of interesting, in contrast to the "showy" features one might expect of a modern language.

Re: Program your next server in Go

#90

Post by Chris2048 »

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…

Consider there may be an existential bias - people who are open to new languages are more likely to move away from Java.
Post reply on HN