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

Greenlet – Move an async function into its own thread in the browser

github.com

Post reply on HN
Print view View original

41–46 of 46 posts

Re: Greenlet – Move an async function into its own thread in the browser

#41

Post by seangrogg »

yeukhon wrote: post #40
blurspline wrote: post #21

Earlier quoted context omitted.

after the web worker executes its function, it post a message to the original context with 3 arguments - the call id (c), error string(e), the successful result object(d). the greenlet function when invoked returns a promise waiting to be resolved or rejected. the resolver and rejector functions are stored in object p with the key with a unique call id. so line 18 `p[c][e?1:0](e||d);` basically means resolve or rejec…

Wow! Nice! Thank you!! WOW! I haven't touched Javascript for a long time, especially using shiny features in ES5, ES6... those arrows always throws me off. Is this a typical JS & NodeJS style nowadays? Does anyone ever feel your code and your co-workers' code are barely readable? Disclaimer: Python programmer.

Not the parent, but I find function vs fat arrow to be similar to:

* def vs lambda in Python

* fn vs closures in Rust

* def vs anonymous functions in Elixir

Honestly, given how often I find myself using small, immediately-consumed functions when performing common filter/map/reduce operations I find fat arrows to be an extremely welcome addition. I feel that it spares a lot of excessive "function" keywords everywhere and gives you just a little more room to have more verbose variable names when you have to deal with things like enforced maximum line lengths...

Re: Greenlet – Move an async function into its own thread in the browser

#42

Post by jrochkind1 »

vog wrote: post #16
Klathmon wrote: post #5

This is off-topic, but at the top of the readme is this: > The name is somewhat of a poor choice, but it was available on npm. npm has supported scoped packages [0] for years now, and it's a fantastic solution to this problem, as well as solving many others (like typosquatting in many cases). I know this package is already named, but I really urge people to use scoped packages more. [0] https://docs.npmjs.com/misc/sc…

Why not making scopes mandatory, to fix these issues once and for all? Wait, that's what GitHub did for 10 years ...

On github, if I expect an open source thing to get some use, I usually put it in an 'organization', instead of my personal github account. To allow it to later be transitioned to a team, or another maintainer, without disruption.

If one does the same on npm, it just transfers the namespace scarcity to 'scopes' themselves, with no real benefit.

Re: Greenlet – Move an async function into its own thread in the browser

#43

Post by dang »

rattray wrote: post #33

@dang, can the title be modified to include the programming language/environment? (browser-only JS)

Sure.

Btw it's better to email us (hn@ycombinator.com) than to try to get our attention this way, since we don't come close to seeing all the comments, or even all the threads.

Re: Greenlet – Move an async function into its own thread in the browser

#44

Post by jaquers »

yeukhon wrote: post #40
blurspline wrote: post #21

Earlier quoted context omitted.

after the web worker executes its function, it post a message to the original context with 3 arguments - the call id (c), error string(e), the successful result object(d). the greenlet function when invoked returns a promise waiting to be resolved or rejected. the resolver and rejector functions are stored in object p with the key with a unique call id. so line 18 `p[c][e?1:0](e||d);` basically means resolve or rejec…

Wow! Nice! Thank you!! WOW! I haven't touched Javascript for a long time, especially using shiny features in ES5, ES6... those arrows always throws me off. Is this a typical JS & NodeJS style nowadays? Does anyone ever feel your code and your co-workers' code are barely readable? Disclaimer: Python programmer.

I write JavaScript/Node everyday. In my experience one does not write code like this when working with a team or a project that will be handed off; the author(s) are trying to minimize file size with expressions that are as small as possible. This seems okay to me for a library where your API is simply a function wrapper.

Re: Greenlet – Move an async function into its own thread in the browser

#45

Post by rattray »

dang wrote: post #43
rattray wrote: post #33

@dang, can the title be modified to include the programming language/environment? (browser-only JS)

Sure. Btw it's better to email us (hn@ycombinator.com) than to try to get our attention this way, since we don't come close to seeing all the comments, or even all the threads.

Oh cool, gtk! Today I learned.

Re: Greenlet – Move an async function into its own thread in the browser

#46

Post by vog »

Klathmon wrote: post #28
DanHulton wrote: post #27

Earlier quoted context omitted.

All new packages must be scoped. Existing packages can - and shoudl - be aliased by the owner to a scoped package. Everyone's existing code continues to work, while all new code is safe. Doesn't seem especially tricky.

I agree, but I'm just guessing. I have a feeling that if there weren't any downsides, it would have been done by now.

My feeling ist that the downside basically boils down to: Lots of work, and having to find volunteers implementing that.
Post reply on HN