3 ms·

Needs a "2016" in the title. I've mostly skimmed this article but based on what I'm seeing it's more of the same, "Concurrency", "Simplicity", "Simple deployme

by dom96 8y ago

Needs a "2016" in the title. I've mostly skimmed this article but based on what I'm seeing it's more of the same, "Concurrency", "Simplicity", "Simple deployment" etc. I would really like to learn something else about Go now, when is Python a better choice? When is Rust a better choice? What are the negatives of using Go?

zzzcpan 8y ago
Concurrency bugs in Go study is a good place to start on the last one: https://songlh.github.io/paper/go-study.pdf https://songlh.github.io/paper/go-study.pdf
apta 8y ago
For your last point: https://www.reddit.com/r/programming/comments/an33mo/aspnet_core_saturating_10gbe_at_7_million_rps/efrvn0e/ https://www.reddit.com/r/programming/comments/an33mo/aspnet_...
- stunt 8y ago
  > https://www.reddit.com/r/programming/comments/an33mo/aspnet_core_saturating_10gbe_at_7_million_rps/efrvn0e/ https://www.reddit.com/r/programming/comments/an33mo/aspnet_... There are plenty of articles comparing Rust and Go. Easy to find. When it comes to Go itself, You have both those pros listed in this article and repeated everywhere, and these cons listed in Reddit and again repeated everywhere. In my opinion cons will weight more and becomes annoying when you are working on a large projects/code-base, Otherwise for smaller projects you don't notice them much and performance and goroutines are the main reasons for MOST not ALL projects choosing Go over Python or Ruby in that scale.
  - apta 8y ago
    I find it ironic that golang was supposedly created for "large scale" programming, but nothing really in the language supports that notion (no dependency management, import system sucks, verbose error handling, and so on). I just see the claim without anything to back it up.
    - dragonwriter 8y ago
      I'm pretty sure “large scale” was meant specifically in the sense of a single shop with a gigantic code base in a monorepo. Or, more directly, it means “Google”.
      - apta 8y ago
        Yes, that's what I meant, and it does a bad job at it (the examples I gave). Java/C#/Kotlin/etc. are strictly superior when it comes to managing large code bases. I think what they had in mind is just quick compilation times, even at the expense of convenience, safety, terseness, etc.
lerax 8y ago
[darkside]

by dom96 8y ago

zzzcpan 8y ago

Concurrency bugs in Go study is a good place to start on the last one: https://songlh.github.io/paper/go-study.pdf https://songlh.github.io/paper/go-study.pdf

apta 8y ago

For your last point: https://www.reddit.com/r/programming/comments/an33mo/aspnet_core_saturating_10gbe_at_7_million_rps/efrvn0e/ https://www.reddit.com/r/programming/comments/an33mo/aspnet_...

stunt 8y ago
> https://www.reddit.com/r/programming/comments/an33mo/aspnet_core_saturating_10gbe_at_7_million_rps/efrvn0e/ https://www.reddit.com/r/programming/comments/an33mo/aspnet_... There are plenty of articles comparing Rust and Go. Easy to find. When it comes to Go itself, You have both those pros listed in this article and repeated everywhere, and these cons listed in Reddit and again repeated everywhere. In my opinion cons will weight more and becomes annoying when you are working on a large projects/code-base, Otherwise for smaller projects you don't notice them much and performance and goroutines are the main reasons for MOST not ALL projects choosing Go over Python or Ruby in that scale.
- apta 8y ago
  I find it ironic that golang was supposedly created for "large scale" programming, but nothing really in the language supports that notion (no dependency management, import system sucks, verbose error handling, and so on). I just see the claim without anything to back it up.
  - dragonwriter 8y ago
    I'm pretty sure “large scale” was meant specifically in the sense of a single shop with a gigantic code base in a monorepo. Or, more directly, it means “Google”.
    - apta 8y ago
      Yes, that's what I meant, and it does a bad job at it (the examples I gave). Java/C#/Kotlin/etc. are strictly superior when it comes to managing large code bases. I think what they had in mind is just quick compilation times, even at the expense of convenience, safety, terseness, etc.

lerax 8y ago

[darkside]