8 ms·

Go as an alternative to Node.js for very fast servers

176 points by g0lden 13y ago

crncosta 13y ago
Here is the original link: http://blog.safariflow.com/2013/02/22/go-as-an-alternative-to-node-js-for-very-fast-servers/ http://blog.safariflow.com/2013/02/22/go-as-an-alternative-t...
616c 13y ago
So beyond the ironic comment mentioned before with the Golang Hello world tutorial using Chinese, what is the real reason behind the Chinese following behind Go? It seems like this site confirm there must be a pretty dedicated Golang following, but I cannot figure out for the life of me why. Does anyone actually know?
- samnardoni 13y ago
  For me, Go has the least "What the hell does this code do?" and "Why isn't this code working?" of any language I've ever used. I'd say Go isn't an impressive programming language, but a very impressive software engineering language.
  - bsg75 13y ago
    > Go isn't an impressive programming language, but a very impressive software engineering language. Curious, what is the distinction?
    - icedchai 13y ago
      IMO, simplicity, no surprises, doing stuff in a way that "makes sense" without a lot of boilerplate or cruft.
    - coldtea 13y ago
      He means that Go will not impress programming language geeks and academic PL researchers with cool evolved syntax or cutting edge features, but is a fine language for actually building software. In the same sense that a language that "in theory" has tons of cool stuff might be unusuable in practice (due to complexity, opaqueness, lack of libs, strange syntax etc).
- siddhant 13y ago
  Not necessarily. I suppose the hello world tutorial shows hello world in Chinese mostly to show Unicode. And as for this link, this is just an external link (http://blog.safariflow.com/2013/02/22/go-as-an-alternative-to-node-js-for-very-fast-servers/ http://blog.safariflow.com/2013/02/22/go-as-an-alternative-t...) that someone posted on a forum. Things like these happen on every forum in every country.
  - 616c 13y ago
    Yeah, not sure what happened but this was the link below a few minutes ago. http://bbs.studygolang.com/thread-278-1-1.html http://bbs.studygolang.com/thread-278-1-1.html Notice that, despite English content, the forum looks Chinese-language oriented. I think it is cool, but not normal to me.
- justincormack 13y ago
  There was some discussion here but no OK me seems to know more https://news.ycombinator.com/item?id=6161399 https://news.ycombinator.com/item?id=6161399
  - freyr 13y ago
    Your original comment: > They seem to be making a concerted effort to make Go Chinese friendly https://code.google.com/p/go-zh/ https://code.google.com/p/go-zh/ The Chinese fork seems to be a project started by Minux. Minux (Shenghou Ma) is a Go contributer and is very active in the Go community, but he does not work for Google, as far as I know.
    - 616c 13y ago
      Interesting. Unfortunately I did not make it past year one Chinese in university, so I do not remember enough. If I had known, I would go find out if he contributes a lot on the Study Golang BBS.
- corresation 13y ago
  Do you mean specifically why there is a dedicated Chinese following in particular, or just in general? Go is a clean, intuitive language with a very robust supporting ecosystem and a strong concurrency model. It builds fast, small code and makes quick work of big problems. Why shouldn't there be a big following of one of the better platforms to come out in a long time?
  - agentultra 13y ago
    My only gripe is its intended use as a systems programming language. The runtime kind of makes it a silo; ie: hard to bind other languages to it through an FFI. Of course if I am mistaken or there's something being done to address such a scenario then I will be much happier seeing more and more infrastructure code shipping in Go.
    - mratzloff 13y ago
      Go has the same FFI language that most languages do: C. http://golang.org/cmd/cgo/ http://golang.org/cmd/cgo/
      - masklinn 13y ago
        Wrong way around. By "bind languages to it" agentultra talks about using Go from other languages, not using C from Go.
    - corresation 13y ago
      >hard to bind other languages to it through an FFI. Go has absurdly simple FFI through, as mratzloff mentioned, C. This is self-promotion and apologies, but see my submission history for two examples.
    - masklinn 13y ago
      > My only gripe is its intended use as a systems programming language. It's not. It's a new Java, not a new C++. > ie: hard to bind other languages to it through an FFI. More or less impossible: GC and goroutines are not optional so you'd need to cleanly setup and shutdown the Go runtime. You'd have to embed Go as you do Lua or Python.
- fredsanford 13y ago
  Maybe because a lot of choice has been removed from the system? I've worked with a bunch of people from different countries and find that the more strict the gov't, the less they like choice, in general. All anecdotal of course... Giving one guy from the Ukraine the typical choices at a restaurant here in the US would freeze him in place. What would you like to drink? Tea Sweetened or Unsweetened? Sweet. frustration += 1 Sugar or artificial sweetener. Sugar. frustration += 2 Soup or Salad? Soup. frustration += 7 Which soup? Minestrone, Pasta Fagioli, Italian Wedding? frustration += 14 and on and on... Ukraine started packing his lunch. Then there was the guy from Iceland... He took 10+ minutes to decide what to order in a new place and once he figured out what he liked in a particular place, he never gave the waitstaff a chance to offer him a choice. This, well done, salad with x dressing, with unsweetened tea. Iceland liked making the choices but only a few times. Some people like to be dictated to: Code will be formatted like this. Braces will be like this. etc. The author of the article thinks these are a feature while I find it obnoxious. My brain requires braces to line up in the left column, anything else slows me down. Maybe I'm just old?
  - mr_luc 13y ago
    Off-topic on the subject of restaurants: I use the ML approach of combining other people's algorithms. :) My first time in a new place, I'm usually with friends, and I imitate their orders. On the rare times when I'm not, I ask the waiter what the favorite plates of he/the other people in the restaurant are, what they order when they eat there. This way even my initial orders are lightning-fast and already judged as 'tasty' in comparison to other offerings. And over time, I can investigate other plates for myself.
  - asabjorn 13y ago
    It does not make sense to group peoples reaction to choice like this. As a counter example Apple products are very popular in the USA and other Western Countries, and Apple does not give you many choices.
    - fredsanford 13y ago
      I used a lot of weasel words in my comment to avoid follow up comments like this. Maybe, anecdotal etc... It was simply something I noticed from lots of years working with lots of people from lots of different countries. No offense was intended.
- Jhsto 13y ago
  If you meant the Hello World example, it is probably because the board game Go originates from China: http://en.wikipedia.org/wiki/Go_(game) http://en.wikipedia.org/wiki/Go_(game)
  - prewett 13y ago
    I doubt it. If I recall the example correctly, it was "Hello, 世界!" Since "世界" means "world" the example is really the same "Hello, world!" example from C, only with one of the words changed to something that clearly requires Unicode. That was certainly my reaction when I saw the example: "oh, good, easy Unicode support" I expect the choice of Chinese as the language is probably the fact that you can't play code page games very easily with Chinese, which you could with Korean, Arabic, etc. It is probably the most widely spoken language with a non-Latin character set. Also, chances are very good that a Chinese-writing colleague of the example writer was readily available. Although, who knows, it would be fun if it were because of the board game.
munimkazia 13y ago
If you read the original blog post on http://blog.safariflow.com/2013/02/22/go-as-an-alternative-to-node-js-for-very-fast-servers/ http://blog.safariflow.com/2013/02/22/go-as-an-alternative-t..., one of the commentators actually attempted the comparison between node.js and go, and his results for node.js was significantly faster.
- axaxs 13y ago
  Go version 1.1 was more than a significant increase in net handling speed.
  - bhauer 13y ago
    Not only that, but although the particular test described in the linked blog post did not include database connectivity, we saw a massive increase in database performance in 1.1 versus 1.0.2 due to a fix in the sql package [1]. That was back in Round 4 of our project [2]. Just something to be aware of if anyone reading has Go 1.0.2 installed and has not yet upgraded. 1.1 is worth the upgrade. [1] https://code.google.com/p/go/source/detail?r=45c12efb46 https://code.google.com/p/go/source/detail?r=45c12efb46 [2] http://www.techempower.com/blog/2013/05/02/frameworks-round-4/ http://www.techempower.com/blog/2013/05/02/frameworks-round-...
- bhauer 13y ago
  Thanks for the link to the original. Perhaps "February 22, 2013" should be identified in the title here? That explains the use of Go 1.0.2.
MatthewPhillips 13y ago
Is it possible to write Go in a functional way? Are there first class functions? Anonymous functions? If so it seems it would be possible to write highly functional code given the flexibility of interface{}
- deleted 13y ago
  [deleted]
- lmm 13y ago
  Up to a point, but go's limited datatypes make it difficult to write the kind of code you're used to writing in haskell/f#/etc.
  - payload 13y ago
    A haskell version with the Warp server performs just a little bit worse than the go version (6 secs vs 7 secs) with a little bigger minimal latency (68 ms vs 71 ms). go version go1.0.2 runghc 7.6.2 cabal packages of today Runned with "runhaskell main.hs" on localhost over loopback :) import qualified Network.Wai as Wai import qualified Network.Wai.Handler.Warp as Warp import qualified Network.HTTP.Types as HTTP import qualified Data.ByteString as ByteString import Blaze.ByteString.Builder.ByteString (fromByteString) main = do let port = 8000 Warp.run port app app req = do let n = 1024*1024 let bytes = fromByteString $ ByteString.replicate n 100 return $ Wai.ResponseBuilder HTTP.status200 [] bytes
    - cgag 13y ago
      Am I right in thinking that Haskell servers will likely be winning on these benchmarks after Mio is released in 7.8.1? https://news.ycombinator.com/item?id=6198068 https://news.ycombinator.com/item?id=6198068
      - Peaker 13y ago
        Since Warp seems to use many light-weight(green) threads behind the scenes, and Mio is mainly about improving multithreaded performance on actual multi-core set ups, the answer seems to be yes. However, it would probably only help if you use -threaded (which you should, anyways).
AndyKelley 13y ago
I did the benchmarks outlined at the end of the article. Summary of results: 1. Node.js v0.10.15, single worker: 46.2 seconds 2. Node.js v0.10.15, cluster 8 workers using naught: 17.2 seconds 3. Go 1.0.2, GOMAXPROCS left default: 3.5 seconds 4. Go 1.0.2, GOMAXPROCS=8: 3.7 seconds Detailed results below: 1. Node.js v0.10.15, single worker Concurrency Level: 100 Time taken for tests: 46.217 seconds Complete requests: 10000 Failed requests: 0 Write errors: 0 Total transferred: 10486510000 bytes HTML transferred: 10485760000 bytes Requests per second: 216.37 [#/sec] (mean) Time per request: 462.168 [ms] (mean) Time per request: 4.622 [ms] (mean, across all concurrent requests) Transfer rate: 221580.08 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.2 0 3 Processing: 193 461 36.2 450 944 Waiting: 16 235 127.3 235 534 Total: 193 461 36.2 450 944 Percentage of the requests served within a certain time (ms) 50% 450 66% 467 75% 470 80% 486 90% 492 95% 514 98% 517 99% 545 100% 944 (longest request) 2. Node.js v0.10.15, cluster 8 workers using naught Concurrency Level: 100 Time taken for tests: 17.199 seconds Complete requests: 10000 Failed requests: 0 Write errors: 0 Total transferred: 10486510000 bytes HTML transferred: 10485760000 bytes Requests per second: 581.41 [#/sec] (mean) Time per request: 171.995 [ms] (mean) Time per request: 1.720 [ms] (mean, across all concurrent requests) Transfer rate: 595408.80 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.2 0 3 Processing: 7 171 116.4 149 739 Waiting: 5 96 81.9 71 710 Total: 8 171 116.5 150 740 Percentage of the requests served within a certain time (ms) 50% 150 66% 197 75% 236 80% 266 90% 324 95% 397 98% 438 99% 493 100% 740 (longest request) 3. Go 1.0.2, GOMAXPROCS left default Concurrency Level: 100 Time taken for tests: 3.542 seconds Complete requests: 10000 Failed requests: 0 Write errors: 0 Total transferred: 10486730000 bytes HTML transferred: 10485760000 bytes Requests per second: 2823.16 [#/sec] (mean) Time per request: 35.421 [ms] (mean) Time per request: 0.354 [ms] (mean, across all concurrent requests) Transfer rate: 2891181.71 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 1 0.3 1 3 Processing: 9 35 2.2 34 56 Waiting: 0 1 1.3 1 22 Total: 12 35 2.3 35 57 Percentage of the requests served within a certain time (ms) 50% 35 66% 36 75% 36 80% 36 90% 37 95% 38 98% 39 99% 41 100% 57 (longest request) 4. Go 1.0.2, GOMAXPROCS=8 Concurrency Level: 100 Time taken for tests: 3.657 seconds Complete requests: 10000 Failed requests: 0 Write errors: 0 Total transferred: 10486730000 bytes HTML transferred: 10485760000 bytes Requests per second: 2734.54 [#/sec] (mean) Time per request: 36.569 [ms] (mean) Time per request: 0.366 [ms] (mean, across all concurrent requests) Transfer rate: 2800429.67 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 1 0.4 1 3 Processing: 19 36 2.5 35 57 Waiting: 0 1 1.1 1 16 Total: 20 37 2.5 36 58 Percentage of the requests served within a certain time (ms) 50% 36 66% 37 75% 37 80% 37 90% 38 95% 39 98% 42 99% 51 100% 58 (longest request)
deleted 13y ago
[deleted]
rartichoke 13y ago
That test is rigged to be a best case scenario for Go. How often do you send 1MB responses down to the client? If you send 3KB responses then you would see both setups are much closer in performance. Factor in some actual I/O and the difference will be even less. Then you'll eventually realize using either one makes little difference when it comes to performance. This is why micro benchmarks are pure jokes. A real world site has a mix of response sizes, database I/O and caching. It's the only way to test something properly and you'll see if you properly test both there will be little difference in performance.
- redneckbeard 13y ago
  Original author of the post in question here. Please note that the microbench was "rigged" by the author of Node when he was first presenting it several years ago (spelled out in the article). If you need a tl;dr, it's this: I don't care for JavaScript as a language. Many make the argument that JavaScript should be adopted widely server-side because of its speed. I assert that languages should be evaluated not only for performance but for maintainability, feature sets, standard library, etc. Go provides a great combination of execution speed, development speed, and ease of maintainability.
  - rartichoke 13y ago
    The development speed isn't very good with Go because you have to re-invent almost everything yourself because the web libs are seriously years behind other platforms. The default template language is also really archaic and no one has created a solid alternative yet that's actually well tested and used by the masses. It might have good execution speed and the language itself might be nice but the only thing that matters is going from point A to point B. Go will not get you there faster than other languages and the execution speed is a non-issue for pretty much every platform (even rails) if you use tools available to you to their fullest. P.S., I compared Go to Node almost a year ago and even wrote a mini framework for Go to resemble a smaller version of Express. I eventually just said fk it and stopped because the gains were not even close to being worth it.
    - 13y ago
swah 13y ago
Go doesn't mean just fast for me; in that space there is also the JVM. To me, it fits the fast and lean and easy to deploy space.
- tensor 13y ago
  The headline of this article bothered me in this regard. Node.js is decidedly middle of the pack in terms of performance: http://www.techempower.com/benchmarks/ http://www.techempower.com/benchmarks/ In addition to various JVM technologies, there are faster technologies in C++, PHP, and Lua.
  - pekk 13y ago
    I think you will find that in many actual applications PHP is not faster than Node. Further, once you apply a framework to paper over some language warts, performance is often terrible and can only be rescued by extremely liberal caching. If this were not so, it would be hard to see the motivation for HipHop.
    - tensor 13y ago
      Might the motivation simply be to get closer to C++ performance? I really don't value this type of response where the benchmark is brought into question, yet nothing is substituted as evidence. In the few cases were someone does claim that they rewrote a sufficiently complex system in Node from some other language, it's impossible to discount that the performance changes come from architectural choices rather than language choices. Playing devils advocate, I've heard the same claim you put forth here about Node.js: it gets much slower in real apps because you have more slow JS code being run vs the very fast C libraries that back the core of Node.js. To me, benchmarks like the one I posted above are the most compelling form of evidence we have. What I take from it is that a great many "boring" languages and frameworks are really very fast. It's not the answer that most people want to hear of course; it goes against the current popular hype.
- cgag 13y ago
  What's easier about deploying Go vs with the JVM? Deploying stuff I've written in Clojure has been pretty easy.
markuskobler 13y ago
Are these trivial micro benchmarks, (simply respond with an empty 200) not totally misleading to focus on? Especially when you start to factor in many real workloads that involve disk or network io.
- ilaksh 13y ago
  Its not empty because its 1mb but it is misleading because in the original article someone's comment showed Node going much faster than Go. If it were empty then Node would be faster because you can get 4000 req per sec if its empty. I think something weird is going on though because it should be more than 300 per sec with the new Node version even if its 1mb.
Morphling 13y ago
I know this post is about speed, but you should always remember that with node.js you only need JS developers while with Go you are probably going to need both Go and JS (for front-end stuff) developers. Just my two cents.
- cenhyperion 13y ago
  Or developers that are comfortable with both JS and Go.
- gtaylor 13y ago
  At the same token, having frontend JS devs that don't have much experience in writing backends can leave you with a mess to clean up or completely re-write in the future. I think this "benefit" of using the same language for front and backend is pretty over-hyped, as well. In theory, I can agree that it sounds good. In practice, use the best tool for the job on both ends to fit your team's abilities and strengths. The other neat thing is that if your frontend and UI are cleanly separated, you can swap them out individually without the other even noticing. If our backend gets to be too sluggish, I can replace it with something lower level gradually over time (Go?) without leaving a bunch of deprecated backend JS cruft to clean out.
  - purplelobster 13y ago
    As a single developer on a project, I use js on the front-end, NodeJS and CouchDB (views written in js). This means that every step of the way is js, json and http, which is extremely liberating for me, as someone who's just starting out with web development.
  - ef4 13y ago
    I have a rich, client-side, fully-offline-capable javascript application. I started out with a different language for the backend, but over time the benefit of switching to Node and sharing one codebase became overwhelming. Just to give one example: any data query can get answered locally or from the server, depending on what's already cached and whether you're online. Before, I had to implement every call twice and make sure they stayed in sync. Now I can implement once and run the same code in both places. And other interesting possibilities open up. The server can just run the client's data synchronization code to pull changes from another server, giving realtime server-to-server replication nearly "for free".
invisible 13y ago
I've worked with both node and Go. There is a lot of hyperbole and fluff points about Go's strengths in the original article (sorry to the author!). Things that are touted as huge wins for Go have equally better things in node. Both platforms are great and they both have appeal for different people. My eloquent post was eaten by an expired link on the original article but here are some counter-points: The commutative property applies to all code that has semicolons to end lines. Use jslint/jshint/an IDE. The symbol is "optional" not marked as "leave it out because it makes scripts nicer." Use jslint/jshint/an IDE to prevent globals. Seriously. It's the same as running go fmt on your code. Forcing people to use "channels" as a best practice to accomplish scaling is the same as the best practice of callbacks - but yes, channels are nicer to use. Node standard modules require callbacks by default as Go standard library implements channels by default. 32-bit integers in JS don't have float problems because the precision doesn't break Typing in Go can still be annoying for some situations. If you're dealing with external content (creating an API with mutable content that you still need to read) it can be annoying at best (e.g. reminds me of writing C). Types in Go are a nice implementation though. npm is way better than go get and there are at least 3 projects in Go trying to replicate npm's ease-of-use The vim/emacs syntax highlighter is nice but it's awfully frustrating if you don't use vim/emacs. This is due to Go's young age, but you shouldn't be forced into using a certain editor to get syntax highlighting. The alternative to "go fmt" for Javascript is a good IDE or jslint/jshint. In Go, you get a lot in the standard library, but you miss out on a lot in the community. Yet another young language problem, you wind up having to roll your own for a lot of things that should just exist. It can be frustrating looking for answers because you might be the first person working on the problem in the language. Also, just as a general thing I've perceived, people seem to argue static types vs dynamic types more than that a particular language is "better." Go and JS/node are both great!!!! Go is typed, JS is not and you deal with the consequences in both situations. Static typed languages have big faults with external data handling that sometimes cripple features (or makes them far more difficult to accomplish). Dynamic typed languages can fall victim to variables being used incorrectly (especially when not using an IDE). That's the biggest bulk of the difference in my experience.
- drsintoma 13y ago
  > Typing in Go can still be annoying for some situations. If you're dealing with external content (creating an API with mutable content that you still need to read) it can be annoying at best (e.g. reminds me of writing C). Types in Go are a nice implementation though. Indeed, that's probably the biggest flaw I've found working with GO's type system. Trying to work with unknown n-level JSON is real pain.
lloeki 13y ago
Also, Go as an alternative to <whatever> for very slow servers. I use Go on my Pi and the thing flies.
sandGorgon 13y ago
Did you compare with a JVM toolkit with similar concurrency libraries like Akka/Scala? Am curious to find out the results. There was a recent, don't remember which, comparison that put Scala way ahead of Go possibly because of a superior GC. Wonder if the results correlate
jambay 13y ago
I think there is a typo in the go sample program. bytes = 100 Should be bytes[i] = 100 Right or wrong?
- erper 13y ago
  you're right. unless i really don't understand Go code.
Chris2048 13y ago
I'd like to see go compared to netty as well. Is there a good place for this kind of thing, SO obviously doesn't care for it.

176 points by g0lden 13y ago

Here is the original link: http://blog.safariflow.com/2013/02/22/go-as-an-alternative-to-node-js-for-very-fast-servers/ http://blog.safariflow.com/2013/02/22/go-as-an-alternative-t...

616c 13y ago

So beyond the ironic comment mentioned before with the Golang Hello world tutorial using Chinese, what is the real reason behind the Chinese following behind Go? It seems like this site confirm there must be a pretty dedicated Golang following, but I cannot figure out for the life of me why. Does anyone actually know?

samnardoni 13y ago
For me, Go has the least "What the hell does this code do?" and "Why isn't this code working?" of any language I've ever used. I'd say Go isn't an impressive programming language, but a very impressive software engineering language.
- bsg75 13y ago
  > Go isn't an impressive programming language, but a very impressive software engineering language. Curious, what is the distinction?
  - icedchai 13y ago
    IMO, simplicity, no surprises, doing stuff in a way that "makes sense" without a lot of boilerplate or cruft.
  - coldtea 13y ago
    He means that Go will not impress programming language geeks and academic PL researchers with cool evolved syntax or cutting edge features, but is a fine language for actually building software. In the same sense that a language that "in theory" has tons of cool stuff might be unusuable in practice (due to complexity, opaqueness, lack of libs, strange syntax etc).
siddhant 13y ago
Not necessarily. I suppose the hello world tutorial shows hello world in Chinese mostly to show Unicode. And as for this link, this is just an external link (http://blog.safariflow.com/2013/02/22/go-as-an-alternative-to-node-js-for-very-fast-servers/ http://blog.safariflow.com/2013/02/22/go-as-an-alternative-t...) that someone posted on a forum. Things like these happen on every forum in every country.
- 616c 13y ago
  Yeah, not sure what happened but this was the link below a few minutes ago. http://bbs.studygolang.com/thread-278-1-1.html http://bbs.studygolang.com/thread-278-1-1.html Notice that, despite English content, the forum looks Chinese-language oriented. I think it is cool, but not normal to me.
justincormack 13y ago
There was some discussion here but no OK me seems to know more https://news.ycombinator.com/item?id=6161399 https://news.ycombinator.com/item?id=6161399
- freyr 13y ago
  Your original comment: > They seem to be making a concerted effort to make Go Chinese friendly https://code.google.com/p/go-zh/ https://code.google.com/p/go-zh/ The Chinese fork seems to be a project started by Minux. Minux (Shenghou Ma) is a Go contributer and is very active in the Go community, but he does not work for Google, as far as I know.
  - 616c 13y ago
    Interesting. Unfortunately I did not make it past year one Chinese in university, so I do not remember enough. If I had known, I would go find out if he contributes a lot on the Study Golang BBS.
corresation 13y ago
Do you mean specifically why there is a dedicated Chinese following in particular, or just in general? Go is a clean, intuitive language with a very robust supporting ecosystem and a strong concurrency model. It builds fast, small code and makes quick work of big problems. Why shouldn't there be a big following of one of the better platforms to come out in a long time?
- agentultra 13y ago
  My only gripe is its intended use as a systems programming language. The runtime kind of makes it a silo; ie: hard to bind other languages to it through an FFI. Of course if I am mistaken or there's something being done to address such a scenario then I will be much happier seeing more and more infrastructure code shipping in Go.
  - mratzloff 13y ago
    Go has the same FFI language that most languages do: C. http://golang.org/cmd/cgo/ http://golang.org/cmd/cgo/
    - masklinn 13y ago
      Wrong way around. By "bind languages to it" agentultra talks about using Go from other languages, not using C from Go.
  - corresation 13y ago
    >hard to bind other languages to it through an FFI. Go has absurdly simple FFI through, as mratzloff mentioned, C. This is self-promotion and apologies, but see my submission history for two examples.
  - masklinn 13y ago
    > My only gripe is its intended use as a systems programming language. It's not. It's a new Java, not a new C++. > ie: hard to bind other languages to it through an FFI. More or less impossible: GC and goroutines are not optional so you'd need to cleanly setup and shutdown the Go runtime. You'd have to embed Go as you do Lua or Python.
fredsanford 13y ago
Maybe because a lot of choice has been removed from the system? I've worked with a bunch of people from different countries and find that the more strict the gov't, the less they like choice, in general. All anecdotal of course... Giving one guy from the Ukraine the typical choices at a restaurant here in the US would freeze him in place. What would you like to drink? Tea Sweetened or Unsweetened? Sweet. frustration += 1 Sugar or artificial sweetener. Sugar. frustration += 2 Soup or Salad? Soup. frustration += 7 Which soup? Minestrone, Pasta Fagioli, Italian Wedding? frustration += 14 and on and on... Ukraine started packing his lunch. Then there was the guy from Iceland... He took 10+ minutes to decide what to order in a new place and once he figured out what he liked in a particular place, he never gave the waitstaff a chance to offer him a choice. This, well done, salad with x dressing, with unsweetened tea. Iceland liked making the choices but only a few times. Some people like to be dictated to: Code will be formatted like this. Braces will be like this. etc. The author of the article thinks these are a feature while I find it obnoxious. My brain requires braces to line up in the left column, anything else slows me down. Maybe I'm just old?
- mr_luc 13y ago
  Off-topic on the subject of restaurants: I use the ML approach of combining other people's algorithms. :) My first time in a new place, I'm usually with friends, and I imitate their orders. On the rare times when I'm not, I ask the waiter what the favorite plates of he/the other people in the restaurant are, what they order when they eat there. This way even my initial orders are lightning-fast and already judged as 'tasty' in comparison to other offerings. And over time, I can investigate other plates for myself.
- asabjorn 13y ago
  It does not make sense to group peoples reaction to choice like this. As a counter example Apple products are very popular in the USA and other Western Countries, and Apple does not give you many choices.
  - fredsanford 13y ago
    I used a lot of weasel words in my comment to avoid follow up comments like this. Maybe, anecdotal etc... It was simply something I noticed from lots of years working with lots of people from lots of different countries. No offense was intended.
Jhsto 13y ago
If you meant the Hello World example, it is probably because the board game Go originates from China: http://en.wikipedia.org/wiki/Go_(game) http://en.wikipedia.org/wiki/Go_(game)
- prewett 13y ago
  I doubt it. If I recall the example correctly, it was "Hello, 世界!" Since "世界" means "world" the example is really the same "Hello, world!" example from C, only with one of the words changed to something that clearly requires Unicode. That was certainly my reaction when I saw the example: "oh, good, easy Unicode support" I expect the choice of Chinese as the language is probably the fact that you can't play code page games very easily with Chinese, which you could with Korean, Arabic, etc. It is probably the most widely spoken language with a non-Latin character set. Also, chances are very good that a Chinese-writing colleague of the example writer was readily available. Although, who knows, it would be fun if it were because of the board game.

munimkazia 13y ago

If you read the original blog post on http://blog.safariflow.com/2013/02/22/go-as-an-alternative-to-node-js-for-very-fast-servers/ http://blog.safariflow.com/2013/02/22/go-as-an-alternative-t..., one of the commentators actually attempted the comparison between node.js and go, and his results for node.js was significantly faster.

axaxs 13y ago
Go version 1.1 was more than a significant increase in net handling speed.
- bhauer 13y ago
  Not only that, but although the particular test described in the linked blog post did not include database connectivity, we saw a massive increase in database performance in 1.1 versus 1.0.2 due to a fix in the sql package [1]. That was back in Round 4 of our project [2]. Just something to be aware of if anyone reading has Go 1.0.2 installed and has not yet upgraded. 1.1 is worth the upgrade. [1] https://code.google.com/p/go/source/detail?r=45c12efb46 https://code.google.com/p/go/source/detail?r=45c12efb46 [2] http://www.techempower.com/blog/2013/05/02/frameworks-round-4/ http://www.techempower.com/blog/2013/05/02/frameworks-round-...
bhauer 13y ago
Thanks for the link to the original. Perhaps "February 22, 2013" should be identified in the title here? That explains the use of Go 1.0.2.

MatthewPhillips 13y ago

Is it possible to write Go in a functional way? Are there first class functions? Anonymous functions? If so it seems it would be possible to write highly functional code given the flexibility of interface{}

deleted 13y ago
[deleted]
lmm 13y ago
Up to a point, but go's limited datatypes make it difficult to write the kind of code you're used to writing in haskell/f#/etc.
- payload 13y ago
  A haskell version with the Warp server performs just a little bit worse than the go version (6 secs vs 7 secs) with a little bigger minimal latency (68 ms vs 71 ms). go version go1.0.2 runghc 7.6.2 cabal packages of today Runned with "runhaskell main.hs" on localhost over loopback :) import qualified Network.Wai as Wai import qualified Network.Wai.Handler.Warp as Warp import qualified Network.HTTP.Types as HTTP import qualified Data.ByteString as ByteString import Blaze.ByteString.Builder.ByteString (fromByteString) main = do let port = 8000 Warp.run port app app req = do let n = 1024*1024 let bytes = fromByteString $ ByteString.replicate n 100 return $ Wai.ResponseBuilder HTTP.status200 [] bytes
  - cgag 13y ago
    Am I right in thinking that Haskell servers will likely be winning on these benchmarks after Mio is released in 7.8.1? https://news.ycombinator.com/item?id=6198068 https://news.ycombinator.com/item?id=6198068
    - Peaker 13y ago
      Since Warp seems to use many light-weight(green) threads behind the scenes, and Mio is mainly about improving multithreaded performance on actual multi-core set ups, the answer seems to be yes. However, it would probably only help if you use -threaded (which you should, anyways).

AndyKelley 13y ago

I did the benchmarks outlined at the end of the article. Summary of results: 1. Node.js v0.10.15, single worker: 46.2 seconds 2. Node.js v0.10.15, cluster 8 workers using naught: 17.2 seconds 3. Go 1.0.2, GOMAXPROCS left default: 3.5 seconds 4. Go 1.0.2, GOMAXPROCS=8: 3.7 seconds Detailed results below: 1. Node.js v0.10.15, single worker Concurrency Level: 100 Time taken for tests: 46.217 seconds Complete requests: 10000 Failed requests: 0 Write errors: 0 Total transferred: 10486510000 bytes HTML transferred: 10485760000 bytes Requests per second: 216.37 [#/sec] (mean) Time per request: 462.168 [ms] (mean) Time per request: 4.622 [ms] (mean, across all concurrent requests) Transfer rate: 221580.08 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.2 0 3 Processing: 193 461 36.2 450 944 Waiting: 16 235 127.3 235 534 Total: 193 461 36.2 450 944 Percentage of the requests served within a certain time (ms) 50% 450 66% 467 75% 470 80% 486 90% 492 95% 514 98% 517 99% 545 100% 944 (longest request) 2. Node.js v0.10.15, cluster 8 workers using naught Concurrency Level: 100 Time taken for tests: 17.199 seconds Complete requests: 10000 Failed requests: 0 Write errors: 0 Total transferred: 10486510000 bytes HTML transferred: 10485760000 bytes Requests per second: 581.41 [#/sec] (mean) Time per request: 171.995 [ms] (mean) Time per request: 1.720 [ms] (mean, across all concurrent requests) Transfer rate: 595408.80 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.2 0 3 Processing: 7 171 116.4 149 739 Waiting: 5 96 81.9 71 710 Total: 8 171 116.5 150 740 Percentage of the requests served within a certain time (ms) 50% 150 66% 197 75% 236 80% 266 90% 324 95% 397 98% 438 99% 493 100% 740 (longest request) 3. Go 1.0.2, GOMAXPROCS left default Concurrency Level: 100 Time taken for tests: 3.542 seconds Complete requests: 10000 Failed requests: 0 Write errors: 0 Total transferred: 10486730000 bytes HTML transferred: 10485760000 bytes Requests per second: 2823.16 [#/sec] (mean) Time per request: 35.421 [ms] (mean) Time per request: 0.354 [ms] (mean, across all concurrent requests) Transfer rate: 2891181.71 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 1 0.3 1 3 Processing: 9 35 2.2 34 56 Waiting: 0 1 1.3 1 22 Total: 12 35 2.3 35 57 Percentage of the requests served within a certain time (ms) 50% 35 66% 36 75% 36 80% 36 90% 37 95% 38 98% 39 99% 41 100% 57 (longest request) 4. Go 1.0.2, GOMAXPROCS=8 Concurrency Level: 100 Time taken for tests: 3.657 seconds Complete requests: 10000 Failed requests: 0 Write errors: 0 Total transferred: 10486730000 bytes HTML transferred: 10485760000 bytes Requests per second: 2734.54 [#/sec] (mean) Time per request: 36.569 [ms] (mean) Time per request: 0.366 [ms] (mean, across all concurrent requests) Transfer rate: 2800429.67 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 1 0.4 1 3 Processing: 19 36 2.5 35 57 Waiting: 0 1 1.1 1 16 Total: 20 37 2.5 36 58 Percentage of the requests served within a certain time (ms) 50% 36 66% 37 75% 37 80% 37 90% 38 95% 39 98% 42 99% 51 100% 58 (longest request)

deleted 13y ago

[deleted]

rartichoke 13y ago

That test is rigged to be a best case scenario for Go. How often do you send 1MB responses down to the client? If you send 3KB responses then you would see both setups are much closer in performance. Factor in some actual I/O and the difference will be even less. Then you'll eventually realize using either one makes little difference when it comes to performance. This is why micro benchmarks are pure jokes. A real world site has a mix of response sizes, database I/O and caching. It's the only way to test something properly and you'll see if you properly test both there will be little difference in performance.

redneckbeard 13y ago
Original author of the post in question here. Please note that the microbench was "rigged" by the author of Node when he was first presenting it several years ago (spelled out in the article). If you need a tl;dr, it's this: I don't care for JavaScript as a language. Many make the argument that JavaScript should be adopted widely server-side because of its speed. I assert that languages should be evaluated not only for performance but for maintainability, feature sets, standard library, etc. Go provides a great combination of execution speed, development speed, and ease of maintainability.
- rartichoke 13y ago
  The development speed isn't very good with Go because you have to re-invent almost everything yourself because the web libs are seriously years behind other platforms. The default template language is also really archaic and no one has created a solid alternative yet that's actually well tested and used by the masses. It might have good execution speed and the language itself might be nice but the only thing that matters is going from point A to point B. Go will not get you there faster than other languages and the execution speed is a non-issue for pretty much every platform (even rails) if you use tools available to you to their fullest. P.S., I compared Go to Node almost a year ago and even wrote a mini framework for Go to resemble a smaller version of Express. I eventually just said fk it and stopped because the gains were not even close to being worth it.
  - 13y ago

swah 13y ago

Go doesn't mean just fast for me; in that space there is also the JVM. To me, it fits the fast and lean and easy to deploy space.

tensor 13y ago
The headline of this article bothered me in this regard. Node.js is decidedly middle of the pack in terms of performance: http://www.techempower.com/benchmarks/ http://www.techempower.com/benchmarks/ In addition to various JVM technologies, there are faster technologies in C++, PHP, and Lua.
- pekk 13y ago
  I think you will find that in many actual applications PHP is not faster than Node. Further, once you apply a framework to paper over some language warts, performance is often terrible and can only be rescued by extremely liberal caching. If this were not so, it would be hard to see the motivation for HipHop.
  - tensor 13y ago
    Might the motivation simply be to get closer to C++ performance? I really don't value this type of response where the benchmark is brought into question, yet nothing is substituted as evidence. In the few cases were someone does claim that they rewrote a sufficiently complex system in Node from some other language, it's impossible to discount that the performance changes come from architectural choices rather than language choices. Playing devils advocate, I've heard the same claim you put forth here about Node.js: it gets much slower in real apps because you have more slow JS code being run vs the very fast C libraries that back the core of Node.js. To me, benchmarks like the one I posted above are the most compelling form of evidence we have. What I take from it is that a great many "boring" languages and frameworks are really very fast. It's not the answer that most people want to hear of course; it goes against the current popular hype.
cgag 13y ago
What's easier about deploying Go vs with the JVM? Deploying stuff I've written in Clojure has been pretty easy.

markuskobler 13y ago

Are these trivial micro benchmarks, (simply respond with an empty 200) not totally misleading to focus on? Especially when you start to factor in many real workloads that involve disk or network io.

ilaksh 13y ago
Its not empty because its 1mb but it is misleading because in the original article someone's comment showed Node going much faster than Go. If it were empty then Node would be faster because you can get 4000 req per sec if its empty. I think something weird is going on though because it should be more than 300 per sec with the new Node version even if its 1mb.

Morphling 13y ago

I know this post is about speed, but you should always remember that with node.js you only need JS developers while with Go you are probably going to need both Go and JS (for front-end stuff) developers. Just my two cents.

cenhyperion 13y ago
Or developers that are comfortable with both JS and Go.
gtaylor 13y ago
At the same token, having frontend JS devs that don't have much experience in writing backends can leave you with a mess to clean up or completely re-write in the future. I think this "benefit" of using the same language for front and backend is pretty over-hyped, as well. In theory, I can agree that it sounds good. In practice, use the best tool for the job on both ends to fit your team's abilities and strengths. The other neat thing is that if your frontend and UI are cleanly separated, you can swap them out individually without the other even noticing. If our backend gets to be too sluggish, I can replace it with something lower level gradually over time (Go?) without leaving a bunch of deprecated backend JS cruft to clean out.
- purplelobster 13y ago
  As a single developer on a project, I use js on the front-end, NodeJS and CouchDB (views written in js). This means that every step of the way is js, json and http, which is extremely liberating for me, as someone who's just starting out with web development.
- ef4 13y ago
  I have a rich, client-side, fully-offline-capable javascript application. I started out with a different language for the backend, but over time the benefit of switching to Node and sharing one codebase became overwhelming. Just to give one example: any data query can get answered locally or from the server, depending on what's already cached and whether you're online. Before, I had to implement every call twice and make sure they stayed in sync. Now I can implement once and run the same code in both places. And other interesting possibilities open up. The server can just run the client's data synchronization code to pull changes from another server, giving realtime server-to-server replication nearly "for free".

invisible 13y ago

I've worked with both node and Go. There is a lot of hyperbole and fluff points about Go's strengths in the original article (sorry to the author!). Things that are touted as huge wins for Go have equally better things in node. Both platforms are great and they both have appeal for different people. My eloquent post was eaten by an expired link on the original article but here are some counter-points: The commutative property applies to all code that has semicolons to end lines. Use jslint/jshint/an IDE. The symbol is "optional" not marked as "leave it out because it makes scripts nicer." Use jslint/jshint/an IDE to prevent globals. Seriously. It's the same as running go fmt on your code. Forcing people to use "channels" as a best practice to accomplish scaling is the same as the best practice of callbacks - but yes, channels are nicer to use. Node standard modules require callbacks by default as Go standard library implements channels by default. 32-bit integers in JS don't have float problems because the precision doesn't break Typing in Go can still be annoying for some situations. If you're dealing with external content (creating an API with mutable content that you still need to read) it can be annoying at best (e.g. reminds me of writing C). Types in Go are a nice implementation though. npm is way better than go get and there are at least 3 projects in Go trying to replicate npm's ease-of-use The vim/emacs syntax highlighter is nice but it's awfully frustrating if you don't use vim/emacs. This is due to Go's young age, but you shouldn't be forced into using a certain editor to get syntax highlighting. The alternative to "go fmt" for Javascript is a good IDE or jslint/jshint. In Go, you get a lot in the standard library, but you miss out on a lot in the community. Yet another young language problem, you wind up having to roll your own for a lot of things that should just exist. It can be frustrating looking for answers because you might be the first person working on the problem in the language. Also, just as a general thing I've perceived, people seem to argue static types vs dynamic types more than that a particular language is "better." Go and JS/node are both great!!!! Go is typed, JS is not and you deal with the consequences in both situations. Static typed languages have big faults with external data handling that sometimes cripple features (or makes them far more difficult to accomplish). Dynamic typed languages can fall victim to variables being used incorrectly (especially when not using an IDE). That's the biggest bulk of the difference in my experience.

drsintoma 13y ago
> Typing in Go can still be annoying for some situations. If you're dealing with external content (creating an API with mutable content that you still need to read) it can be annoying at best (e.g. reminds me of writing C). Types in Go are a nice implementation though. Indeed, that's probably the biggest flaw I've found working with GO's type system. Trying to work with unknown n-level JSON is real pain.

lloeki 13y ago

Also, Go as an alternative to <whatever> for very slow servers. I use Go on my Pi and the thing flies.

sandGorgon 13y ago

Did you compare with a JVM toolkit with similar concurrency libraries like Akka/Scala? Am curious to find out the results. There was a recent, don't remember which, comparison that put Scala way ahead of Go possibly because of a superior GC. Wonder if the results correlate

jambay 13y ago

I think there is a typo in the go sample program. bytes = 100 Should be bytes[i] = 100 Right or wrong?

erper 13y ago
you're right. unless i really don't understand Go code.

Chris2048 13y ago

I'd like to see go compared to netty as well. Is there a good place for this kind of thing, SO obviously doesn't care for it.