6 ms·

I just love how this language marches forward. I have so many colleagues that hate many aspects of it but I sit here combining Go, Goa and SQLc writing mountain

I just love how this language marches forward. I have so many colleagues that hate many aspects of it but I sit here combining Go, Goa and SQLc writing mountains of code and having a fairly good compiler behind me. I understand what I’m missing out on by not using stricter languages and so often it’s a totally fine trade off.

devmor 1y ago
I did not like it at first but it has grown on me. I still have my gripes, which are mostly things that come from its overall architecture and will never be resolved, but it is pretty enjoyable to use for the limited domain I use it in at work.
danudey 1y ago
I've gotten used to golang, though it's still not my favourite language to program in by any stretch. One issue I've been having, though, is the documentation. Documentation for third-party modules in Python is fantastic, almost universally so. In nearly every case of using a third-party library, large or small, there's sufficient documentation to get up and running. Golang libraries, however, seem to be the opposite. In most cases there's either no documentation whatsoever on how to use things, or, more commonly, there is example code in the readme which is out of date and does not work at all. The IDE integration with golang is great, and it makes some of this a bit easier, but I also still get a ton of situations where my editor will offer some field or function that looks like what I want (and is what I'm typing to see if it will autocomplete) but once I select it it complains that there's no such field or function. Still haven't figured that out. So yeah, I dunno. The language is 'great'; it certainly has some extreme strengths and conveniences, like the fact that 'run this function with these arguments in a separate thread' is a language keyword and not some deep dive into subprocess or threading or concurrent.futures; the fact that synchronization functionality is trivially easy to access; Sync.Once feels so extremely obvious for a language where concurrency is king, and so on. Still, the ecosystem is... a bit of a mess, at the best of times. Good modules are great, all other modules are awful.
- leoqa 1y ago
  I quite frankly will just read the code. Go generally discourages abstractions so any code you jump into is fairly straightforward (compared to a hierarchy of abstract classes, dependency injected implementations, nested pattern matching with destructuring etc etc). Regarding your IDE issues- I’ve found the new wave of copilot/cursor behavior to be the culprit. Sometimes I just disable it and use the agent if I want it to do something. But it’ll completely fail to suggest an auto complete for a method that absolutely exists.
  - treyd 1y ago
    > Go generally discourages abstractions so any code you jump into is fairly straightforward This is a really anti-intellectual take. All of software engineering is about building abstractions. Not having abstractions makes the structure less easy to understand because they're made implicit, and forces developers to repeat themselves and use brittle hacks. It's not a way to build robust or maintainable software.
    - bjt 1y ago
      Go does have plenty of abstractions. I think the more charitable interpretation is "Go generally discourages metaprogramming." Which I would agree with, and I think positively distinguishes it from most popular languages.
      - eru 1y ago
        Go mostly only have abstractions that the language designers put into the language. It is (mostly) hostile to users defining their own new abstractions. A case in point is that arrays and maps (and the 'make' function etc) were always generic, but as a user until fairly recently you couldn't define your own generic data structures and algorithms.
    - Mawr 1y ago
      Did you cherry pick that part of the sentence and ignored "(compared to a hierarchy of abstract classes, dependency injected implementations, nested pattern matching with destructuring etc etc)." on purpose or?
gottorf 1y ago
Go is the only language where I've come back to a nontrivial source code after 10 years of letting it sit and have had zero problems building and running. That alone, for me, more than makes up for its idiosyncrasies.
- doublepg23 1y ago
  As a more sysadmin/ops focused guy it really is the killer feature. Static binaries and a more Java-esque resource profile than say Python are the cherries on top.
- fuzztester 1y ago
  i have read that same point said multiple times on hn about both common lisp and perl, including in a recent thread about perl.
  - keyle 1y ago
    The difference is that going back to Go code you've written a few years ago, isn't nearly as bad as going back to Perl code you've written a few years ago!
    - fredrikholm 1y ago
      And having written a lot of Common Lisp, Go code is extraordinarily straight forward in a sense where every developer writes in almost the exact same style. This is not true for Common Lisp (even though it's not as bad as people make it out to be). I feel the exact same way with C versus C++, even if I was the person to write the C++.
    - fuzztester 1y ago
      Nonsense! Different strokes for different folks! I feel very leery of people who end their sentences with exclamation marks! ;)
    - fuzztester 1y ago
      as is often said on hn, the plural of anecdote is not data. and ... different strokes for different folks. qed.
djfobbz 1y ago
Any language that helps me put food on my family table is a good language. For me, that has been the case with both Ruby and Go.
christophilus 1y ago
I love it because the average Go project has so few dependencies.
- jen20 1y ago
  While I agree, one thing that would really help there is the notion of test dependencies separate from ones that will end up in a production binary. Testify in particular is widely used in tests yet pulls in an entire YAML parser.
- lenkite 1y ago
  Only if you are not using Kubernetes.

devmor 1y ago

I did not like it at first but it has grown on me. I still have my gripes, which are mostly things that come from its overall architecture and will never be resolved, but it is pretty enjoyable to use for the limited domain I use it in at work.

danudey 1y ago

I've gotten used to golang, though it's still not my favourite language to program in by any stretch. One issue I've been having, though, is the documentation. Documentation for third-party modules in Python is fantastic, almost universally so. In nearly every case of using a third-party library, large or small, there's sufficient documentation to get up and running. Golang libraries, however, seem to be the opposite. In most cases there's either no documentation whatsoever on how to use things, or, more commonly, there is example code in the readme which is out of date and does not work at all. The IDE integration with golang is great, and it makes some of this a bit easier, but I also still get a ton of situations where my editor will offer some field or function that looks like what I want (and is what I'm typing to see if it will autocomplete) but once I select it it complains that there's no such field or function. Still haven't figured that out. So yeah, I dunno. The language is 'great'; it certainly has some extreme strengths and conveniences, like the fact that 'run this function with these arguments in a separate thread' is a language keyword and not some deep dive into subprocess or threading or concurrent.futures; the fact that synchronization functionality is trivially easy to access; Sync.Once feels so extremely obvious for a language where concurrency is king, and so on. Still, the ecosystem is... a bit of a mess, at the best of times. Good modules are great, all other modules are awful.

leoqa 1y ago
I quite frankly will just read the code. Go generally discourages abstractions so any code you jump into is fairly straightforward (compared to a hierarchy of abstract classes, dependency injected implementations, nested pattern matching with destructuring etc etc). Regarding your IDE issues- I’ve found the new wave of copilot/cursor behavior to be the culprit. Sometimes I just disable it and use the agent if I want it to do something. But it’ll completely fail to suggest an auto complete for a method that absolutely exists.
- treyd 1y ago
  > Go generally discourages abstractions so any code you jump into is fairly straightforward This is a really anti-intellectual take. All of software engineering is about building abstractions. Not having abstractions makes the structure less easy to understand because they're made implicit, and forces developers to repeat themselves and use brittle hacks. It's not a way to build robust or maintainable software.
  - bjt 1y ago
    Go does have plenty of abstractions. I think the more charitable interpretation is "Go generally discourages metaprogramming." Which I would agree with, and I think positively distinguishes it from most popular languages.
    - eru 1y ago
      Go mostly only have abstractions that the language designers put into the language. It is (mostly) hostile to users defining their own new abstractions. A case in point is that arrays and maps (and the 'make' function etc) were always generic, but as a user until fairly recently you couldn't define your own generic data structures and algorithms.
  - Mawr 1y ago
    Did you cherry pick that part of the sentence and ignored "(compared to a hierarchy of abstract classes, dependency injected implementations, nested pattern matching with destructuring etc etc)." on purpose or?

gottorf 1y ago

Go is the only language where I've come back to a nontrivial source code after 10 years of letting it sit and have had zero problems building and running. That alone, for me, more than makes up for its idiosyncrasies.

doublepg23 1y ago
As a more sysadmin/ops focused guy it really is the killer feature. Static binaries and a more Java-esque resource profile than say Python are the cherries on top.
fuzztester 1y ago
i have read that same point said multiple times on hn about both common lisp and perl, including in a recent thread about perl.
- keyle 1y ago
  The difference is that going back to Go code you've written a few years ago, isn't nearly as bad as going back to Perl code you've written a few years ago!
  - fredrikholm 1y ago
    And having written a lot of Common Lisp, Go code is extraordinarily straight forward in a sense where every developer writes in almost the exact same style. This is not true for Common Lisp (even though it's not as bad as people make it out to be). I feel the exact same way with C versus C++, even if I was the person to write the C++.
  - fuzztester 1y ago
    Nonsense! Different strokes for different folks! I feel very leery of people who end their sentences with exclamation marks! ;)
  - fuzztester 1y ago
    as is often said on hn, the plural of anecdote is not data. and ... different strokes for different folks. qed.

djfobbz 1y ago

Any language that helps me put food on my family table is a good language. For me, that has been the case with both Ruby and Go.

christophilus 1y ago

I love it because the average Go project has so few dependencies.

jen20 1y ago
While I agree, one thing that would really help there is the notion of test dependencies separate from ones that will end up in a production binary. Testify in particular is widely used in tests yet pulls in an entire YAML parser.
lenkite 1y ago
Only if you are not using Kubernetes.