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.
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.
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?
> 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.
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.
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.
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.
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.
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. :)
Thanks for the great convo, really enjoyed it. I have been on a project with good devs, wrote a large scale web crawler in clojure for a famous research lab. These days I’m responsible for hiring/training/retaining hundreds of devs across many code bases, some dating back decades. It gives you a whole different perspective. Also, I don’t get to code all day anymore, but I still love to code, so squeeze it in on fun hobby projects. This also gives one a whole different perspective about what is important, and what is really worth keeping in one’s head.
