3 ms·

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

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.

DennisP 14y ago
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.
- rartichoke 14y ago
  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.
  - DennisP 14y ago
    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_JavaScript_solutions 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.
    - rartichoke 14y ago
      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 libs speak for themselves.
  - Pherdnut 14y ago
    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.

DennisP 14y ago

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.

rartichoke 14y ago
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.
- DennisP 14y ago
  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_JavaScript_solutions 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.
  - rartichoke 14y ago
    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 libs speak for themselves.
- Pherdnut 14y ago
  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.