Earlier quoted context omitted.
Main strengths: * The ecosystem is pretty strong and constantly evolving. Lots of companies and individuals are putting a serious amount of work into making high-quality tooling and libraries. (Although with that also comes a lot of lower quality stuff and its sometimes hard to tell) * The language isn't owned by any single company and is well specified * TypeScript provides a powerful and flexible type system with a…
> The performance is also quite comparable to statically typed GCed languages. (For example, you can probably get to 50%-90% of Java performance on most single-threaded workloads) Citation needed, please. I disagree with this. I recently was able to achieve a massive speedup in a Node application through writing a native C++ module... and implementing Garbage Collection is required for N-API.
A 7KB AWS lambda Node.js library with zero runtime dependencies
11–20 of 63 posts
Re: A 7KB AWS lambda Node.js library with zero runtime dependencies
#12Earlier quoted context omitted.
Main strengths: * The ecosystem is pretty strong and constantly evolving. Lots of companies and individuals are putting a serious amount of work into making high-quality tooling and libraries. (Although with that also comes a lot of lower quality stuff and its sometimes hard to tell) * The language isn't owned by any single company and is well specified * TypeScript provides a powerful and flexible type system with a…
> The performance is also quite comparable to statically typed GCed languages. (For example, you can probably get to 50%-90% of Java performance on most single-threaded workloads) Citation needed, please. I disagree with this. I recently was able to achieve a massive speedup in a Node application through writing a native C++ module... and implementing Garbage Collection is required for N-API.
For those situations where the GC becomes a performance (or more likely memory usage) problem, it seems reasonable that the built-in WASM support of most engines will be able to provide an adequate performance (its already getting quite close): https://www.usenix.org/conference/atc19/presentation/jangda
Re: A 7KB AWS lambda Node.js library with zero runtime dependencies
#13Earlier quoted context omitted.
Main strengths: * The ecosystem is pretty strong and constantly evolving. Lots of companies and individuals are putting a serious amount of work into making high-quality tooling and libraries. (Although with that also comes a lot of lower quality stuff and its sometimes hard to tell) * The language isn't owned by any single company and is well specified * TypeScript provides a powerful and flexible type system with a…
> The performance is also quite comparable to statically typed GCed languages. (For example, you can probably get to 50%-90% of Java performance on most single-threaded workloads) Citation needed, please. I disagree with this. I recently was able to achieve a massive speedup in a Node application through writing a native C++ module... and implementing Garbage Collection is required for N-API.
An interesting blog post on how that might be done: https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to...
Re: A 7KB AWS lambda Node.js library with zero runtime dependencies
#14Not knowing this myself, could someone explain the attraction in using a web scripting framework for stuff like this? I get that this particular example makes the whole thing seem fairly straightforward, but have never really heard why people like adapting Node.js and similar to non-web environments beyond "you can". Is there anything more to it than that?
Main strengths: * The ecosystem is pretty strong and constantly evolving. Lots of companies and individuals are putting a serious amount of work into making high-quality tooling and libraries. (Although with that also comes a lot of lower quality stuff and its sometimes hard to tell) * The language isn't owned by any single company and is well specified * TypeScript provides a powerful and flexible type system with a…
[deleted]
Re: A 7KB AWS lambda Node.js library with zero runtime dependencies
#15Earlier quoted context omitted.
I think it's partly "you can", but surprisingly enough I also feel that node's single-threaded architecture makes code surprisingly easy to reason about.
Until you have to deal with aaync/callback/promises and mixing those to deal with various library dependencies. I would love to see JavaScript turn into a less verbose, more consistent and less golf-oriented language.
I don't really see how JS could be less verbose in its concurrency-management side.
result = somePromise() // run while the next promises are resolving
pages = await Promise.map(url, url => crawlUrl(url), {
concurrency: 4
})
allResults = await Promise.all([result, pages])
If you want verbosity, look at Go's equivalent (wait groups) or, god forbid, any concurrency management in Swift.
The only problem you run into with callbacks imo are event-emitters like streams which you need to actually understand. Though I don't think this is any more trivial in other languages with evented/callback APIs like Java and Rust, I think reasoning about event callbacks is always harder for humans but a useful construct and necessary evil in evented code.
Re: A 7KB AWS lambda Node.js library with zero runtime dependencies
#16Not knowing this myself, could someone explain the attraction in using a web scripting framework for stuff like this? I get that this particular example makes the whole thing seem fairly straightforward, but have never really heard why people like adapting Node.js and similar to non-web environments beyond "you can". Is there anything more to it than that?
IMO, Node's superpower is not really in the language but in the NPM ecosystem. If that is not attractive to you (maybe you develop the whole system by yourself, or need fine-tuned performance), Node only has to offer an ubiquous language, and that's about it.
People overlook the fact that JS is a pretty nice modern language in its own right. "Because you can" is pointlessly dismissive and indicates to me that one still thinks JS is nothing more than a language to toggle a CSS class on because they haven't used it since people used the word DHTML.
- async-everything, not a blocking language where anything async relegates you to a subecosystem like you have it in basically every other language from Java to Rust to Python.
- simple stdlib Promise that everything uses. no fragmentation between competing byob futures and byob abstractions.
- async/await.
- single-threaded making it ideal for i/o workloads, a crawler being the perfect example.
For these reasons I think it's one of the best languages. Certainly didn't used to be this way.
Re: A 7KB AWS lambda Node.js library with zero runtime dependencies
#17Not knowing this myself, could someone explain the attraction in using a web scripting framework for stuff like this? I get that this particular example makes the whole thing seem fairly straightforward, but have never really heard why people like adapting Node.js and similar to non-web environments beyond "you can". Is there anything more to it than that?
A big part of it is "because you can". I will say, that in general, and acknowledging I have a solid JS understanding, doing projects with node tends to be considerably less friction, because it's so easy to work around friction.
With npm, there are lots of options... generally if one package doesn't provide an interface I like, or performs poorly, or just has odd dependencies it shouldn't need, there's another that's probably closer to what I want. Worst case, if there's a smaller change, I fork the project on github, update to a scoped name, and publish my fork.
It's not always pretty. That said, I tend to be considerably more productive with it.
I've also worked a lot with C#, and am recently learning Rust... I feel the first version of most things should be done in a scripted language, and JS/Node is just as valid as any other option in the space.
Re: A 7KB AWS lambda Node.js library with zero runtime dependencies
#18Earlier quoted context omitted.
> The performance is also quite comparable to statically typed GCed languages. (For example, you can probably get to 50%-90% of Java performance on most single-threaded workloads) Citation needed, please. I disagree with this. I recently was able to achieve a massive speedup in a Node application through writing a native C++ module... and implementing Garbage Collection is required for N-API.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Excellent source; thanks!
It’s probably worth clarifying that Node is ⅓ the speed of Java in some of these cases and that the Node implementations use both fixed size typed arrays as well as worker threads, features that aren’t common practice in most Node programs.
Re: A 7KB AWS lambda Node.js library with zero runtime dependencies
#19Earlier quoted context omitted.
IMO, Node's superpower is not really in the language but in the NPM ecosystem. If that is not attractive to you (maybe you develop the whole system by yourself, or need fine-tuned performance), Node only has to offer an ubiquous language, and that's about it.
People overlook the fact that JS is a pretty nice modern language in its own right. "Because you can" is pointlessly dismissive and indicates to me that one still thinks JS is nothing more than a language to toggle a CSS class on because they haven't used it since people used the word DHTML. - async-everything, not a blocking language where anything async relegates you to a subecosystem like you have it in basically…
Also just the fact that JS runtimes have had a lot of hard work put into them to make them extremely fast (motivated by the fact that JS is so widely used on the web).
Re: A 7KB AWS lambda Node.js library with zero runtime dependencies
#20Not knowing this myself, could someone explain the attraction in using a web scripting framework for stuff like this? I get that this particular example makes the whole thing seem fairly straightforward, but have never really heard why people like adapting Node.js and similar to non-web environments beyond "you can". Is there anything more to it than that?
Node is especially good at handling async stuff. It’s in the JavaScript DNA. Whether through callbacks, Promises or async/await. As many backend apps are basically tying together 3rd party and 1st APIs it’s actually a very logical choice.