5 ms·

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 include

by 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.
      - valenterry 5y ago
        Yeah, I guess I could have been a bit more clear. In the end it's fine, I just wanted to make it a bit more interesting and any additional constraint would have worked :) The reason that the Scala code is so much shorter is because streams compose really well and a lot of common building blocks (such as the throttling) can be provided. This effect gets more important when the code base is growing. Also, when things become more complicated, loops like the one you wrote tend to become very complicated. At least that has been my experience. It's fun to write it, but not so much to read or maintain it.
        jshen 5y ago
        My experience has been the opposite. If I jump into a random Go code base, it’s been easier to figure out what’s going on than with languages that provide a lot more abstraction power. The reason, IMO, is that a bad abstraction is worse than less abstraction, and people are more likely to create bad abstractions than they are good ones. I think it’s better with functional languages like scala and clojure, because bad class hierarchies with inheritance are the worst abstractions, but Go hits the right balance for me and I think for large organizations that have a lot of devs who move on and off of code bases on a regular basis. I agree that you can get a better result with powerful languages, but that it’s unlikely in large orgs. I think software engineering at scale is more about sociology than people admit or realize.
        valenterry 5y ago
        I think I might agree when it comes to Java developers creating crazy class-hierarchies with no meaning. To me that is pretty much as bad as a desert of for-loops and low-level code, maybe even worse. I'm praying for you that you at some point end up in a project with a bunch of good developers that work on a code base with a lot of good and high abstraction. The pleasure to improve your own skills in this area and feeling your productiviy rise is worth the pain of learning things to get there. It will be difficult to find this in bigger companies though. > I think software engineering at scale is more about sociology than people admit or realize. Yes, but it's only a matter of time. Software engineering is a growing and young field. There will be a time when we laugh about the bad code that was written, without standards and training. This time is not yet, but I'm looking forward to it. :)
  - valenterry 5y ago
    I have matched this implementation, here's my approach: https://scastie.scala-lang.org/AiusSr76QLCTrlZvBICT7A https://scastie.scala-lang.org/AiusSr76QLCTrlZvBICT7A 13 lines and should behave like yours (i.e. is not optimal in the sense of fully utilizing the rate limit). Curious to see your solution that fully utilizes the rate limit - it's not so trivial I think. :) Anyways. I have to say that the Go-code is better than I expected (even for the suboptimal solution). But given my experience with higher abstractions (here streaming) I personally find the streaming solution much more readible.
    - jshen 5y ago
      Thanks, this was a fun experiment. I was curious to see what language you used. I've done a bit of scala many years ago, and I have to say that I HATED other peoples weird and often over complex scala code. I think this is the main difference in our point of view. I 100% agree that you can write better abstractions with a language like Scala, but you can also shoot yourself in the foot far far easier. If you have a small team of very talented devs, something like scala can be amazing. At a large company, with thousands of developers of varying levels, I find you get worse results with something like scala relative to Go. I also think that a dev who just graduated college would be able to jump into my code and work on it fairly easily. I think they'd need a lot of extra training/learning to understand yours. One question about yours, is it using a separate OS thread for each HTTP call, or some kind of async io?
      - valenterry 5y ago
        You are very right and > I also think that a dev who just graduated college would be able to jump into my code and work on it fairly easily. I think they'd need a lot of extra training/learning to understand yours. this nails it. It's also what Go was designed for. People just shouldn't make the mistake to assume that this means would also be easier to understand a whole code base. It's not, it takes longer, since there will be so much more code. We pay the long upfront costs to learn our languages and tooling for the same reason we sent people to school for years: in the end it pays off. > One question about yours, is it using a separate OS thread for each HTTP call, or some kind of async io? Just like Go it uses "green threads" and will work and run requests in parallel even when just having one thread and/or cpu core.

by jshen 5y ago

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.
    - valenterry 5y ago
      Yeah, I guess I could have been a bit more clear. In the end it's fine, I just wanted to make it a bit more interesting and any additional constraint would have worked :) The reason that the Scala code is so much shorter is because streams compose really well and a lot of common building blocks (such as the throttling) can be provided. This effect gets more important when the code base is growing. Also, when things become more complicated, loops like the one you wrote tend to become very complicated. At least that has been my experience. It's fun to write it, but not so much to read or maintain it.
      - jshen 5y ago
        My experience has been the opposite. If I jump into a random Go code base, it’s been easier to figure out what’s going on than with languages that provide a lot more abstraction power. The reason, IMO, is that a bad abstraction is worse than less abstraction, and people are more likely to create bad abstractions than they are good ones. I think it’s better with functional languages like scala and clojure, because bad class hierarchies with inheritance are the worst abstractions, but Go hits the right balance for me and I think for large organizations that have a lot of devs who move on and off of code bases on a regular basis. I agree that you can get a better result with powerful languages, but that it’s unlikely in large orgs. I think software engineering at scale is more about sociology than people admit or realize.
        valenterry 5y ago
        I think I might agree when it comes to Java developers creating crazy class-hierarchies with no meaning. To me that is pretty much as bad as a desert of for-loops and low-level code, maybe even worse. I'm praying for you that you at some point end up in a project with a bunch of good developers that work on a code base with a lot of good and high abstraction. The pleasure to improve your own skills in this area and feeling your productiviy rise is worth the pain of learning things to get there. It will be difficult to find this in bigger companies though. > I think software engineering at scale is more about sociology than people admit or realize. Yes, but it's only a matter of time. Software engineering is a growing and young field. There will be a time when we laugh about the bad code that was written, without standards and training. This time is not yet, but I'm looking forward to it. :)
- valenterry 5y ago
  I have matched this implementation, here's my approach: https://scastie.scala-lang.org/AiusSr76QLCTrlZvBICT7A https://scastie.scala-lang.org/AiusSr76QLCTrlZvBICT7A 13 lines and should behave like yours (i.e. is not optimal in the sense of fully utilizing the rate limit). Curious to see your solution that fully utilizes the rate limit - it's not so trivial I think. :) Anyways. I have to say that the Go-code is better than I expected (even for the suboptimal solution). But given my experience with higher abstractions (here streaming) I personally find the streaming solution much more readible.
  - jshen 5y ago
    Thanks, this was a fun experiment. I was curious to see what language you used. I've done a bit of scala many years ago, and I have to say that I HATED other peoples weird and often over complex scala code. I think this is the main difference in our point of view. I 100% agree that you can write better abstractions with a language like Scala, but you can also shoot yourself in the foot far far easier. If you have a small team of very talented devs, something like scala can be amazing. At a large company, with thousands of developers of varying levels, I find you get worse results with something like scala relative to Go. I also think that a dev who just graduated college would be able to jump into my code and work on it fairly easily. I think they'd need a lot of extra training/learning to understand yours. One question about yours, is it using a separate OS thread for each HTTP call, or some kind of async io?
    - valenterry 5y ago
      You are very right and > I also think that a dev who just graduated college would be able to jump into my code and work on it fairly easily. I think they'd need a lot of extra training/learning to understand yours. this nails it. It's also what Go was designed for. People just shouldn't make the mistake to assume that this means would also be easier to understand a whole code base. It's not, it takes longer, since there will be so much more code. We pay the long upfront costs to learn our languages and tooling for the same reason we sent people to school for years: in the end it pays off. > One question about yours, is it using a separate OS thread for each HTTP call, or some kind of async io? Just like Go it uses "green threads" and will work and run requests in parallel even when just having one thread and/or cpu core.