Hacker News Reader

Comment by rartichoke | Hacker News Reader

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.

View on HN

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 libs speak for themselves.

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.

Reply on news.ycombinator.com