Seems like most issues (except the nil problem, which is explained very well by chimeracoder) are not really with the language itself, but just with its ecosystem, which naturally is nowhere near something like Java or Ruby at this point. I agree, and while I love Go, I would probably develop a new web app in Sinatra. Who knows if that will be the case next year, though.
Yep, that's what I noticed too. This makes me hopeful, because if the biggest criticisms of a new language are "it's not mature yet", it's a very good sign for the language. I'm glad they didn't have problems with the language's core components.
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.
Yeah and this is why I don't think it will ever become semi-main stream. I personally use Express with Node and it seems a good amount of people use Sinatra/Flask as well.
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.
Yes because Javascript and Golang are basically the same language with basically similar approaches to concurrency, similar deployment characteristics, similar toolchains, and comparable performance in most situations. Is what you're saying, right?
No, they have much different ways of dealing with concurrency. Deployment is a solved problem in most modern languages.
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.
If by "solved problem" you mean "if you accept the problem of keeping an up-to-date deployment environment on every machine with up-to-date patches", compared with "build this binary copy it over and run it", yes, Node and Golang deployment is comparable.
It is a solved problem. You can't just copy over a folder (or file) and call it a day but it doesn't take that much to get Node deployed by simply typing 1 command on 1 machine and this is the same thing you would end up doing for Go too.
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.
Ok, so you're going to be scp'ing your binary over manually every time? Do you manually do your other build tasks too?
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.
Interesting that you are using Node.js as your example. Just a couple years ago Node was the new hotness, but was pretty terrible for creating an entire website.
Go has been out for a number of years. It shipped v1.0 almost a year ago and Node hasn't shipped v1.0 but who cares about version numbers.
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.
Node.js was released in 2009, the same year as Go. But Node uses a language released in the 90's, which at this point is arguably the most popular language in the world.
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.
I think it's fair because a lot of JS code is highly coupled with the DOM which isn't really going to be that useful for the server except for projects like phantomjs and other similar libs.
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.
But Node wasn't the first server-side javascript. In fact, Netscape released a server platform for it a few months after releasing the language. Quite a few others have cropped up since then: http://en.wikipedia.org/wiki/Comparison_of_server-side_JavaS...
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.
It doesn't matter. SSJS's past has nothing to do with anything in this discussion.
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 only part of JavaScript that's tied to working with web UI is the DOM API, which isn't even a part of the ECMAScript standard but rather set by the W3C and meant to be language-independent. I think Python could have worked out on the client-side but there were other options and none of them lasted. Give JS a more serious look. You might be surprised to discover that it has some unique features that make it attractive as a general-use language. I think JS has a lot to do with why people suddenly wanted closures in Java or that they implemented proper first class funcs in C#. It's exceptionally good at event-driven paradigms, normalization and reducing complexity, which is exactly what was needed on the client-side but also serves as a powerful feature-set in general use IMO. It's good at letting you set your own paradigm. If you don't love callback-passing-intensive code, that's something you can bury under an interface that appeals to you more.
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.
