Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go as an alternative to Node.js for Very Fast Servers

techblog.safaribooksonline.com

Post reply on HN
Print view View original

41–50 of 147 posts

Re: Go as an alternative to Node.js for Very Fast Servers

#41

Post by chimeracoder »

papsosouid wrote: post #36
chimeracoder wrote: post #32

Earlier quoted context omitted.

Go is going to look hideous to you because you're probably expecting functional things like list comprehensions (which Go doesn't have) and a very intricate type system allowing for things like generics (which Go doesn't have either). Go code will look a little less DRY to you as a result, which is a fair criticism, but it makes up for that by being incredibly opinionated (that's a good thing), being incredibly easy…

>Go is going to look hideous to you because you're probably expecting functional things like list comprehensions Nah, list comprehensions are just syntactic sugar and not used much in haskell. Python seems to encourage their use a lot, but you hardly even see them in haskell code. >a very intricate type system allowing for things like generics (which Go doesn't have either). That is definitely one of the big problems…

> Parametric polymorphism is very simple, and has been a completely solved issue for a very long time. There is simply no excuse for a brand new language to be decades behind on something so easy to do right.

Go has addressed this; their approach is Go's interfaces, which combines the best of all worlds: duck typing with static type checks and type inference.

> Go is harder to prototype in, and it is easy to add bugs when refactoring because the type system is so poor.

This is where we'll have to agree to disagree. It's definitely not harder to prototype in - and I say this as a functional programmer - and if you find the type system to be inadequate when refactoring, it sounds to me like you're trying to write idiomatic Haskell in Go. Go's type system, by design, stays out of the way - if you're writing Go idiomatically, you really shouldn't be thinking very much about the types as you write them.

As for generics, this gets beaten to death on every single Go post on HackerNews. Yes, Go would ideally have generics. Yes, there are tradeoffs involved. Yes, those tradeoffs have been explained by the Go developers at length. Yes, they would be open to including them in the future, if somebody addressed the existing concerns. No, nobody seems to mind that they're missing from the language as-is, given those tradeoffs.

Re: Go as an alternative to Node.js for Very Fast Servers

#42

Post by btown »

> The biggest promise that Node makes is the ability to handle many many concurrent requests. How it does so relies entirely on a community contract: every action must be non-blocking. All code must use callbacks for any I/O handling, and one stinker can make the whole thing fall apart. Try as I might, I just can’t view a best practice as a feature.

Nonblocking I/O isn't just a "best practice" in the sense that consistent indentation is a "best practice," it's a core tenet of the Node ecosystem. Sure, you could write a Haskell library by putting everything in mutable-state monad blocks, and porting over your procedural code line-for-line. It's allowed by the language, just like blocking is allowed by Node. But the whole point of Haskell is to optimize the function-composition use case.

The Node community has the benefit of designing all its libraries from scratch with this tenet in mind, so in practice you never/rarely need to look for "stinkers" unless they're documented to be blocking. And unless they're using badly-written blocking native code, you can just grep for `Sync` to see any blocking calls.

Re: Go as an alternative to Node.js for Very Fast Servers

#43

Post by kibwen »

mattgreenrocks wrote: post #19
evmar wrote: post #14

Earlier quoted context omitted.

It seems so. https://code.google.com/p/go/issues/detail?id=4056 An interesting point raised there is that if they instead used a limited thread pool for all goroutines to share when making OS calls you could produce deadlocks.

I'm curious what calls could induce deadlock. I figured everything used a nonblocking API internally and the runtime conferred blocking semantics.

I'm groping blindly here, but from the references in that message to cgo I think it might have to do with calling into foreign code. Presumably Go's scheduler can't yield when you're inside C code (I'm not aware of any lightweight thread system that can achieve this) so you have to block there, which means you can no longer schedule other goroutines on that thread, and thus you have to spawn a new thread if you want to get any work done. But I'm just guessing here.

Re: Go as an alternative to Node.js for Very Fast Servers

#44

Post by Flow »

mseepgood wrote: post #25
jacobmarble wrote: post #2

Node: Everyone knows JavaScript, there's a massive community, there are tons of libraries, and you get very good performance Go: No one knows this language, there's a small-but-growing community, there are enough libraries to get a lot done, and you get even better performance Java: They are paying me (money!) to write in this language

The Go community on Reddit is already bigger than the Node community: http://www.reddit.com/r/golang (3730) http://www.reddit.com/r/node (3581)

And the Google+ Go community is growing fast and is already larger than the sub-reddit. https://plus.google.com/communities/114112804251407510571

Re: Go as an alternative to Node.js for Very Fast Servers

#45

Post by papsosouid »

chimeracoder wrote: post #41
papsosouid wrote: post #36

Earlier quoted context omitted.

>Go is going to look hideous to you because you're probably expecting functional things like list comprehensions Nah, list comprehensions are just syntactic sugar and not used much in haskell. Python seems to encourage their use a lot, but you hardly even see them in haskell code. >a very intricate type system allowing for things like generics (which Go doesn't have either). That is definitely one of the big problems…

> Parametric polymorphism is very simple, and has been a completely solved issue for a very long time. There is simply no excuse for a brand new language to be decades behind on something so easy to do right. Go has addressed this; their approach is Go's interfaces, which combines the best of all worlds: duck typing with static type checks and type inference. > Go is harder to prototype in, and it is easy to add bugs…

You are contradicting yourself about parametric polymorphism. First you acknowledge it doesn't exist, then you claim a limited workaround solves it.

>It's definitely not harder to prototype in - and I say this as a functional programmer

Have you used haskell to make the comparison?

>if you're writing Go idiomatically, you really shouldn't be thinking very much about the types as you write them.

I don't understand where you are coming from here. I am not thinking about types, that is why I need the compiler to point out when I mess them up. The problem is go has such a limited type system, that you have to change much more code when you refactor, and the type system is inadequate for catching many errors, in particular dealing with error handling. The combination makes go worse for refactoring than haskell. It is certainly much better than python for example, but you seem to be convinced that go is the top of the spectrum and nothing can exist above it.

Re: Go as an alternative to Node.js for Very Fast Servers

#46

Post by oinksoft »

mjijackson wrote: post #39

I was curious, so I actually ran both of the servers from the article on my little MacBook Air. The results are below. First, go: $ ab -c 100 -n 10000 http://localhost:8000/ This is ApacheBench, Version 2.3 Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient) Completed 1000 requests Completed 200…

I'd be interested to see your numbers benchmarking with `siege' rather than `ab'.

Re: Go as an alternative to Node.js for Very Fast Servers

#47

Post by fizx »

mjijackson wrote: post #39

I was curious, so I actually ran both of the servers from the article on my little MacBook Air. The results are below. First, go: $ ab -c 100 -n 10000 http://localhost:8000/ This is ApacheBench, Version 2.3 Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient) Completed 1000 requests Completed 200…

Benchmarking on macbooks is often an exercise in testing the mediocre default configuration of the network stack, not your language. My macbook pro gets 4k rps with apache, node, go, and nginx. YMMV and all that, but I'm always wary.

Re: Go as an alternative to Node.js for Very Fast Servers

#48

Post by emidln »

chimeracoder wrote: post #41
papsosouid wrote: post #36

Earlier quoted context omitted.

>Go is going to look hideous to you because you're probably expecting functional things like list comprehensions Nah, list comprehensions are just syntactic sugar and not used much in haskell. Python seems to encourage their use a lot, but you hardly even see them in haskell code. >a very intricate type system allowing for things like generics (which Go doesn't have either). That is definitely one of the big problems…

> Parametric polymorphism is very simple, and has been a completely solved issue for a very long time. There is simply no excuse for a brand new language to be decades behind on something so easy to do right. Go has addressed this; their approach is Go's interfaces, which combines the best of all worlds: duck typing with static type checks and type inference. > Go is harder to prototype in, and it is easy to add bugs…

> Go's type system, by design, stays out of the way - if you're writing Go idiomatically, you really shouldn't be thinking very much about the types as you write them.

I'd wager that if you aren't thinking about what your inputs and outputs are going to be at every step, you're introducing bugs or working harder than you have to. A strong static type system like you find in Haskell formalizes that so that it's required, but even in the languages I write most often (Python and C, which get bashed constantly for their type systems), this is just what writing solid code is about.

In Python, I may not be thinking exactly "what is the type of this thing, foo", but I am asking myself "okay, I'm trying to iterate this thing, is it actually iterable? How do I handle when it isn't? or guarantee it to always be an iterable ?".

Re: Go as an alternative to Node.js for Very Fast Servers

#49

Post by dman »

papsosouid wrote: post #45
chimeracoder wrote: post #41

Earlier quoted context omitted.

> Parametric polymorphism is very simple, and has been a completely solved issue for a very long time. There is simply no excuse for a brand new language to be decades behind on something so easy to do right. Go has addressed this; their approach is Go's interfaces, which combines the best of all worlds: duck typing with static type checks and type inference. > Go is harder to prototype in, and it is easy to add bugs…

You are contradicting yourself about parametric polymorphism. First you acknowledge it doesn't exist, then you claim a limited workaround solves it. >It's definitely not harder to prototype in - and I say this as a functional programmer Have you used haskell to make the comparison? >if you're writing Go idiomatically, you really shouldn't be thinking very much about the types as you write them. I don't understand whe…

I have been wanting to learn Haskell for some time. Is Real World Haskell still the best book for the language? Could you point me to some well written libraries/projects that are considered idiomatic haskell? Would appreciate the pointers.

Re: Go as an alternative to Node.js for Very Fast Servers

#50

Post by VeejayRampay »

jgrahamc wrote: post #5

While JavaScript drags the scars of its hasty standardization around with it, Go was designed very thoughtfully from the beginning, and as a result I find that it’s a pleasure to write. This is very true. Go is a pleasure to write. In fact, it's such a pleasure then when you hit something that wasn't really well designed it's horrid.

I've done Java, PHP, Objective Caml (in college for a few years), some basic C, Ruby and Javascript before and I concur. Go is a real breath of fresh air. I have the same feeling I have when I code with Ruby: that sense that the language works WITH me, that the whole experience is smooth and seamless.

I wish Go stays on that path for a long time. And it never gets TOO big, which makes for awful communities.

Post reply on HN