Also, it matches my experience. It's very nice for some uses, but web development isn't yet a strong suit. Django, for example, is much more mature and has a component for almost anything you might need for web development.
Hopefully Go will reach that point soon.
It's much more than just that though. If you scanned Express feature by feature you could implement most of them in Go. I would imagine someone experienced in JS and Go could port the entire thing over in a day.
It's just then what? Now you have:
1. Similar / worse performance.
2. Way less useful libs to leverage.
3. Have to write 2 languages instead of 1 (if you happen to already use Node).
4. Dealing with way less mature libs for crucial components that you definitely don't want to be writing yourself.
There's basically no gains. Deploying single binaries is great but a "write once, use nearly forever" build script makes deployment a snap with any non-compiled language.
Testing support is amazing in JS too and debugging is leap years ahead of Go. Using gdb is just archaic compared to using node-inspector. I'm sure Ruby and Python have equally as amazing testing/debugging support too.
Both languages have been available for quite some time. It's not about hotness at all. No one seems to WANT to use Go for serious web application development and this is proven time again by the lack of good libs available.
Go on the other hand was actually a new language, which took a while to stabilize. So I don't think this is really a valid comparison, especially if you're going to talk about library support.
The only benefit JS has over Go for adoption is that people are pretty much forced into using JS or something that compiles into JS.
I think Go's take on concurrency is less confusing than callbacks. It's not like the language is massive and close to impossible to learn.
People had a ton of time to create interesting web dev related libs for Go but no one has. There's only a mix of libs that are pre-1.0 (dead), really low quality (missing extremely critical things), or bad performance because they haven't been tweaked under load because no one is using them.
They weren't all that popular, but I think that makes my point. These things can take a while.
If pre-1.0 makes a Go library dead, then Go has only had a year to develop non-dead libraries. You have to really be an early adopter to build stuff on a language that's still making breaking changes.
Also you're misreading what I'm saying too. I never said a pre-1.0 lib makes a go lib dead. It feels like a lot of people made libs pre-1.0 and then abandoned them but pre-1.0 libs make up a pretty big portion of what's available to use right now.
I don't want to use a buggy untested, unmaintained lib as an application developer. This goes for any language. But right now a lot of Go's libs are in this state.
Anyways I'm done replying. You would rather pick at negatives in every post I make and ignore the other things that make sense just to somehow make your case better.
The libs speak for themselves.
I think you may have misunderstood my post?
I also spent a pretty decent amount of time performing real world benchmarks for both languages by writing applications in both and then ran various performance metrics. Performance for general web apps with real world data goes back and forth depending on what you're doing.
My point was Go doesn't offer nearly enough pros for it to worth switching to.
I think you're mostly just handwaving.
If you ever dealt with deploying to more than 1 machine you would realize that doing it by hand is a pretty crazy idea. The first thing you would do is create a solution that allows pretty much hands free deployment, and those solutions exist for every modern language. Heck, it's one of the first things I did as a developer even while deploying to 1 machine.
No, you'd just need to copy over one binary. Go programs compile to a system binary.
No, you would have a build script that minifies/concats assets, runs tests, maybe generate docs, then finally deploy using whatever method you happen to be using if everything passes.
This might be a git deploy, or scping files over to some server.
In either case you're never copying 1 file over because that is abstracted away from you by your build script. In return you type 1 command and let your build script do the dirty work for you.
Typing this one command is the same if you're using Go or Node or any other modern language. It doesn't really matter that I have to add a few extra commands to my build script because these are things I only have to do once.
Yes, yes you can.
Concurrency. Yes, you do want it. go func() { /* periodically do stuff here. No cron jobs! Yay...! / }
Static binaries. Yes, you want that too. For example, I'm on a box with no external access. bundle install rails. Ugh~ o, that's not even possible. Blah. You can even cross compile* for other platforms. Amazing.
...but your comments are entirely valid. I wouldn't pick it over node or flask for a serious project; but it's fun to play with.