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

231–240 of 384 posts

Re: Program your next server in Go

#231

Post by eropple »

chrismorgan wrote: post #229
eropple wrote: post #196

Earlier quoted context omitted.

To add to this: Go's inexpressivity (hi, generics!) makes common patterns that I see in Kotlin, Java, and Scala (as well as Rust, off-JVM) makes error handling a complete bear , to the point where my eyebrows are really raised at vertex-four being downvoted for this. The use of please-check-this error conditions instead of something like a Try (Result in Rust) and an inability to just map over these as 0- or 1-elemen…

Not using a Result is a warning, not an error: https://is.gd/U43rdG

Sorry, yes (I compile with warnings as errors), good catch.

Re: Program your next server in Go

#232

Post by antod »

robohamburger wrote: post #221
antod wrote: post #217

Earlier quoted context omitted.

> Also perl is apparently as fun for humans python which I also find suspect after maintaining perl 5.x code. When people talk about a language being 'fun', they need to distinguish between writing something new for the first time vs maintaining something or figuring out someone else's code.

Yeah I suppose at this point the graph falls apart since even the prospect of writing new perl code does not sound fun to me but I am sure could be fun to someone.

Yeah, I wouldn't want to be writing new Perl either. It was actually Ruby's "optimized for developer happiness" mantra that triggered my comment.

Sometimes I mumble under my breath that Ruby is Perl for the 21st century - gleefully creative hackers leaving behind overly clever code for far less happy developers to deal with.

A culture of optimising the elegance of the API over the simplicity and maintenance of the implementation.

Re: Program your next server in Go

#233

Post by readams »

Matthias247 wrote: post #170
readams wrote: post #83

Earlier quoted context omitted.

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 miss…

As long as your needs are sufficiently basic that you never need to create data structures then what's in Go can be ok. People who are fans of Go seem to be people who don't know what they're missing in more advanced languages. This seems to include C programmers and dynamic language programmers. Programmers used to better type systems are generally not happy with Go.

Re: Program your next server in Go

#234

Post by poorman »

server is a pretty loose term. Most servers* these days require some sort of full stack, with frontend, ORM, etc... Go adds a lot of development time if you need all of that. ...On the other hand, one off tiny microservices, it's absolutely great!

Re: Program your next server in Go

#235

Post by jaegerpicker »

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…

Maybe if you are taking Java the language in isolation but if you consider the JVM ecosystem than I'll absolutely say the JVM does concurrency better. While the JVM offers something like quasar (http://docs.paralleluniverse.co/quasar/) which can match go's goroutine and channels plus an actor interface or the really excellent Akka (http://akka.io/) for a non blocking async actor framework. Offering a lot more choice than golang's single concurrency pattern. I've written major applications with both go and Akka using Java (and scala) and while both were successful stable and performant it's hard to argue with the JVM's concurrency story.

Re: Program your next server in Go

#236

Post by brobinson »

enneff wrote: post #204
mappu wrote: post #181

Earlier quoted context omitted.

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

Channels are implemented using locks, but "4x slower" is a meaningless microbenchmark number.

You're welcome to benchmark it yourself. I got it from [1] which is a pretty recent comparison.

[1] http://www.jtolds.com/writing/2016/03/go-channels-are-bad-an...

Re: Program your next server in Go

#237

Post by netheril96 »

dboreham wrote: post #162
devsquid wrote: post #57

Earlier quoted context omitted.

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

Care to elaborate?

Re: Program your next server in Go

#240

Post by skj »

spriggan3 wrote: post #63
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 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…

> but AFAIK a lot of "Googlers" don't really like it and don't use it

Where on earth did you hear that? It's simply not true.

(googler)

Post reply on HN