Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launching NginScript

nginx.com

Post reply on HN
Print view View original

121–130 of 131 posts

Re: Launching NginScript

#121

Post by bungle »

neomantra wrote: post #34
marktangotango wrote: post #18

Earlier quoted context omitted.

Two things; The big HUGE win for lua in this, in my view, is the plethora of packages on luarocks. With simple scripts, as presented in this blog posts, sure a javascript subset is fine. But suppose you want to interact with redis from your script? Where's the c ffi interface, and a prepared package you can use from nginscript? Grap hiredis bindings from luarocks, and your set. Second, great yet another javascript im…

I agree with what you said -- although the node/npm ecosystem is much bigger. I'm not sure how it works with the nginScript subset. But network-related libraries shouldn't be pulled from luarocks (unless maybe they have resty in the name). One would want to use lua-resty-redis and not hiredis within OpenResty. The 'resty' libs use the nginx cosocket library so work asyncronously with nginx core. hiredis would block t…

Not asynchronously, but in a non-blocking fashion. Good thing is that Lua socket and ngx.tcp are quite compatible. But C libs with their own IO are - well they work, but they will block the nginx workers.

Re: Launching NginScript

#122

Post by mrbig4545 »

so it's mod_perl, but javascript and nginx instead of apache and perl. seems like they've ignored history here, as mod_perl turned out to be a bad thing in the end, people messing with bits they really shouldn't leading to massive amounts of unmaintained legacy spaghetti code messing with all parts of apache.

bearing in mind mod_perl's original use was not for writing applications, it was for messing with apache, for doing the things you can't easily do in the config. but where there's a way, abuse will follow, and before you know it whole apps will be written with this

ah well, those who don't learn from history are doomed to repeat it.

so, while it may seem like a good idea now, you can bet in 5-10 years it will no longer look so clever

Re: Launching NginScript

#124

Post by 59nadir »

I think a countdown for a new 'in vogue' webserver just started.

This is something I would've expected from a "Show HN: Embedded JS in Nginx" post, meaning it has potential to be a project done just to see what can be done, that everyone could say "Hey, that's cool" and then never use, because it's a terrible idea.

Instead, it's presented as a reasonable way of moving forward, when they could've pushed for their own much more reasonable alternative. They've done more work for a worse idea, effectively out-competing their own feature with a much more popular but crappy alternative.

Re: Launching NginScript

#126

Post by girishso »

eknkc wrote: post #32

I think it's a good addition. We have been using varnish on high traffic servers and one of the reasons was that it had "vcl", a javascript-like language to define request handling logic. (With a lot smaller feature set and more domain specific. But powerful enough). Having javascript on nginx would provide a lot of config options for people familiar with it. I believe nginx already has Lua support so not a big deal…

I agree. It will be more easier to write some custom request handling logic in Javascript.

Re: Launching NginScript

#127

Post by jws »

jnbiche wrote: post #54

I wonder why they didn't use Duktape[1]. It seems like the obvious choice for this kind of effort (e.g., if the 2 main Lua implementations have any counterpart in JS, it's probably Duktape). It's possible that Duktape was still too early in its development to use when Nginx started this project, but even then it seems like they could have collaborated and saved a lot of man hours. I wonder if there a good reason why…

I've used duktape as an extension language and wholeheartedly recommend it. It does the job and caused me zero problems. I can't ask for more than that in software.

Re: Launching NginScript

#128

Post by mkup »

Adding Javascript support to high-performance reliable web server does not seem rational from the engineering point of view.

I'd rather added support for the safe subset of some statically-typed, high performance language compiled to LLVM. This language must be without asyncronous GC, so its memory use will be predicatable under high load.

Javascript on server side is so vogue-ish. Vogue will change soon but uglyness of architectural decision will stay with Nginx forever.

Re: Launching NginScript

#129

Post by jimjag »

Yeah, I am a known Apache fanboy, and so I'm sure that what I say will be discounted. But, imo, this just shows what happens when an open source project becomes the sales initiative of an Open Core model company. Instead of the design and future being under the control and guidance of the community, it is instead in the hands of the VCs and whatever "promises" future revenue growth. Believe me, I know; I used to work at Covalent which was billed as the "Red Hat of the Apache web server" so I know how hard it is to resist the push of VCs and those nasty quarterly numbers. And Covalent wasn't the only Apache shop around, unlike nginx.com today.

The combination of FUD and marketing $$$ is being used to "encourage" more people to migrate (or use) nginx, as an "open source" alternative, when it's obvious that "open source" is being used mostly for the PR aspect and not so much for the community-focus and community-led aspects which is really core to "true" Open Source.

Post reply on HN