Launching NginScript
91–100 of 131 posts
Re: Launching NginScript
#92Earlier quoted context omitted.
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.
lua compiled to asm.js is 64% of the speed of lua native https://kripken.github.io/lua.vm.js/lua.vm.js.html
That's not compiling lua to asm.js; it's running the lua vm in asm.js.
A straight up transpilation is other projects like lua.js. But you loose really nice core lua features like coroutines...
Re: Launching NginScript
#93Earlier quoted context omitted.
The usefulness of this is not to turn nginx into an application server. Although there are already frameworks for this using ngx_lua ( http://leafo.net/lapis/ ), I don't find them very interesting except for the technical aspect. The point is to make nginx's configuration dynamic and prevent bloating applications with stuff that belongs at the (lets call it) devops level. Now, I also don't think nginScript is such a…
It's funny. Any feature you don't want to use is bloat, but as soon as you need it is a necessity. The way I see it, they can either "bloat" nginx by adding scripting capabilities, or they can bloat it by covering all of the use cases that a scripting engine would otherwise enable, big and small. One simple example that I would love to use this for: generating and adding a UUIDv4 to every request's headers. Doing so…
I've had the following Lua adding request UUIDs to our logs in production for over a year. Feel free to give it a try:
Re: Launching NginScript
#94Earlier quoted context omitted.
> load balancing You'd rather use a dedicated load balancer like Route53 or haproxy. Don't think choosing Apache or Nginx is the right option for those really. Plus something like vert.x is very usable as a load balancer already. >SSL Termination Just about everything handles this already. Current best practice is to use SSL for all communication between your own servers anyway, so there's no gain. If you SSL termina…
> Current best practice is to use SSL for all communication between your own servers anyway, so there's no gain. I've never heard this. Who does this? Everyone I know of either just naively relies on the privacy of NAT-style non-routability in something like an AWS VPC, or, if they're more paranoid (or their provider has no private-networking feature, or they need HIPAA compliance, or whatever), uses IPSec—which is,…
Regarding encryption inside your network, it's a new trend since the NSA business has been going on. Google famously decrypted at the edge and the NSA demanded (and received) a backdoor into their network to ba able to see the unencrypted internal traffic. As a result, Google now encrypts at every level.
http://techcrunch.com/2014/03/20/gmail-traffic-between-googl...
Re: Launching NginScript
#95Should Greenspun's Tenth Rule be updated with a note that "they might try adding javascript before they add common lisp"?
Re: Launching NginScript
#96Earlier quoted context omitted.
I think is is sad to see anything replaced by Javascript. Unpopular opinion I guess. So many better choices out there.
I for one like seeing Javascript replaced by better Javascript.
Better javascript would be incompatible with javascript - best you can get will be "less sucking javascript". And you'll be able to use it somewhere in the far future, after four competing companies have implemented enough of it in a way that mostly works, their browsers have reached most of the internet and the brave open source community has developed the polyfills needed to fix the incompatibilities.
I'm not holding my breath. Javascript sucks, it will be everywhere and we are stuck with it.
Re: Launching NginScript
#97Earlier quoted context omitted.
Lua and JavaScript are very similar languages and share the basic problems. I'm indifferent.
I like and use both. I think Lua is a better language and I have a hard time seeing otherwise. Lua has some warts too, it's not about warts, but Lua got enough right from the beginning, is small enough to be crazy fast, and is not continually adding new large features. This is the key thing to me. JavaScript is designed by committee and has too many features in ES6.
That's a good point, Lua is smaller than JS. It does have that going for it.
Re: Launching NginScript
#98I think Nginx is open source crippleware. All the goddies are in the closed Nginxplus. Http2, load balancing with monitoring with application health checks. Do you get the source code of the closed features? Nginx already has LUA scripting support.
The HTTP/2 module of NGINX is (and has been) fully open source. https://www.nginx.com/blog/nginx-1-9-5/
Disclaimer: I work at NGINX.
Re: Launching NginScript
#99HN 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+ features fo'free.
Re: Launching NginScript
#100This 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.