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

Go Replaces Interface{} with 'Any'

github.com

Post reply on HN
Print view View original

461–470 of 481 posts

Re: Go Replaces Interface{} with 'Any'

#461

Post by valenterry »

jshen wrote: post #460
valenterry wrote: post #402

Earlier quoted context omitted.

It's far easier for you . It definitely isn't for me or in general . Thank you for answering the list of languages though. Makes me wonder what the concrete points are for, since I really have a different opinion. Maybe our minds just work very different; :)

Just ran into a great example today. Was using typescript/javascript to hit an api that has a limit of 5 requests per second. One of these fails saying that it's making more than 5 requests per second, the other doesn't, is it obvious why? It took me several hours to figure it out, wouldn't have had this problem in go. choices.forEach(async (ce) => { let ce = choices[index] Deno.sleepSync(220); let cf = await getChoi…

Good example, because that's exactly what I don't want to see when I read code.

This should really be:

    streamOf(choices)
      .mapAsync(ce => getChoice(ce))
      .throttle(5, 1.second)
This is such a common use-case, it should really be in the streaming-library of choice. It's also a good example of how more abstract code is often better and has less edge-cases. In this example, of you have 4 choices, then these can send all at once without delay. This will be much faster compared to the code you posted, which will wait after each request, even though the rate-limit is not applied.

Apart from that, I don't think the second example is complete, where does ce come from here? And also, I don't know Deno, but calling "sleepSync" already looks like a bad idea to me, no matter where it's used - especially since calling a sync operation within an async doesn't make much sense.

Re: Go Replaces Interface{} with 'Any'

#462

Post by lucacasonato »

valenterry wrote: post #461
jshen wrote: post #460

Earlier quoted context omitted.

Just ran into a great example today. Was using typescript/javascript to hit an api that has a limit of 5 requests per second. One of these fails saying that it's making more than 5 requests per second, the other doesn't, is it obvious why? It took me several hours to figure it out, wouldn't have had this problem in go. choices.forEach(async (ce) => { let ce = choices[index] Deno.sleepSync(220); let cf = await getChoi…

Good example, because that's exactly what I don't want to see when I read code. This should really be: streamOf(choices) .mapAsync(ce => getChoice(ce)) .throttle(5, 1.second) This is such a common use-case, it should really be in the streaming-library of choice. It's also a good example of how more abstract code is often better and has less edge-cases. In this example, of you have 4 choices, then these can send all a…

Yeah, this should not be calling `Deno.sleepSync`... this should be an `await new Promise(resolve => setTimeout(resolve, 220));`.

Re: Go Replaces Interface{} with 'Any'

#463

Post by jshen »

valenterry wrote: post #461
jshen wrote: post #460

Earlier quoted context omitted.

Just ran into a great example today. Was using typescript/javascript to hit an api that has a limit of 5 requests per second. One of these fails saying that it's making more than 5 requests per second, the other doesn't, is it obvious why? It took me several hours to figure it out, wouldn't have had this problem in go. choices.forEach(async (ce) => { let ce = choices[index] Deno.sleepSync(220); let cf = await getChoi…

Good example, because that's exactly what I don't want to see when I read code. This should really be: streamOf(choices) .mapAsync(ce => getChoice(ce)) .throttle(5, 1.second) This is such a common use-case, it should really be in the streaming-library of choice. It's also a good example of how more abstract code is often better and has less edge-cases. In this example, of you have 4 choices, then these can send all a…

I messed up my copy/paste, the 'let ce' line in the first example should be in the second example.

Regarding your example, where is this throttle method implemented in javascript? And, your code is not easier to reason about for me than the synchronous golang code. It's not clear how throttle is affecting the function call that happens before it. Compare to this.

    for _, v := range choices {
      getChoice(v)
      time.Sleep(200)
    }

Re: Go Replaces Interface{} with 'Any'

#464

Post by [deleted] »

lucacasonato wrote: post #462
valenterry wrote: post #461

Earlier quoted context omitted.

Good example, because that's exactly what I don't want to see when I read code. This should really be: streamOf(choices) .mapAsync(ce => getChoice(ce)) .throttle(5, 1.second) This is such a common use-case, it should really be in the streaming-library of choice. It's also a good example of how more abstract code is often better and has less edge-cases. In this example, of you have 4 choices, then these can send all a…

Yeah, this should not be calling `Deno.sleepSync`... this should be an `await new Promise(resolve => setTimeout(resolve, 220));`.

[deleted]

Re: Go Replaces Interface{} with 'Any'

#465

Post by jshen »

lucacasonato wrote: post #462
valenterry wrote: post #461

Earlier quoted context omitted.

Good example, because that's exactly what I don't want to see when I read code. This should really be: streamOf(choices) .mapAsync(ce => getChoice(ce)) .throttle(5, 1.second) This is such a common use-case, it should really be in the streaming-library of choice. It's also a good example of how more abstract code is often better and has less edge-cases. In this example, of you have 4 choices, then these can send all a…

Yeah, this should not be calling `Deno.sleepSync`... this should be an `await new Promise(resolve => setTimeout(resolve, 220));`.

That's kind of my point, it's less obvious how to do basic things in js/ts than golang.

What's the vanilla way in ts/js to do the equivalent of this golang code where getChoice makes an HTTP call and can't make more than 5 per second?

    for _, v := range choices {
      getChoice(v)
      time.Sleep(200)
    }
Also, why doesn't Deno.sleepSync work as I expect here?

Re: Go Replaces Interface{} with 'Any'

#466

Post by valenterry »

jshen wrote: post #463
valenterry wrote: post #461

Earlier quoted context omitted.

Good example, because that's exactly what I don't want to see when I read code. This should really be: streamOf(choices) .mapAsync(ce => getChoice(ce)) .throttle(5, 1.second) This is such a common use-case, it should really be in the streaming-library of choice. It's also a good example of how more abstract code is often better and has less edge-cases. In this example, of you have 4 choices, then these can send all a…

I messed up my copy/paste, the 'let ce' line in the first example should be in the second example. Regarding your example, where is this throttle method implemented in javascript? And, your code is not easier to reason about for me than the synchronous golang code. It's not clear how throttle is affecting the function call that happens before it. Compare to this. for _, v := range choices { getChoice(v) time.Sleep(20…

> Regarding your example, where is this throttle method implemented in javascript

I didn't say it is. I said it should be. But here is a similar functionality that I just googled: https://www.learnrxjs.io/learn-rxjs/operators/filtering/thro...

I'm neither a javascript pro, nor a fan of this language. There are probably better solutions out there.

> And, your code is not easier to reason about for me than the synchronous golang code

I never said it is. If you would be familiar with only assembler, then assembly code would most easy to read. And you need to spend some time upfront to learn other languages/techniques that can make certain problems easier.

So here's the thing. Let's change the idea of this code a little bit and make it a challenge.

Let's say we want to improve the code:

1. Improve performance by sending requests as quickly as possible while respecting the rate limit. I.e. if we have 3 requests, send them all at once. If we have 7 requests, then they should all be sent after 1 second has finished.

2. If a request fails, we retry it up to 3 times and don't count it towards the api rate limit

3. If all retries for a request fail, we just skip it and continue with the rest.

I think this is a very practical real world example. I'm curious how elegant this can be solved in Go. I will also solve it and post my online-runnable solution afterwards. :-)

And then we reevaluate which solution is easier to read.

Re: Go Replaces Interface{} with 'Any'

#467

Post by jshen »

valenterry wrote: post #466
jshen wrote: post #463

Earlier quoted context omitted.

I messed up my copy/paste, the 'let ce' line in the first example should be in the second example. Regarding your example, where is this throttle method implemented in javascript? And, your code is not easier to reason about for me than the synchronous golang code. It's not clear how throttle is affecting the function call that happens before it. Compare to this. for _, v := range choices { getChoice(v) time.Sleep(20…

> Regarding your example, where is this throttle method implemented in javascript I didn't say it is. I said it should be. But here is a similar functionality that I just googled: https://www.learnrxjs.io/learn-rxjs/operators/filtering/thro... I'm neither a javascript pro, nor a fan of this language. There are probably better solutions out there. > And, your code is not easier to reason about for me than the synchron…

I'd love to, will code my go version after xmas. Feel free to shoot me an email, hn isn't great for long running conversations. jay.donnell@hey.com

Re: Go Replaces Interface{} with 'Any'

#468

Post by [deleted] »

lucacasonato wrote: post #462
valenterry wrote: post #461

Earlier quoted context omitted.

Good example, because that's exactly what I don't want to see when I read code. This should really be: streamOf(choices) .mapAsync(ce => getChoice(ce)) .throttle(5, 1.second) This is such a common use-case, it should really be in the streaming-library of choice. It's also a good example of how more abstract code is often better and has less edge-cases. In this example, of you have 4 choices, then these can send all a…

Yeah, this should not be calling `Deno.sleepSync`... this should be an `await new Promise(resolve => setTimeout(resolve, 220));`.

[deleted]

Re: Go Replaces Interface{} with 'Any'

#469

Post by jshen »

valenterry wrote: post #466
jshen wrote: post #463

Earlier quoted context omitted.

I messed up my copy/paste, the 'let ce' line in the first example should be in the second example. Regarding your example, where is this throttle method implemented in javascript? And, your code is not easier to reason about for me than the synchronous golang code. It's not clear how throttle is affecting the function call that happens before it. Compare to this. for _, v := range choices { getChoice(v) time.Sleep(20…

> Regarding your example, where is this throttle method implemented in javascript I didn't say it is. I said it should be. But here is a similar functionality that I just googled: https://www.learnrxjs.io/learn-rxjs/operators/filtering/thro... I'm neither a javascript pro, nor a fan of this language. There are probably better solutions out there. > And, your code is not easier to reason about for me than the synchron…

Here you go. Took me about 15 minutes to write, using https://gist.github.com/jaydonnell/4fd14c69132734aac76b7f538...

Re: Go Replaces Interface{} with 'Any'

#470

Post by valenterry »

jshen wrote: post #469
valenterry wrote: post #466

Earlier quoted context omitted.

> Regarding your example, where is this throttle method implemented in javascript I didn't say it is. I said it should be. But here is a similar functionality that I just googled: https://www.learnrxjs.io/learn-rxjs/operators/filtering/thro... I'm neither a javascript pro, nor a fan of this language. There are probably better solutions out there. > And, your code is not easier to reason about for me than the synchron…

Here you go. Took me about 15 minutes to write, using https://gist.github.com/jaydonnell/4fd14c69132734aac76b7f538...

Very cool! I'll let my solution follow soon.

Immediate question that I have (since I can't execute it easily):

What happens if we have 11 requests, each request takes 1 second to be responded to, but one of the first 5 requests fails 3 times and each time the reponse until failure takes 0.1 seconds.

Will all 10 successful requests be completed within 2 seconds then? Or will the failing request block the 11th requests for 0.3 seconds, meaning that all 10 successful requests will only be completed within 2.3 seconds?

Post reply on HN