4 ms·

I have matched this implementation, here's my approach: https://scastie.scala-lang.org/AiusSr76QLCTrlZvBICT7A https://scastie.scala-lang.org/AiusSr76QLCTrlZvBI

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.

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.