8 ms·

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 implem

by jshen 5y ago

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) }

valenterry 5y ago
> 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/throttletime 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.
- jshen 5y ago
  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
- jshen 5y ago
  Here you go. Took me about 15 minutes to write, using < 50 lines of code, and not using any external libraries outside of the Go Project. The 15 minutes includes the time to create the server I used to test it. https://gist.github.com/jaydonnell/4fd14c69132734aac76b7f5386161696 https://gist.github.com/jaydonnell/4fd14c69132734aac76b7f538...
  - valenterry 5y ago
    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?
    - jshen 5y ago
      I’m limiting it to 5 concurrent requests which is independent of the rate limit itself. The failing request will hold one of those 5 slots until all 3 failures are done, but won’t otherwise block anything.
      - valenterry 5y ago
        Which means the solution isn't really optimal, since if every second request fails, the code won't take full advantage of the rate limit and only do 2.5 successful requests per second.
        jshen 5y ago
        I think the requirement is a bit vague. I'm assuming an HTTP call, and that the rate limit exists on the server. Given this, there are two different error conditions: 1) the request makes it to the server, is counted against the server-side rate limit, but fails for some reason. 2) maybe the network is down, the server never sees the request, so the failure is not counted against the rate limit. I opted to assume all failures are of the first type, which means my code should also behave as expected, but will be slower when encountering failures of the second time. I'm actually curious, I think it would be easier to change my code to handle both types of errors, but I could be wrong since I don't know the scala stuff you are using that well.

by jshen 5y ago

valenterry 5y ago

> 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/throttletime 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.

jshen 5y ago
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
jshen 5y ago
Here you go. Took me about 15 minutes to write, using < 50 lines of code, and not using any external libraries outside of the Go Project. The 15 minutes includes the time to create the server I used to test it. https://gist.github.com/jaydonnell/4fd14c69132734aac76b7f5386161696 https://gist.github.com/jaydonnell/4fd14c69132734aac76b7f538...
- valenterry 5y ago
  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?
  - jshen 5y ago
    I’m limiting it to 5 concurrent requests which is independent of the rate limit itself. The failing request will hold one of those 5 slots until all 3 failures are done, but won’t otherwise block anything.
    - valenterry 5y ago
      Which means the solution isn't really optimal, since if every second request fails, the code won't take full advantage of the rate limit and only do 2.5 successful requests per second.
      - jshen 5y ago
        I think the requirement is a bit vague. I'm assuming an HTTP call, and that the rate limit exists on the server. Given this, there are two different error conditions: 1) the request makes it to the server, is counted against the server-side rate limit, but fails for some reason. 2) maybe the network is down, the server never sees the request, so the failure is not counted against the rate limit. I opted to assume all failures are of the first type, which means my code should also behave as expected, but will be slower when encountering failures of the second time. I'm actually curious, I think it would be easier to change my code to handle both types of errors, but I could be wrong since I don't know the scala stuff you are using that well.