Here's a haskell comparison (hint: it does very well).
https://gist.github.com/jamwt/5017172
Haskell was ghc 7.6.1 with ghc --make -O2
Go is go1.0.2 with "go build".
Go as an alternative to Node.js for Very Fast Servers
91–100 of 147 posts
Re: Go as an alternative to Node.js for Very Fast Servers
#92Earlier quoted context omitted.
I've written a moderate amount of OCaml and some Go. While I agree that the former is a nice language, it doesn't compare favorably to Go as a development suite: the standard library is terribly designed, and the package management is rather poor compared to Go's (which is about as great as it gets). Now there is "OCaml Batteries Included" which is supposed to mitigate that, but it appeared after I stopped actively u…
OCaml should definitely move toward adopting either Batteries or Jane Street Core as its standard library; they offer a lot more functionality. For package management, I haven't had the chance to really try it yet, but I'm hearing good things about OPAM. Finally, Rust just looks awesome, I'm hoping that the language stabilizes before the end of the year, as I'd love to do my master thesis with it.
As great as OPAM might be (neither have I tried it), it has one fundamental downside compared to Go: it is a package manager for OCaml.
Package management is one of those things that are better off when there is just one.
Re: Go as an alternative to Node.js for Very Fast Servers
#93Earlier quoted context omitted.
Can I ask what language you are used to? I hear how nice go is as a language a lot, but coming from haskell, go is hideous in comparison.
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…
actually, the thing i find most lacking in go (although granted i've only done a few toy programs in the language) is sum types. it would make error handling a lot more pleasant, for one.
i'm excited about rust, which did go the algebraic datatype route.
Re: Go as an alternative to Node.js for Very Fast Servers
#94Here's a haskell comparison (hint: it does very well). https://gist.github.com/jamwt/5017172 Haskell was ghc 7.6.1 with ghc --make -O2 Go is go1.0.2 with "go build".
Warp is very nice.
Re: Go as an alternative to Node.js for Very Fast Servers
#95Earlier quoted context omitted.
OCaml should definitely move toward adopting either Batteries or Jane Street Core as its standard library; they offer a lot more functionality. For package management, I haven't had the chance to really try it yet, but I'm hearing good things about OPAM. Finally, Rust just looks awesome, I'm hoping that the language stabilizes before the end of the year, as I'd love to do my master thesis with it.
As great as OPAM might be (neither have I tried it), it has one fundamental downside compared to Go: it is a package manager for OCaml. Package management is one of those things that are better off when there is just one.
I'm pretty sure OPAM will become the de facto standard of the OCaml world; most people don't want to deal with the other ones.
Re: Go as an alternative to Node.js for Very Fast Servers
#96Earlier quoted context omitted.
So, is it possible to move/rename class/method/field smoothly using those tools? Extract code block to new method?
the gofmt tool has a replacement feature: `gofmt -r 'InitialName -> FinalName'`
Documentation looks quite incomplete(http://golang.org/cmd/gofmt/). Will it change all imports and usages of class/method/field? Will it resolve all signature polymorphic calls?
Re: Go as an alternative to Node.js for Very Fast Servers
#97I 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'.
I really love 'siege'. I wonder if you can get it show you response-time percentiles (or whatever they're called). I mean this (from `ab`):
Percentage of the requests served within a certain time (ms)
50% 161
66% 174
75% 182Re: Go as an alternative to Node.js for Very Fast Servers
#98I 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.
What configs do you change?
Re: Go as an alternative to Node.js for Very Fast Servers
#99I played around with a go server to do some simple scaling numbers - looking at possibly using go to implement a large-number-of-idle-connections notification server. I found the (good) result that I could spawn a new goroutine for each incoming connection with minimal (~4k) overhead. This is pretty much what you'd expect since a goro just needs a page for it's stack if it's doing no real work. I had something like 4…
> I think this is due to the go runtime allocating an OS thread for each goro as it goes through the socket close() blocking call. I think it has to do this to maintain concurrency I highly doubt that it is creating a thread per goro on client disconnect. If you have a minimalish example of this, the golang mailing list would be very interested in working with you to identify what went wrong and create a patch if it…
Blocking system calls spawn OS threads in Go, which can be cached and recycled for new goroutines. You don't see this if you code to pkg/net because it multiplexes i/o with a select/kqueue goroutine, but you'll see it right away if you code directly to the syscalls.
Close isn't a blocking call, though.
Re: Go as an alternative to Node.js for Very Fast Servers
#100Is there a socket.io equivalent for Go? In terms of ease of use and at least providing the same functionality.