Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
dvlsg
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
30 ms
·
301.
▲
by
dvlsg
10y ago
Yeah, the phrase "button mashing" is fairly common in gaming.
302.
▲
by
dvlsg
10y ago
I think the gist of it / watered down version is that you would be able to compile / run a good amount / most Linux (ubuntu) applications natively-ish in Windows. For example, I read a blog where someone pulled down the redi
303.
▲
by
dvlsg
10y ago
Do they still have the colored lines towards the top? I think you have to click on it to see the language percentage breakdown.
304.
▲
by
dvlsg
10y ago
It's good for legitimate customers.
305.
▲
by
dvlsg
10y ago
I do hope they gain some more traction. I've found them to be very useful with reducing boilerplate / repetitive code.
306.
▲
by
dvlsg
10y ago
Even when implemented in a readable way, callbacks can still become hard to maintain. When you use properly separate functions (instead of anonymous ones), you typically have to embed those methods inside one another. I'll take an exam
307.
▲
by
dvlsg
10y ago
That's not true. You could return (either the promise being used or a directly awaited value) and that value would be made available through await / promise as well.
308.
▲
by
dvlsg
10y ago
I think it's nice to have both options. I prefer the functional style of chaining promises for the most part, but there are definitely a few times when await is easier to use IMO (awaiting inside of a loop, for example).
309.
▲
by
dvlsg
10y ago
Closures aside, a somewhat significant difference between the two is that the generator would yield each value in the sequence, whereas yours would just return a single value from the sequence. Which might be perfect, depending on the use c
310.
▲
by
dvlsg
10y ago
Sometimes it's really useful to kick off an async function as well, do some other work in the meantime that doesn't require that async function to be done, then await the promise from the async method later on when you do need it
311.
▲
by
dvlsg
10y ago
No, you're right. That was a mistake on my part. The .map() should be called on the array, as calebegg pointed out.
312.
▲
by
dvlsg
10y ago
Oh you're right of course. My mistake.
313.
▲
by
dvlsg
10y ago
Yup. Promise.all() returns a new Promise which settles after every Promise in the provided array has settled (or throws after one of the provided Promises throws).
314.
▲
by
dvlsg
10y ago
Yes. They will be sent into map immediately, and Promise.all() will return a Promise which will settle when the mapped array is all settled (or one errors, but that's not really relevant to the question). We're really just awaitin
315.
▲
by
dvlsg
10y ago
Just to be picky, but I believe you would be better off with this: async function main () { try { const jsons = await Promise.all([ fetch('https://api.github.com/orgs/facebook'),
316.
▲
by
dvlsg
10y ago
You probably can, but you may as well just do this instead: const json = await fetch('https://api.github.com/orgs/facebook').then(res => res.json());
317.
▲
by
dvlsg
11y ago
Interesting. Javascript is actually adding something very similar, calling it destructuring. It's actually quite handy - although admittedly more handy for destructuring object arguments than array arguments.
318.
▲
by
dvlsg
11y ago
I've had mine for over a year now, and I've only had to reboot it 3 times - 4 if you count the time I unplugged it and moved to a new city.
319.
▲
by
dvlsg
11y ago
I would if I got Google fiber speeds. For this, though? Probably not.
320.
▲
by
dvlsg
11y ago
Yeah... That's not something I would enjoy working with. It's a nice idea, I'll add my hopes that some of the boilerplate will get removed, but I can't see myself working with this on a production app any time soon.