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

51–60 of 63 posts

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

#51

Post by cdata »

Jim99 wrote: post #22
cdata wrote: post #5

Earlier quoted context omitted.

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.

Where in the stack did you spend your time before you became a manager?

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

#53

Post by z3t4 »

sametmax wrote: post #50
z3t4 wrote: post #42

Earlier quoted context omitted.

embrace higher-order functions. Use named functions and closures! example code: var anchors = document.getElementsByTagName(“a”); for(var i=0,len=anchors.length; i

This makes anything but basic life cycles very hard to read.

You can look at each function at a time and only have to understand what that function does. No more nesting.

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

#54

Post by BoorishBears »

BinaryIdiot wrote: post #10
modarts wrote: post #2

What's wrong with async/await?

While I don't use async / await right now, mostly because it's not natively available in all of the target browsers I want to use, I'm not the biggest fan of the pattern. It takes previously asynchronous functions and makes them appear as synchronous. The worst part is with some asynchronous methods you can't use async / await so now you have synchronous and asynchronous code that appears identical while also having…

It's funny watching part of the history of C# replay itself in Js, I heard the same arguments when it was playing out in C# (TPL => Promises, await/async => await/async)

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

#55

Post by vbezhenar »

I'm using ES6 async/await and I can't be happier, async programming is almost sane now. The only drawback is that you have to remember that it's all syntax sugar about Promises and they are just a bit more than syntax sugar about callbacks, so you have to understand how each async thing works or you'll be mad. But when you know those things, you can be asynchronously productive.

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

#56

Post by camus2 »

kidstrack wrote: post #6
modarts wrote: post #2

What's wrong with async/await?

2 main reasons: 1. If some nested function is async/await, all the callers (and whole graph) need to be converted to async/await. I feel that language shouldn't force programmer to do this type of tedious work. 2. It's not compatible with some browsers, only via Babel

> If some nested function is async/await, all the callers (and whole graph) need to be converted to async/await

Is totally false. You can await on any promise, the method called doesn't have to be an async function.

And you can resolve any async function through promises as well.

> 2. It's not compatible with some browsers, only via Babel

async/await is part of the the ES spec, which browsers have to follow to be compliant with ES spec.

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

#57

Post by Klathmon »

josephg wrote: post #37
Klathmon wrote: post #35

Earlier quoted context omitted.

I think the disconnect here is that a prepared statement isn't really more complicated. As pseudocode it's more like dbquery('select * from friends where user_id = $1', userId) A few extra characters is all it takes. And the benefits of prepared or parameterized statements don't end at security, they can often have performance benefits as well. And as for the login pseudocode, if it doesn't have anything to do with t…

I've been enjoying sql-template-strings lately, which build on ES6 tagged template literals so you get the best of both worlds: dbquery(sql`select * from friends where user_id = ${userId}`) https://www.npmjs.com/package/sql-template-strings

(not sure why you are getting downvoted, but...)

Template strings are the one ES2015 feature I still really haven't used much. And this almost seems like a textbook use case for them! I'll need to give this a shot in a toy project and see if I can't get my own version hacked together for support with my favorite database interface library in node (pg-promise)

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

#58

Post by camus2 »

badminton1 wrote: post #48
pygy_ wrote: post #27

Earlier quoted context omitted.

Green threads are threads too (a.k.a. cooperative threads/coroutines).

It is my understanding they would always execute on the same core.

> It is my understanding they would always execute on the same core.

no they don't, Go has green threads and they are fully parallel. They are called green because they are not scheduled by the operating system.

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

#59

Post by [deleted] »

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.

[deleted]

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

#60

Post by antonb9 »

BoorishBears wrote: post #54
BinaryIdiot wrote: post #10

Earlier quoted context omitted.

While I don't use async / await right now, mostly because it's not natively available in all of the target browsers I want to use, I'm not the biggest fan of the pattern. It takes previously asynchronous functions and makes them appear as synchronous. The worst part is with some asynchronous methods you can't use async / await so now you have synchronous and asynchronous code that appears identical while also having…

It's funny watching part of the history of C# replay itself in Js, I heard the same arguments when it was playing out in C# (TPL => Promises, await/async => await/async)

I really enjoy the TPL library. blocking queue etc makes it pretty damn easy to understand, what could be complex code.
Post reply on HN