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

471–480 of 481 posts

Re: Go Replaces Interface{} with 'Any'

#471

Post by jshen »

valenterry wrote: post #470
jshen wrote: post #469

Earlier quoted context omitted.

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…

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.

Re: Go Replaces Interface{} with 'Any'

#472

Post by valenterry »

jshen wrote: post #471
valenterry wrote: post #470

Earlier quoted context omitted.

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…

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.

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.

Re: Go Replaces Interface{} with 'Any'

#473

Post by valenterry »

jshen wrote: post #471
valenterry wrote: post #470

Earlier quoted context omitted.

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…

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.

I have matched this implementation, here's my approach:

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.

Re: Go Replaces Interface{} with 'Any'

#474

Post by jshen »

valenterry wrote: post #472
jshen wrote: post #471

Earlier quoted context omitted.

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.

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.

Re: Go Replaces Interface{} with 'Any'

#475

Post by jshen »

valenterry wrote: post #473
jshen wrote: post #471

Earlier quoted context omitted.

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.

I have matched this implementation, here's my approach: 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). Bu…

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?

Re: Go Replaces Interface{} with 'Any'

#476

Post by valenterry »

jshen wrote: post #475
valenterry wrote: post #473

Earlier quoted context omitted.

I have matched this implementation, here's my approach: 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). Bu…

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 s…

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.

Re: Go Replaces Interface{} with 'Any'

#477

Post by valenterry »

jshen wrote: post #474
valenterry wrote: post #472

Earlier quoted context omitted.

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…

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.

Re: Go Replaces Interface{} with 'Any'

#478

Post by jshen »

valenterry wrote: post #477
jshen wrote: post #474

Earlier quoted context omitted.

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…

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 b…

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.

Re: Go Replaces Interface{} with 'Any'

#479

Post by valenterry »

jshen wrote: post #478
valenterry wrote: post #477

Earlier quoted context omitted.

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 b…

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…

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. :)

Re: Go Replaces Interface{} with 'Any'

#480

Post by jshen »

valenterry wrote: post #479
jshen wrote: post #478

Earlier quoted context omitted.

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…

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 f…

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.
Post reply on HN