Live data from Hacker News

Launching NginScript

nginx.com

101–110 of 131 posts

Re: Launching NginScript

#101
post #72

Earlier quoted context omitted.

I'm willing to bet it won't bring them any new business. And in the long run, it will encourage their existing users to dump nginx and use Node.

Isn't Node more of an Application server though? I don't see Node replacing Nginx in the roles it's normally used for (serving static resources, reverse-proxy). I can't think of a single upside

Agreed... I don't want the effort and complexity it would take to offer a lot of what's pretty easy with nginx inside a node app. As much as I really like node, I think it's generally nginx in front of node to offset what it does better... I think people make applications complicated enough as it is...

Re: Launching NginScript

#102

This seems like massive overkill. Instead of adding a limited domain-specific language which is tuned to nginx's requirements, they've added the behemoth that is JavaScript, along with all its flaws. A turing-complete behemoth, at that.

It's a subset of javascript, with a subset of flaws. The wiki entry specifically mentions that eval and closures aren't supported.

So, kind of like JScript in IE3?

Re: Launching NginScript

#103

Earlier quoted context omitted.

So when are you going to release "node-ginx"? :)

You're on to me. ;) There is node-http-proxy available ( https://github.com/nodejitsu/node-http-proxy ), which also has some plugins available to do some of the advanced features nginx supports. I'll likely be writing a custom proxy server tailored to our needs such that it probably won't be useful as a general purpose proxy server, but if you're looking for something, that's a start. Making it more general purpose u…

For that matter godaddy's website builder now "publishes" to a cassandra cluster that is served via a cluster of node servers with local redis as a local in-memory cache... it works really well. The distribution model is working much better than the previous publishing via ftp to a dedicated backend linux host (apache). I haven't been there for about a year now, but I'm pretty sure a lot of those aspects have proven out.

Re: Launching NginScript

#105

HN and it's predictable level of antipathy is a constant disappointment. Hating is the norm, do better. Put more thought into your opinions. Personal feelings of Javascript aside (not my favorite either!), I think this is a great business move (adoption, excitement, blog-o-sphere marketing, even if some users shoot themselves in the foot), and I think it opens up exciting possibilities, including creating Nginx+ feat…

Anything you can do in nginScript, you can do in Lua. Except that Lua was lightweight to begin with. This isn't JS (as we know it), this doesn't get access to the Node/npm/bower/whatever ecosystems.

The antipathy is a symptom of our JavaScript disease. We have grown tired of this affliction. We understand now what makes it less great than we once thought. The churn of rapidly growing and devolving JS frameworks, the slog of awful design-by-committee processes putting the language together... it is nothing compared to Lua's simplicity.

And some clever fellows understood this long ago, on a site much like this one. Feel free to take a look. https://news.ycombinator.com/item?id=7890685

Re: Launching NginScript

#106
post #17

Earlier quoted context omitted.

It is. But JavaScript is the new assembly language, all you need is a Lua to JS compiler or a whatever to JS compiler.

Last I checked Javascript implementations were slower than LuaJIT. Cost of implementing Lua tables, meta-tables, co-routines, etc. in Javascript will be rather high. Anywhere between 2-50x. If native Lua engine is removed, you can just forget about it then. So what you're saying doesn't make any sense for anything remotely performance sensitive.

It's a joke. Like haha, but serious, because some people actually believe this.

Re: Launching NginScript

#108

We run a separate virtual machine for each request, so there’s no need for garbage collection I'm curious to see the impact of this strategy on performance.

I wondered about this sentence. If you would apply scripting functionality to serve long-running websocket or HTTP/2 connections I'm sure garbage collection would be necessary. However if the scripts are really per request and not per connection then it could work - but the capabilites would be much more limited then what you can do in other scripted-webserver-environments (e.g. node).

A VM context could be cheap to create and include an amount of memory above what that script uses for its lifetime. Meaning a single allocation and then the whole thing gets free'd at the end of execution. Analogous to how CGIs execute.

Re: Launching NginScript

#109
post #52

Earlier quoted context omitted.

I have tried so hard to like Lua, but I prefer 0-indexed arrays and curly braces.

The comment syntax is really what gets me.

Oh right, when you try to disable code with a block comment and an array says "not today".

Although the same happens in JS with Regular Expressions :P

Post reply on HN