4 ms·

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/Fla

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.

pkulak 14y ago
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.
- rartichoke 14y ago
  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.
      - 14y ago
tptacek 14y ago
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?
- rartichoke 14y ago
  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.
  - tptacek 14y ago
    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. I think you're mostly just handwaving.
    - rartichoke 14y ago
      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.
      - chrisbroadfoot 14y ago
shadowmint 14y ago
Not entirely without gains: 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.

pkulak 14y ago

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.

rartichoke 14y ago
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.
    - 14y ago

tptacek 14y ago

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?

rartichoke 14y ago
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.
- tptacek 14y ago
  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. I think you're mostly just handwaving.
  - rartichoke 14y ago
    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.
    - chrisbroadfoot 14y ago

shadowmint 14y ago

Not entirely without gains: 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.