6 ms·

What's so great about Go?

51 points by theBashShell 6y ago

jitl 6y ago
Very generic Golang puff piece; this reads like a Business Insider “contributor” blog post.
- throwaway894345 6y ago
  Agreed, and I'm a fan of Go. Evaluating its performance from a toy CRUD app and a microbenchmark? It's disappointing to see this on SO.
  - bird_monster 6y ago
    Pretty much all of the content on that blog is fluff garbage. "Making the most of your one-on-one with your manager or other leadership", "Communities and Connections will power our growth in 2021", "Static site generation with single page app functionality? That’s what’s coming Next(.js)".
  - Cthulhu_ 6y ago
    Yeah, SO is very much aimed at the masses + management, I mean their main platform is aimed at that as well.
- jshen 6y ago
  I couldn’t agree more. I love Go, but this piece is superficial at best. One thing I’ll say about Go, and why I love it. I’ve been coding for decades, and it’s one of the few languages where I find it very easy to read and understand other peoples code.
  - taywrobel 6y ago
    That’s more a side effect of the tooling than the language itself tho. “ Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.” https://go-proverbs.github.io/ https://go-proverbs.github.io/
    - eat_veggies 6y ago
      not sure I agree. the ability to comprehend code goes way beyond surface-level formatting, especially since gofmt doesn't actually do that much
      - kortex 6y ago
        I concur. It's not just gofmt (although it is great). With go and an IDE, I can drill straight down and basically hit "bottom of the stack" within <5-7 jumps of "jump to definition" (C-b for me). Python it's like layer on layer on layer of indirection, "clever" code everywhere, and frequently the track runs cold. I don't have to sit there and study some inscrutable nugget for minutes/hours cause it's all obvious. Not sure if it's the language, culture, or both, but I love it.
    - cle 6y ago
      The language goes out of its way to minimize concepts, the number of ways state can be mutated (eg no thread locals), over-abstraction, and dynamic meta-programming. It emphasizes explicit control flow, preferring code duplication that is easy to read, over minimizing duplication by creating complex abstractions or implicit runtime behavior. There are a lot of cases where these tradeoffs suck and add a bunch of unnecessary friction. And there are many cases where it boosts overall productivity significantly.
    - Cthulhu_ 6y ago
      It's not just the formatting though, I think it's the lack of magic and options; when you compare it with Java, every library will have its own style and approach to doing things. in Go, things are a lot more consistent - either because of the language, or because of conventions. I've always considered Scala to be the linear opposite of Go, where over time they have bolted more and more (advanced) features and syntax until you end up with libraries and code as extreme as scalaz [1], and of course every developer will have their own Opinion on how things should be written, formatted, etc. Scala adds choice, Go reduces it. Oftentimes the argument is "but you don't have to use all these features! you can write Scala just like Java", but in practice that's not how it works. I mean just a for loop is already a headscratcher in Scala. [1]https://github.com/scalaz/scalaz https://github.com/scalaz/scalaz
  - sjansen 6y ago
    In my opinion, Go & Python are similar languages in the way they balance language constraints with just enough expressiveness to not feel stifling. I think this is part of the reason so many Python shops have adopted Go as either a second language or their new primary language.
sigrlami 6y ago
Get Generics implemented first. Fortunately draft already prepared but any modern PL without similar generalization tech is far from `great`.
- steve_adams_86 6y ago
  I really struggle with this too. I know a language can be great at what it does without generics, but it doesn't seem like Go is geared towards being that kind of language. I appreciate how easy it is to write and how incredible the performance is, but I get tired of the style of code it forces you to write. I write a lot of code to reduce the amount of code I need to write. In Go, that's not really easy to go or necessarily a good idea because of the lack of generalization.
  - sheeshkebab 6y ago
    The problem with generics is that every programmer generalizes differently and thus there is a massive barrier/“learning curve” for anyone new picking up an arcane codebase that some clever developer cooked up. Not saying someone can’t screw up codebases in go, but it’s just much harder to do and you usually see it right away by noticing abuse of interface{}.
    - deleted 6y ago
      [deleted]
    - steve_adams_86 6y ago
      I agree completely. I use very dumb generalizations in hopes of keeping them easy to follow. I’ve burned myself and team members with cleverness many times with good intentions. These days I’ve calmed down a little but still find generalizations handy on a regular basis. You’re absolutely right though and I see why they were left out. For a lot of people (including myself at a times) it’s probably best to prevent cleverness.
  - Cthulhu_ 6y ago
    > I write a lot of code to reduce the amount of code I need to write. In Go, that's not really easy to go or necessarily a good idea because of the lack of generalization. This is where one of those sayings come in; "Duplication is better than the wrong abstraction"
quaffapint 6y ago
They mention two things in the article - speed and number of lines of code. Are either of them the most important thing in the average business code? Sure devs always like to get things faster just because they can, but in most business settings whether its java, .net, php, etc it really doesn't matter it will be just fine for the speed (considering its probably database calls, etc that are the bottleneck). I would argue its more about code readability and maintainability than speed. Can I take a java developer and have him/her look at some Go code and know what's going on? For the most part I would say yes.
taywrobel 6y ago
TLDR; - Simplified, familiar syntax for those who already know a C variant - Concurrency model (CSP) which works nicely with the request/response paradigm of server communication - Performance comparable to other statically compiled languages.
haolez 6y ago
The nicest thing about Go is that the trade-offs are quite clear from the beginning, i.e. you know what you are sacrificing to seize the pros. The cons are usually excessive verbosity. I'll add my favorite pros as well: - the language is very simple and explicit, which makes it easy to understand third party code bases - the spec moves very slowly (or not at all), which ends up protecting the investment that you make into your software in the long term
loopz 6y ago
Go is simple and fast to use, but not so elegant under the hood, which is part of the cost. Go is great for readability and changing of code, depending on the dev and time though.
- Cthulhu_ 6y ago
  > not so elegant under the hood Could you explain this? IIRC they kept the language simple so that they can keep things elegant in tooling / compilers / etc as well. Or is this about the runtime?
watermelon59 6y ago
To me it's the fact that it's an alright language to build stuff in, but the tooling is hard to beat. The fact that you can "go <command>" so many things so easily (build, run, test, etc.) beats almost every language out there. It makes starting new projects really easy. Personally, that's one of the main barriers I feel when I'm trying to start anything in other languages. Consider Java (or Kotlin, for that matter). You need either a Maven POM or a Gradle build file. Gradle makes things a little easier with 'gradle init', but you're still stuck with arcane build files either way. If you have to use Maven and need any plugins... Good luck with that. I think the general pattern here is that pretty much every language doesn't stand on its own when it comes to starting and working on a project. You need external build and dependency management tools. Go has it all built-in and it's super easy to use. It's beautiful. Language-wise, I want a language that's as versatile as Kotlin, with the ease of use of Go. Imagine having a bunch of .kt files and just being able to 'kotlin build', 'kotlin run', etc. That'd be gold.
- jitl 6y ago
  In some ways Kotlin’s heritage from JetBrains is a disincentive to make this simple, batteries-included build/run/test/deps tool - most language users and the language producers have the IDE itself playing this role. I hope that as Kotlin multi-platform matures, we’ll see more stand-alone, Unix-y tooling for the language. As is, it seems very challenging to do a Kotlin project without a (JetBrains) IDE handling initial project set-up, Repl, build, run, test, and all the Gradle malarkey.
  - kinjba11 6y ago
    Technically you can use Gradle from the command line. Gradle isn't pretty though. `gradle init` for a simple Kotlin hello-world application generates 20+ files and folders, which to me is an incredible amount of bloat. Not exactly Unix-y. Agreed about Kotlin being made by JetBrains being a negative. It's a great language, but only working with one IDE, JetBrains', is a trap I'd rather not be in. They seem to be on the wrong side of history with the Language Server Protocol becoming more popular every day.
- kinjba11 6y ago
fnord77 6y ago
What's not so great about Golang: -error handling is kinda ugly and verbose -no generics -interfaces are done through duck typing -null pointers -int size is platform dependent -no built-in immutability
- rgoulter 6y ago
  A point I don't see mentioned often enough is a couple of points about the compiler's poor DX for iterative development. Go will fail to build if you have unused dependencies or variables. (And it's easy to use the convenient `:=` in a way which faces problems exacerbated by this). If I'm debugging through something, I might be adding packages or intermediate calculations to try and figure out what's going wrong. But because the Go compiler enforces this proper style of "nothing unused", there's that much more friction when tinkering.
  - papaf 6y ago
    I highly recommend using goimports to format your code on save: https://godoc.org/golang.org/x/tools/cmd/goimports https://godoc.org/golang.org/x/tools/cmd/goimports This will hopefully reduce some of the friction you are having.
- kortex 6y ago
  What's great about "not so great about Golang" posts: - it's the exact same 4-6 criticisms every single time - "no generics" is on the chopping block
  - blandflakes 6y ago
    > - it's the exact same 4-6 criticisms every single time This isn't necessarily an argument that those criticisms are wrong, though.
  - duckmysick 6y ago
    It's the exact same criticisms every single time about other languages too. Unsafe C, slow Python, verbose Java, messy JavaScript ecosystem, etc. When criticism is valid, it doesn't matter if it's novel or not.
Barrin92 6y ago
Personally I like Go for the same reason I like Clojure. It aims to be a simple (in the most positive sense of the term) and reliable language that avoids fanciness or complexity and has a good concurrency model. Easy to learn and without much arcane hierarchies and easy to read and maintain. The longer I write code the more I'm drawn to simplicity as the most important thing about a language.
dustinmoris 6y ago
I am fairly new to Go, been a Gopher for about a year now, and I really like it a lot. My background is Visual Basic, PHP, C and C++ and then C# and F# for the longest part. Coming from .NET Go feels like a huge breath of fresh air and brought the fun back into programming. What I enjoy the most is the simplicity (not to be mistaken with the language being “simple”) and the vibrant OSS ecosystem. With Go I feel like I’m actually programming again and solving problems. My focus is to deliver value. With C# I feel like 50% of the time is spent understanding everything around it and mastering .NET with the anticipation that the next project will benefit from my expertise, but before the next project has arrived the .NET landscape has changed significantly enough so that I’m yet again spending 50% of my time mastering the language rather than building something cool.
deleted 6y ago
[deleted]

51 points by theBashShell 6y ago

jitl 6y ago

Very generic Golang puff piece; this reads like a Business Insider “contributor” blog post.

throwaway894345 6y ago
Agreed, and I'm a fan of Go. Evaluating its performance from a toy CRUD app and a microbenchmark? It's disappointing to see this on SO.
- bird_monster 6y ago
  Pretty much all of the content on that blog is fluff garbage. "Making the most of your one-on-one with your manager or other leadership", "Communities and Connections will power our growth in 2021", "Static site generation with single page app functionality? That’s what’s coming Next(.js)".
- Cthulhu_ 6y ago
  Yeah, SO is very much aimed at the masses + management, I mean their main platform is aimed at that as well.
jshen 6y ago
I couldn’t agree more. I love Go, but this piece is superficial at best. One thing I’ll say about Go, and why I love it. I’ve been coding for decades, and it’s one of the few languages where I find it very easy to read and understand other peoples code.
- taywrobel 6y ago
  That’s more a side effect of the tooling than the language itself tho. “ Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.” https://go-proverbs.github.io/ https://go-proverbs.github.io/
  - eat_veggies 6y ago
    not sure I agree. the ability to comprehend code goes way beyond surface-level formatting, especially since gofmt doesn't actually do that much
    - kortex 6y ago
      I concur. It's not just gofmt (although it is great). With go and an IDE, I can drill straight down and basically hit "bottom of the stack" within <5-7 jumps of "jump to definition" (C-b for me). Python it's like layer on layer on layer of indirection, "clever" code everywhere, and frequently the track runs cold. I don't have to sit there and study some inscrutable nugget for minutes/hours cause it's all obvious. Not sure if it's the language, culture, or both, but I love it.
  - cle 6y ago
    The language goes out of its way to minimize concepts, the number of ways state can be mutated (eg no thread locals), over-abstraction, and dynamic meta-programming. It emphasizes explicit control flow, preferring code duplication that is easy to read, over minimizing duplication by creating complex abstractions or implicit runtime behavior. There are a lot of cases where these tradeoffs suck and add a bunch of unnecessary friction. And there are many cases where it boosts overall productivity significantly.
  - Cthulhu_ 6y ago
    It's not just the formatting though, I think it's the lack of magic and options; when you compare it with Java, every library will have its own style and approach to doing things. in Go, things are a lot more consistent - either because of the language, or because of conventions. I've always considered Scala to be the linear opposite of Go, where over time they have bolted more and more (advanced) features and syntax until you end up with libraries and code as extreme as scalaz [1], and of course every developer will have their own Opinion on how things should be written, formatted, etc. Scala adds choice, Go reduces it. Oftentimes the argument is "but you don't have to use all these features! you can write Scala just like Java", but in practice that's not how it works. I mean just a for loop is already a headscratcher in Scala. [1]https://github.com/scalaz/scalaz https://github.com/scalaz/scalaz
- sjansen 6y ago
  In my opinion, Go & Python are similar languages in the way they balance language constraints with just enough expressiveness to not feel stifling. I think this is part of the reason so many Python shops have adopted Go as either a second language or their new primary language.

sigrlami 6y ago

Get Generics implemented first. Fortunately draft already prepared but any modern PL without similar generalization tech is far from `great`.

steve_adams_86 6y ago
I really struggle with this too. I know a language can be great at what it does without generics, but it doesn't seem like Go is geared towards being that kind of language. I appreciate how easy it is to write and how incredible the performance is, but I get tired of the style of code it forces you to write. I write a lot of code to reduce the amount of code I need to write. In Go, that's not really easy to go or necessarily a good idea because of the lack of generalization.
- sheeshkebab 6y ago
  The problem with generics is that every programmer generalizes differently and thus there is a massive barrier/“learning curve” for anyone new picking up an arcane codebase that some clever developer cooked up. Not saying someone can’t screw up codebases in go, but it’s just much harder to do and you usually see it right away by noticing abuse of interface{}.
  - deleted 6y ago
    [deleted]
  - steve_adams_86 6y ago
    I agree completely. I use very dumb generalizations in hopes of keeping them easy to follow. I’ve burned myself and team members with cleverness many times with good intentions. These days I’ve calmed down a little but still find generalizations handy on a regular basis. You’re absolutely right though and I see why they were left out. For a lot of people (including myself at a times) it’s probably best to prevent cleverness.
- Cthulhu_ 6y ago
  > I write a lot of code to reduce the amount of code I need to write. In Go, that's not really easy to go or necessarily a good idea because of the lack of generalization. This is where one of those sayings come in; "Duplication is better than the wrong abstraction"

quaffapint 6y ago

They mention two things in the article - speed and number of lines of code. Are either of them the most important thing in the average business code? Sure devs always like to get things faster just because they can, but in most business settings whether its java, .net, php, etc it really doesn't matter it will be just fine for the speed (considering its probably database calls, etc that are the bottleneck). I would argue its more about code readability and maintainability than speed. Can I take a java developer and have him/her look at some Go code and know what's going on? For the most part I would say yes.

taywrobel 6y ago

TLDR; - Simplified, familiar syntax for those who already know a C variant - Concurrency model (CSP) which works nicely with the request/response paradigm of server communication - Performance comparable to other statically compiled languages.

haolez 6y ago

The nicest thing about Go is that the trade-offs are quite clear from the beginning, i.e. you know what you are sacrificing to seize the pros. The cons are usually excessive verbosity. I'll add my favorite pros as well: - the language is very simple and explicit, which makes it easy to understand third party code bases - the spec moves very slowly (or not at all), which ends up protecting the investment that you make into your software in the long term

loopz 6y ago

Go is simple and fast to use, but not so elegant under the hood, which is part of the cost. Go is great for readability and changing of code, depending on the dev and time though.

Cthulhu_ 6y ago
> not so elegant under the hood Could you explain this? IIRC they kept the language simple so that they can keep things elegant in tooling / compilers / etc as well. Or is this about the runtime?

watermelon59 6y ago

To me it's the fact that it's an alright language to build stuff in, but the tooling is hard to beat. The fact that you can "go <command>" so many things so easily (build, run, test, etc.) beats almost every language out there. It makes starting new projects really easy. Personally, that's one of the main barriers I feel when I'm trying to start anything in other languages. Consider Java (or Kotlin, for that matter). You need either a Maven POM or a Gradle build file. Gradle makes things a little easier with 'gradle init', but you're still stuck with arcane build files either way. If you have to use Maven and need any plugins... Good luck with that. I think the general pattern here is that pretty much every language doesn't stand on its own when it comes to starting and working on a project. You need external build and dependency management tools. Go has it all built-in and it's super easy to use. It's beautiful. Language-wise, I want a language that's as versatile as Kotlin, with the ease of use of Go. Imagine having a bunch of .kt files and just being able to 'kotlin build', 'kotlin run', etc. That'd be gold.

jitl 6y ago
In some ways Kotlin’s heritage from JetBrains is a disincentive to make this simple, batteries-included build/run/test/deps tool - most language users and the language producers have the IDE itself playing this role. I hope that as Kotlin multi-platform matures, we’ll see more stand-alone, Unix-y tooling for the language. As is, it seems very challenging to do a Kotlin project without a (JetBrains) IDE handling initial project set-up, Repl, build, run, test, and all the Gradle malarkey.
- kinjba11 6y ago
  Technically you can use Gradle from the command line. Gradle isn't pretty though. `gradle init` for a simple Kotlin hello-world application generates 20+ files and folders, which to me is an incredible amount of bloat. Not exactly Unix-y. Agreed about Kotlin being made by JetBrains being a negative. It's a great language, but only working with one IDE, JetBrains', is a trap I'd rather not be in. They seem to be on the wrong side of history with the Language Server Protocol becoming more popular every day.
kinjba11 6y ago

fnord77 6y ago

What's not so great about Golang: -error handling is kinda ugly and verbose -no generics -interfaces are done through duck typing -null pointers -int size is platform dependent -no built-in immutability

rgoulter 6y ago
A point I don't see mentioned often enough is a couple of points about the compiler's poor DX for iterative development. Go will fail to build if you have unused dependencies or variables. (And it's easy to use the convenient `:=` in a way which faces problems exacerbated by this). If I'm debugging through something, I might be adding packages or intermediate calculations to try and figure out what's going wrong. But because the Go compiler enforces this proper style of "nothing unused", there's that much more friction when tinkering.
- papaf 6y ago
  I highly recommend using goimports to format your code on save: https://godoc.org/golang.org/x/tools/cmd/goimports https://godoc.org/golang.org/x/tools/cmd/goimports This will hopefully reduce some of the friction you are having.
kortex 6y ago
What's great about "not so great about Golang" posts: - it's the exact same 4-6 criticisms every single time - "no generics" is on the chopping block
- blandflakes 6y ago
  > - it's the exact same 4-6 criticisms every single time This isn't necessarily an argument that those criticisms are wrong, though.
- duckmysick 6y ago
  It's the exact same criticisms every single time about other languages too. Unsafe C, slow Python, verbose Java, messy JavaScript ecosystem, etc. When criticism is valid, it doesn't matter if it's novel or not.

Barrin92 6y ago

Personally I like Go for the same reason I like Clojure. It aims to be a simple (in the most positive sense of the term) and reliable language that avoids fanciness or complexity and has a good concurrency model. Easy to learn and without much arcane hierarchies and easy to read and maintain. The longer I write code the more I'm drawn to simplicity as the most important thing about a language.

dustinmoris 6y ago

I am fairly new to Go, been a Gopher for about a year now, and I really like it a lot. My background is Visual Basic, PHP, C and C++ and then C# and F# for the longest part. Coming from .NET Go feels like a huge breath of fresh air and brought the fun back into programming. What I enjoy the most is the simplicity (not to be mistaken with the language being “simple”) and the vibrant OSS ecosystem. With Go I feel like I’m actually programming again and solving problems. My focus is to deliver value. With C# I feel like 50% of the time is spent understanding everything around it and mastering .NET with the anticipation that the next project will benefit from my expertise, but before the next project has arrived the .NET landscape has changed significantly enough so that I’m yet again spending 50% of my time mastering the language rather than building something cool.

deleted 6y ago

[deleted]