Live data from Hacker News

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

techblog.safaribooksonline.com

71–80 of 147 posts

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

#71
post #69
post #65

Earlier quoted context omitted.

But go ecosystem still doesn't have anything even close to refactoring abilities of Java/C# IDEs. Say, move Java class which is in use in 100s places from one package to another is just few mouse clicks in Eclipse and a lot of pain in case of Go.

Not really. Go comes with code rewriting tools, unsurprisingly since they were used to update the standard library and 3rd party code when the language changed before Go 1. I don't want to use a language that doesn't come with a parser in the standard library anymore.

So, is it possible to move/rename class/method/field smoothly using those tools? Extract code block to new method?

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

#72
post #58

Earlier quoted context omitted.

> For some reason people still hate the language even though it's the closest to being the most versatile language around (in every single aspect that makes a good language it ranks well against the others) In every respect that a PHB may care about, perhaps. I think you should examine that "for some reason" more carefully before declaring that all reasons favor Java. Clearly there is something going on there, unless…

Well, I know lots of programmers who do like Java, you just don't see them that much on Hacker News. Reasons: - Availability of good IDEs. - Good dependency management and build infrastructure via Maven. - Quick and easy deployment via servlet containers. I am not a big Java fan, but having written quite much code, feature-wise there are not that many advantages of Go over Java. Package management in Go is nice for a…

You and VeejayRampay seem to have misunderstood me. I'm not saying the language is all bad, or that the technology is crap, or that there are not programmers who love everything about it. I am saying that there are reasons that many people dislike Java; it isn't just some sort of blind prejudice.

@VeejayRampay

Considering the love Clojure gets on HN, I reject the notion that Java gets a bad rap due to historic shortcomings of the JVM or ecosystem. No, the language itself is disliked, not the tech. Its constructs and its idiomatic usage. Things that your standard PHB will find difficult to quantify. This is in stark contrast with how the JVM is perceived (from my perspective, it seems to be widely adored).

I'm saying this as someone who currently makes their living programming in Java.

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

#73

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

Define hideous.

"Extremely unpleasant"

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

#75

One advantage of node that wasn't mentioned is the ability to share server side and client side code. Avoiding discrepancies in the same form validation written in two different languages can often be more important than performance gains in server applications.

>One advantage of node that wasn't mentioned is the ability to share server side and client side code

You can do that with lots of languages, using one of the langX->javascript compilers.

>Avoiding discrepancies in the same form validation written in two different languages

What form validation are you doing in javascript? I can't actually think of any client side validation that isn't just a regex.

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

#77
post #9

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

In case you didn't see it, I commented above with a link to a bug.

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

#78
post #10

Earlier quoted context omitted.

Yes, but at what point does go transition from obscurity to PG's "python paradox"? http://www.paulgraham.com/pypar.html It sure seems Scala's in this "python paradox" land now. My guess is that you need some startups make it big using Go to evangelize it. Google using it is interesting, but I'm not sure it makes it "cool". Though, I'm not sure Java was ever a language you could use as a skillset filter. Hm.

Pretty much anything Google does is cool. Probably same could be said about Amazon, Facebook et al. Depends a lot on your interpretation of "Cool" though.

Right.

I get more of the sense that Google is more "impressive" than "cool".

If I were to use "Google's got it in production" I might be told something like "well they can pull this off" as if they have some unattainable smarts or something.

Whereas a "cool" thing is more about just simply taking a risk.

Come to think of it, that's kind of a funny definition. Oh well.

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

#79
post #67

Earlier quoted context omitted.

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.

Maybe you didn't do much OCaml? I've found it to be mostly significantly better than Go, especially with it's type system. Go's type system is relatively limited and ad-hoc where OCaml's is extremely elegant, simple and consistent. In particular, OCaml has an awesome module system and a great take on structural sub-typing combined with proper type inference and sane parametric polymorphism. Having actual algebraic da…

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 using OCaml so I can't comment on that (incidentally, I dislike many of their choices).

Also Go has many of the features that make programming in ML a pleasure, many languages these days have them, which is a good thing.

Personally my tool of choice for many tasks would be OCaml with Go's package management system, and perhaps a syntax closer to M-expressions (like Mathematica).

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

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

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.

Here's a comparable Haskell server, warts and all

    {-# LANGUAGE OverloadedStrings #-}
    import Snap
    import qualified Data.ByteString as BS
    
    main :: IO ()
    main = httpServe (setPort 8000 emptyConfig) $ writeBS $ BS.replicate (1024*1024) 100

I'm benchmarking it currently, but my laptop's network stack seems to break ab. It's also probably faster to build the response incrementally using an Enumerator, but I've never used Snap's Enumerator library and this is slightly closer to the design being tested in the other servers since it'll allocate the whole bytestring instead of writing it lazily.
Post reply on HN