4 ms·

I’ve used all those languages. It’s far easier to make sense of a non trivial go code base I’ve never seen before than any of those.

by jshen 5y ago

valenterry 5y ago
It's far easier for you. It definitely isn't for me or in general. Thank you for answering the list of languages though. Makes me wonder what the concrete points are for, since I really have a different opinion. Maybe our minds just work very different; :)
- jshen 5y ago
  Just ran into a great example today. Was using typescript/javascript to hit an api that has a limit of 5 requests per second. One of these fails saying that it's making more than 5 requests per second, the other doesn't, is it obvious why? It took me several hours to figure it out, wouldn't have had this problem in go. choices.forEach(async (ce) => { let ce = choices[index] Deno.sleepSync(220); let cf = await getChoice(ce); // this makes the API call Deno.sleepSync(220); }); for (index = 0; index < choices.length; index++) { Deno.sleepSync(220); let cf = await getChoice(ce); // this makes the API call Deno.sleepSync(220); }
  - valenterry 5y ago
    Good example, because that's exactly what I don't want to see when I read code. This should really be: streamOf(choices) .mapAsync(ce => getChoice(ce)) .throttle(5, 1.second) This is such a common use-case, it should really be in the streaming-library of choice. It's also a good example of how more abstract code is often better and has less edge-cases. In this example, of you have 4 choices, then these can send all at once without delay. This will be much faster compared to the code you posted, which will wait after each request, even though the rate-limit is not applied. Apart from that, I don't think the second example is complete, where does ce come from here? And also, I don't know Deno, but calling "sleepSync" already looks like a bad idea to me, no matter where it's used - especially since calling a sync operation within an async doesn't make much sense.
    - lucacasonato 5y ago
      Yeah, this should not be calling `Deno.sleepSync`... this should be an `await new Promise(resolve => setTimeout(resolve, 220));`.
      - deleted 5y ago
        [deleted]
      - jshen 5y ago
        That's kind of my point, it's less obvious how to do basic things in js/ts than golang. What's the vanilla way in ts/js to do the equivalent of this golang code where getChoice makes an HTTP call and can't make more than 5 per second? for _, v := range choices { getChoice(v) time.Sleep(200) } Also, why doesn't Deno.sleepSync work as I expect here?
      - deleted 5y ago
        [deleted]
    - 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 would probably require a book length post to truly answer this, but here's the best short version I can do. I think it comes down to a few things. 1. Some languages on your list are very flexible, and that allows them to be written in a very readable form with great discipline. People tend to not have great discipline thought, for various reasons: their bosses are pushing them to go faster and cut corners, they aren't experienced enough yet, etc. I'd say that python and typescript/javascript fall into this category. 2. I think inheritance is the devil, and a more functional style is better (by functional I mean first class functions, passing parameters, etc not purely typed). Java/Groovy fall into this category, they overuse inheritance and things like dependency injection with xml or annotations rather than far easier to read function calls with parameters. 3. Then there is haskell :) Haskell requires a phd in rocket science to be proficient, and most people have other things they want to do with their life. You also can't hire a team of 1000 rocket scientists so most companies can't go this route. Edit: One other thing I'll add about typescript/javascipt because it's a bit of an oddball. There really isn't a typescript/javascript style because most devs end up writing javascript. The java people try to write java in it, the python people python, etc. This alone makes it hard to jump into a random JS/TS codebase and figure out what's going on. Regarding Go, it takes away a lot of flexibility, which makes the code longer generally, but it makes it much more consistent across code bases. It's lack of inheritance prevents the devil from showing up, and it's largely a simple function call with parameter passing style all the way through the code base. Structural typing is also a godsend. Edit 2: Also, package management in python is a complete train wreck.
- mariusor 5y ago
  From the list of languages you mentioned I understand that you probably enjoy ways to express algorithms in an elegant and (maybe) terse way. Maybe that's easier for you to understand. However all that abstraction is very far removed from what the compiler or the interpreter actually execute on the CPU. For me an easy to understand program is one where the way memory is structured and the way execution modifies said memory is easy to follow. That's why Go, despite being very verbose in some cases, it's easier to reason about, than codebases doing similar things in higher level programming languages.

I’ve used all those languages. It’s far easier to make sense of a non trivial go code base I’ve never seen before than any of those.

by jshen 5y ago

I’ve used all those languages. It’s far easier to make sense of a non trivial go code base I’ve never seen before than any of those.

valenterry 5y ago

It's far easier for you. It definitely isn't for me or in general. Thank you for answering the list of languages though. Makes me wonder what the concrete points are for, since I really have a different opinion. Maybe our minds just work very different; :)

jshen 5y ago
Just ran into a great example today. Was using typescript/javascript to hit an api that has a limit of 5 requests per second. One of these fails saying that it's making more than 5 requests per second, the other doesn't, is it obvious why? It took me several hours to figure it out, wouldn't have had this problem in go. choices.forEach(async (ce) => { let ce = choices[index] Deno.sleepSync(220); let cf = await getChoice(ce); // this makes the API call Deno.sleepSync(220); }); for (index = 0; index < choices.length; index++) { Deno.sleepSync(220); let cf = await getChoice(ce); // this makes the API call Deno.sleepSync(220); }
- valenterry 5y ago
  Good example, because that's exactly what I don't want to see when I read code. This should really be: streamOf(choices) .mapAsync(ce => getChoice(ce)) .throttle(5, 1.second) This is such a common use-case, it should really be in the streaming-library of choice. It's also a good example of how more abstract code is often better and has less edge-cases. In this example, of you have 4 choices, then these can send all at once without delay. This will be much faster compared to the code you posted, which will wait after each request, even though the rate-limit is not applied. Apart from that, I don't think the second example is complete, where does ce come from here? And also, I don't know Deno, but calling "sleepSync" already looks like a bad idea to me, no matter where it's used - especially since calling a sync operation within an async doesn't make much sense.
  - lucacasonato 5y ago
    Yeah, this should not be calling `Deno.sleepSync`... this should be an `await new Promise(resolve => setTimeout(resolve, 220));`.
    - deleted 5y ago
      [deleted]
    - jshen 5y ago
      That's kind of my point, it's less obvious how to do basic things in js/ts than golang. What's the vanilla way in ts/js to do the equivalent of this golang code where getChoice makes an HTTP call and can't make more than 5 per second? for _, v := range choices { getChoice(v) time.Sleep(200) } Also, why doesn't Deno.sleepSync work as I expect here?
    - deleted 5y ago
      [deleted]
  - 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 would probably require a book length post to truly answer this, but here's the best short version I can do. I think it comes down to a few things. 1. Some languages on your list are very flexible, and that allows them to be written in a very readable form with great discipline. People tend to not have great discipline thought, for various reasons: their bosses are pushing them to go faster and cut corners, they aren't experienced enough yet, etc. I'd say that python and typescript/javascript fall into this category. 2. I think inheritance is the devil, and a more functional style is better (by functional I mean first class functions, passing parameters, etc not purely typed). Java/Groovy fall into this category, they overuse inheritance and things like dependency injection with xml or annotations rather than far easier to read function calls with parameters. 3. Then there is haskell :) Haskell requires a phd in rocket science to be proficient, and most people have other things they want to do with their life. You also can't hire a team of 1000 rocket scientists so most companies can't go this route. Edit: One other thing I'll add about typescript/javascipt because it's a bit of an oddball. There really isn't a typescript/javascript style because most devs end up writing javascript. The java people try to write java in it, the python people python, etc. This alone makes it hard to jump into a random JS/TS codebase and figure out what's going on. Regarding Go, it takes away a lot of flexibility, which makes the code longer generally, but it makes it much more consistent across code bases. It's lack of inheritance prevents the devil from showing up, and it's largely a simple function call with parameter passing style all the way through the code base. Structural typing is also a godsend. Edit 2: Also, package management in python is a complete train wreck.
mariusor 5y ago
From the list of languages you mentioned I understand that you probably enjoy ways to express algorithms in an elegant and (maybe) terse way. Maybe that's easier for you to understand. However all that abstraction is very far removed from what the compiler or the interpreter actually execute on the CPU. For me an easy to understand program is one where the way memory is structured and the way execution modifies said memory is easy to follow. That's why Go, despite being very verbose in some cases, it's easier to reason about, than codebases doing similar things in higher level programming languages.