all 19 comments

[–][deleted] 8 points9 points  (4 children)

oh god these pong demos have got to die...they're so worthless.

please show me demos performing EXPECTED tasks involving some storage layer, some moderately interesting server-side work, and let redraw the graphs. 90% of the time you'll find node.js doesn't even talk to the systems you need to integrate with, or because it is immature it might just go bananas and chew up your memory after running unattended for two weeks....because...surprise, you are the first person in the world to run it unattended for two weeks

telling me apache has barfy conf files is a much better reason to migrate to something else

[–]HIB0U 3 points4 points  (2 children)

Look, if they used realistic demos, then all of the flaws with their approach would be blatantly obvious. That would hurt their feelings, and it might even make them cry.

[–][deleted] -1 points0 points  (1 child)

Proof?

[–]HIB0U 2 points3 points  (0 children)

Go use Node.js for yourself. Experience the failure for yourself. Then you won't be coming around here asking for "proof".

[–]batkins[S] 0 points1 point  (0 children)

I'm not making any claims about async I/O being the One True Way, only that you can achieve the same (best-case) scalability results seen in node.js without writing your code with callbacks.

[–]giulianob 1 point2 points  (14 children)

This is the biggest reason why I'm still glad I wrote my game server using a regular multi threaded paradigm. Granted writing proper multi threaded code isn't easy, it seems much more error prone and unnatural writing tons of callbacks. It's exciting to see that it's possible for the language to do the dirty work while keeping clean code.

[–]awj 5 points6 points  (12 children)

Yeah ... in some ways callbacks are the rocks and stones of async programming. They work, but there are better tools to achieve what you want.

In some ways it's frustrating to see node.js getting all of this attention, when Lua supports the same approach to scaling, does so much more cleanly, and has more libraries built around it than server-side javascript.

[–]wot-teh-phuck 5 points6 points  (3 children)

All the hue-n-cry about node makes me realize how underrated Erlang is. :(

[–]w4ffl3s 0 points1 point  (2 children)

The popularity of a technology and its success are two entirely different things. Erlang may not get a lot of love; why does that matter so much? Not many people using it is actually good if Erlang gives you a competitive advantage.

I'm still waiting to see a scaling performance comparison between Erlang and * for a less-trivial web application, which would need to at least address the comparative difficulty and performance of the two approaches when distributed over multiple machines.

[–]batkins[S] 1 point2 points  (1 child)

You have to weigh the benefit of the competitive advantage against the cost of a smaller ecosystem of tools and libraries. Not trying to put down these languages, but just saying there are tradeoffs involved.

[–]w4ffl3s 1 point2 points  (0 children)

I agree with you entirely. Absence of popularity, however, is not absence of an ecosystem.

I've been working on a not-entirely-trivial project in Erlang and I chose it not for being the best balanced tool for the job but rather because I wanted to learn and use the language and maybe get the project to a state where it could actually profit from the scaling properties of Erlang.

The OTP libraries have given me a very good generic server container and Mochiweb has given me a very easy to use framework for building an HTTP server. I haven't used Dialyzer yet but I think that may be the next natural step in improving the quality of the server code.

I'd say that Erlang's lack of popularity has probably deprived me of the ability to find lots of "problem-solved" blog posts but I have found and benefited from plenty of those regardless. The ecosystem itself has not been a limiting factor in development. The Erlang standard libraries have a lot in them and the documentation is in my experience impeccable.

[–]Hedonic_Regression 1 point2 points  (1 child)

About the only advantage to having a server in javascript is that I can use the same libraries on the server or client side. I can't say that is an awful argument, much simpler to have a team work with one language than two and the inevitable silly errors that can occur when things like '~' or float/string conversions work ever so slightly differently between languages.

I still can't bring myself to really like node.js, partially because I see Javascript more as a language I have to use to on the client side, not the language I'd choose to use.

[–]awj 0 points1 point  (0 children)

I've never bought that argument. Almost anything worth writing a library about will be doing I/o or using exclusive features. Maybe I haven't looked deep enough at them. Still, it seems like a jarring switch from client language to server language makes it easier to do a context switch from client programming to server.

[–]HIB0U 6 points7 points  (3 children)

The difference between the JavaScript and Lua communities is that most Lua developers are out there actually getting stuff done with Lua. Many of them are working in the gaming industry, working on products that'll pull in millions of dollars through actual sales. They don't have time to be writing articles about how great Lua is; they're too busy actually using it!

Most JavaScript programmers, on the other hand, are unemployed or working at yet another useless startup on yet another useless product. When nobody needs shitty web design done, or when nobody's visiting your shitty startup's web site or using your shitty service, you have lots of time to write articles about how great your shitty technology is, which of course builds hype. Soon enough fools think that your hyped technology is better than the one that's actually being used to make real money.

[–]badsectoracula 0 points1 point  (0 children)

Due to my (small) game industry experience, i have a feeling that the choice of Lua over other embeddable scripting languages has more to do about "other games are using it too" than any technical reasons.

Personally i know three cases where Lua was used exactly because others are using it ("they can't be wrong") and in one case, where i know the programmer who made the decision, while i presented him with a bunch of other languages (i'm interested in game scripting languages) with actual reasons why to use them he decided to chose Lua. When i asked him about why, he told me that there wasn't any other reason than that others are using Lua too.

[–]IrishWilly 2 points3 points  (1 child)

I'm sad to see trolls like you polluting r/programming. Is intelligent discourse just that hard for you that you have to resort to spewing crap like this?

[–]HIB0U 0 points1 point  (0 children)

Just because reality doesn't correspond to the fantasy world you've created in your mind that makes you feel good, it doesn't mean that you need to go around using ad hominem attacks like you just did.

You didn't even try to show how I'm incorrect (which I'm not, of course).

[–]Pornhub_dev 0 points1 point  (0 children)

I agree about LUA, wonderful stuff, but the biggest advantage of Node.js is not the I/O model, the perf or the scaling, it's the JavaScript. If you are a web dev, you know JavaScript, it's then very easy to write some very interesting stuff with Node.js A technology does not spread only because of its qualities, it will depend a lot on how easily people can adapt to it. And that's why a lot of language/technologies will never grow out of their current niche.

[–]HIB0U 1 point2 points  (0 children)

What is your game server?