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

Show HN: Nsynjs – JS engine with stoppable threads and without callback hell

github.com

Post reply on HN
Print view View original

21–30 of 63 posts

Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell

#21

Post by svckr »

Kiro wrote: post #14
BinaryIdiot wrote: post #7

So interesting project! I'm skeptical on the practicality of it but it's still interesting. >> global.nsynjs = global.nsynjs || require('nsynjs'); Don't do this. The module pattern is pretty well known and you can use it to return a singleton. Global has some built in node.js stuff but I wouldn't mess with it. >> Example of wrapper to setTimeout, that will be gracefully stopped in case if pseudo-thread is stopped: Th…

> The module pattern is pretty well known and you can use it to return a singleton. How would you even make it _not_ return a singleton? I thought that was default.

One way is to delete entries from `require.cache`.

Either way you might get a separate instance if npm decided that your module and another module require different version of a given module. These would both be singletons though. Just singletons of instances of different versions of the same module.

Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell

#22

Post by Jim99 »

cdata wrote: post #5
q3k wrote: post #3

Earlier quoted context omitted.

It's a kludge. Syntactic sugar to remove one level of nesting. Other languages come either with great concurrency support out of the box (Go, Erlang) or enough constructs to implement cooperative schedulers without having to specify async/await (Lua).

Not disagreeing, but as a long time JavaScripter it is remarkable to me that no matter how delightful or expressive or ergonomic the language tries to become, the same old criticisms manage to evolve with it (this may not be unique to JS). [Edit] JS has long been criticized (fairly or not) for offering clunky "concurrency" strategies. If you must down vote, please have the decency to offer a counter perspective.

As someone who has been around for a long time and manages teams using many different languages (C,C++,C#,Java,Python,JavaScript) my JavaScript/Web teams are the most problematic in terms of cost/performance/gating bugs/upgrades/multi-platform support. The JavaScript critiques that you see are just an expression of the time and resources being wasted.

Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell

#24

Post by regularfry »

amelius wrote: post #17
Neverbolt wrote: post #15

Could you please not advocate SQLinjection in your example code? > friends: dbQuery("select * from firends where user_id = "+userId).data, > comments: dbQuery("select * from comments where user_id = "+userId).data, > likes: dbQuery("select * from likes where user_id = "+userId).data I'm no js developer, but there has to be a way of using prepared statements, even if just for sample code. It's not 2001 anymore, securi…

I don't see the problem if userId is guaranteed to be just an id. This can be done, for example, by testing it before the SQL call. In that case, it's safer than most pointer-dereferences done in C++.

That's one hell of an `if` you've got there.

Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell

#28

Post by Sorreah »

regularfry wrote: post #24
amelius wrote: post #17

Earlier quoted context omitted.

I don't see the problem if userId is guaranteed to be just an id. This can be done, for example, by testing it before the SQL call. In that case, it's safer than most pointer-dereferences done in C++.

That's one hell of an `if` you've got there.

Not that big of an if. The id was most likely pulled out of the database itself in cases like:

>friends: dbQuery("select * from firends where user_id = "+userId).data

Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell

#29

Post by wwwigham »

So it stringifies the function you give it, splits it into its component bits of execution, then interprets the contents alongside a state machine (with judicious use of bits concatenated together and eval'd). Interesting, for sure. AFAIK there's no preemption mechanism (or resource management), so all it does is make your code execute asynchronously - very asynchronously - the every-line-interwoven-randomly kind of asynchronously.

I do love me some metaprogramming, but is there a real scenario where you'd want something as dangerous as this compared to a generator (or a system of generators)? They have very clear atomicity guarantees (things between yields will happen synchronously), unlike what this ends up decomposing your code into. I suppose that's just the cooperative vs supervised threading debate, though?

Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell

#30

Post by Klathmon »

Sorreah wrote: post #28
regularfry wrote: post #24

Earlier quoted context omitted.

That's one hell of an `if` you've got there.

Not that big of an if. The id was most likely pulled out of the database itself in cases like: >friends: dbQuery("select * from firends where user_id = "+userId).data

or it was pulled from a GET parameter.

The point is that regardless of where it came from parameterized queries are a staple of programming now, and having an example without it would be like having an example of a login system be

    if (username in db && password in db) { login() }
Post reply on HN