8 ms·

Just going to share a sentiment I've felt while diving into Golang over several months. The canonical way to do things feels like it's all over the place in sev

by nstart 8y ago

Just going to share a sentiment I've felt while diving into Golang over several months. The canonical way to do things feels like it's all over the place in several areas of Golang. Not in the fundamental "this is how you should indent" bit but in the "this is how you should unpack dynamic json content" sense. I really wish golang had more canonical content. But at this point, I feel like I'm working against the grain. Golang doesn't feel like a language that wants to prescribe a lot more than fundamentals. How you structure your code beyond the src/git/path/your-code/ is completely up to you and every repo you visit could be different. It's not my thing personally, and I'm leaving this comment just in case any "want to try golang" folk stop by. This is something you should be aware of going in. Don't bang your head when you can't find a clear way of doing something that probably seemed simple in other languages. Embrace the new concept and see if you can get used to it. That said, if anyone ever breaks into the eco system with an es lint style tool that allows experts to share their best practices via plugins, that would be awesome. If that exists already, please do let me know. I'd love to give it a go.

jzoch 8y ago
To agree with you with a slight rephrase: what makes idiomatic go code is very murky lately. With new changes in the horizon (Go 2 proposals around error checking and generics) the current solutions just dont feel idiomatic. Before these proposals started coming in, people staunchly (and many still do) defended error checking and lack of generics. Now, it feels a bit weak. Why am I writing all this ceremony (comparatively little compared to other languages, but ceremony nonetheless) when the new, better way is coming? Additionally, I agree that the idiomatic design patterns of go aren't well defined beyond "use channels, share memory by communicating, handle errors, and dont ever use functional precepts". A lot of go feels really good which makes the not as good parts really stand out. Personally, I'd like to see small QoL improvements (beyond generics and error handling) like named arguments, native functional operators like map, reduce, filter that take advantage of go's great runtime, and something cool like kotlin's by keyword for delegating ( https://kotlinlang.org/docs/reference/delegation.html https://kotlinlang.org/docs/reference/delegation.html)
- dcow 8y ago
  I would argue `by` and `data` are the two most powerful keywords from any of the modern languages (~last 10 years) maybe next to `go`.
  - dnautics 8y ago
    You should check out the "with" keyword from elixir, (but the #1 all time best elixir feature is the |> (pipe) operator combined with IO.inspect)...
  - ngrilly 8y ago
    What does `data` do, and in which language?
    - letientai299 8y ago
      I think he means `data` class in kotlin. https://kotlinlang.org/docs/reference/data-classes.html https://kotlinlang.org/docs/reference/data-classes.html
      - ngrilly 8y ago
        Yes, it looks like this. Thanks!
  - bluk 8y ago
    IMO `async/await` (C# / JavaScript), `defer` (Go), and `guard` (Swift) have changed the structure and flow of programs and are commonly used in their respective languages. Why do you believe that `by` and curiously `data` are so powerful?
  - jstimpfle 8y ago
    > `data` > modern Everything old is new again.
    - dcow 8y ago
Groxx 8y ago
There are a couple implementations of this (e.g. staticcheck[1] is probably the biggest and most widely used), but none are really pluggable or easy to interact with. And nearly anything even slightly sophisticated needs to interact with the type checker, which has like one example repo[2] and no other documentation anywhere. There's a semi-recent experiment to try to make a pluggable lint system[3], but I'm not sure what the current status is. For my workplace, tbh I plan on making something semi-hacky just to get us off the ground + use real go plugins so we actually have some minor extensibility without reams of boilerplate. I've built several tiny things that just use the AST (which is not bad at all, and quite fast - several thousand source files take about 250ms), and they've been worth the effort like 100x over, but it's hard / impossible to do anything better without the type checker + significant amounts of work. [1]: very highly recommended, it has far more / better checks than others I've seen, but is also quite slow and hard to extend: https://staticcheck.io/ https://staticcheck.io/ [2]: it's honestly quite a good repo, but there needs to be more. it's a fairly unfriendly API and there are few helper libs as far as I've seen: https://golang.org/s/types-tutorial https://golang.org/s/types-tutorial [3]: https://docs.google.com/document/d/1-azPLXaLgTCKeKDNg0HVMq2ovMlD-e7n1ZHzZVzOlJk/edit#heading=h.yrkxrtoon8kq https://docs.google.com/document/d/1-azPLXaLgTCKeKDNg0HVMq2o...
- Zach_the_Lizard 8y ago
  I second the comments about the various AST and type packages. They are just absurdly unfriendly. I've written a linter / code formatter / auto bug repair tool internally for my current company and it sucked. Still sucks. Comments doubly so. The examples are few, undocumented, and don't always work with the vendor directory concept. I had to write my own custom importer to get vendor support to be more reliable. I like the concept of shipping with an AST package; it's very forward looking and useful. I too hope the go/analysis package could be the answer. I believe it has not merged but has a prototype version that conflicts with master. Maybe they'll patch it up and get it landed soon. I hope, anyways
  - Groxx 8y ago
    AST for read access I find relatively decent. Straightforward and not complicated. For manipulating code tho (e.g. for code gen or rewriting), yeah - absurdly unfriendly fits pretty well, and comments only kinda sorta mostly work until you actually try to produce anything polished. It kinda feels like they prioritized forward-compatibility at the cost of usability (which could be a decent decision / a fair tradeoff, but it sucks as a user trying to do stuff now).
weberc2 8y ago
> How you structure your code beyond the src/git/path/your-code/ is completely up to you and every repo you visit could be different. This is an unusual criticism. Typically Go is faulted for being too opinionated, and it’s projects too predictable. In fact, this is why I took to the language—no need to see past every maintainer’s personal flourishes just to build the code or run the tests. No ceremoniously nested directory structure. No figuring out how to point the build tool to the source files or how to convince the build tool to output or run a test target. Everything is right there, rather plainly and consistently across all projects. This does mean I have less room for creativity which is an okay tradeoff for me because I have just enough creativity to spend on the application and its architecture and the rest should just work, but I recognize that some may disagree and that’s okay too.
- Felz 8y ago
  This sounds like tooling and formatting consistency versus abstraction consistency. Go isn't great for building powerful abstractions, so at a higher level implementations will trend towards inconsistency, however consistent the low level syntax.
  - gcb0 8y ago
    in other words, it's consistent if you only look at it for a few minutes. use it for anything and it become an inconsistent mess.
    - kerng 8y ago
      Been trying it out and agree. I like it a lot for simple, stand alone tools. For more complex ones it appears strangely ill-suited and "messy".
  - jonathanstrange 8y ago
    As if powerful abstractions lead to more consistency...
  - weberc2 8y ago
    A few thoughts: 1. I don't think powerful abstractions are often that useful. I use Python in my day job, and we mostly don't use many high level abstractions. We never use monads, for example, and while we do use async futures, these are strictly worse than Go's concurrency features. 2. Pretty sure abstraction power drives _less_ consistency, not more. Effectually, it means there are more ways to do the same thing (and more ways to screw it up and make a mess), and consistency depends on organization discipline and less on the rails of the language. I don't mean to say abstraction is bad--only that consistency is one of the costs, not an advantage. I'm interested to hear your thoughts.
sjellis 8y ago
> Golang doesn't feel like a language that wants to prescribe a lot more than fundamentals. How you structure your code beyond the src/git/path/your-code/ is completely up to you and every repo you visit could be different. I only follow Go casually ATM, but I think that it might fairer to say that the core team wants to stay focused on delivering the language and implementations, so we get blog posts and conference talks, but not a big trove of guidance on patterns & practices. The best place to interact with the wider Go community is the Gophers Slack, and if you visit there, you will find that there's a lot of knowledge and thinking, but it's in scattered places. For example, this article will probably be cited in any discussion of application structure: https://medium.com/@benbjohnson/standard-package-layout-7cdbc8391fc1 https://medium.com/@benbjohnson/standard-package-layout-7cdb...
jcelerier 8y ago
> in the "this is how you should unpack dynamic json content" sense. I would be very wary of a language who has core features around such transient things than JSON unpacking.
alias_neo 8y ago
When i first started Golang professionally, over 3 years ago, my first gripe was the GOPATH. WHY SHOULD ALL MY CODE SIT IN ONE FOLDER? I say gripe, it was a huge annoyance. Why on earth, also, should i need to use the repo path in my structure and imports? It's obscene. My next annoyance was the utter inability to easily parse dynamic JSON. But you know what the JSON looks like? Great, you'll only have to wrap it in a few structs and check your capitalisation if you want it to parse at all, no problem you think before half a day has gone just parsing one response. The vendoring makes my month painful as I'm retooling the build system for the flavour of the month vendoring toy. Structuring large projects still causes me great pain. All of that said, Golang is now my favourite language to program in, and is my default for any new project.
- dom96 8y ago
  I've had a similar reaction when trying Go. While I'm biased, I strongly believe Nim offers a much better alternative which solves all of the problems you mention in a much better way. In particular, parsing JSON is a breeze, just like in Python. And there is no GOPATH weirdness. Give Nim a try if you haven't already, it may just become your new favourite language :)
  - alias_neo 8y ago
    I'll look into it, thanks. I was planning on Rust being my next language but I'll see what Nim offers. I take it your bias is because your the/a creator?
    - dom96 8y ago
      I'm one of the core developers
      - alias_neo 8y ago
        Ok! What's its standard library like compared to Go? I like that I can write powerful projects with few external dependencies. I don't like that C binding is slow and C++ binding is missing. How does it compare to Rust, which is currently top of my list to learn next? Can you suggest a reason, or a few why Nim should knock Rust from that spot?
InGodsName 8y ago
Our agency most mostly does SaaS apps. We use Rails and React. We tried Go for backend but Go is missing ActiveRecorss, payment gateway libraries, etc... Where is migration management like sqlachemy or activ records? For building SaaS product i think you should choose Rails. It takes only few minutes to creare subscription billling, team accounts, invoice etc.. functionality. I would like to know what you guys use.
- bpizzi 8y ago
  Well, the comparison is not really fair, Rails is a framework for building webapp, whereas Go is a language with a standard library. To simplify a bit: Go is in the same bag as C++/C#/Java, Rails is in the same bag as PHP & [Symfony/Laravel]. If you're mass building CRUD web applications against customers requirements then, clearly, RoR is the best tool for the job (versus Golang).
  - lowercased 8y ago
    > Go is in the same bag as C++/C#/Java, Rails is in the same bag as PHP & [Symfony/Laravel]. Go is in the same bag as C++/C#/Java/Ruby/PHP (languages) Rails is in the same bag as Symfony/Laravel (frameworks)
    - bpizzi 8y ago
      I literally said 'Rails is a framework for building webapp, whereas Go is a language with a standard library'. what's your point?
      - sixstringtheory 8y ago
        They moved PHP from framework to language, it’s a small nit but worth picking I suppose.
      - lowercased 8y ago
        Ruby is a language distinct from the Rails framework. PHP is a language distinct from the other frameworks listed. Small nitpick, but I always hate to see conflation of languages and frameworks when making comparisons.
Memosyne 8y ago
I try to adhere to https://github.com/golang-standards/project-layout https://github.com/golang-standards/project-layout, but I find that most repositories just have their own way of doing things. I really wish Go provided a standard structure for organizing projects, as I find it increasingly difficult to understand dozens of different structures.
AlexCoventry 8y ago
> es lint style tool that allows experts to share their best practices via plugins, Have you seen gometalinter? Its defaults are way too computationally expensive for me, but it brings together reports from a lot of different linters. https://github.com/alecthomas/gometalinter#supported-linters https://github.com/alecthomas/gometalinter#supported-linters
andreygrehov 8y ago
> How you structure your code beyond the src/git/path/your-code/ is completely up to you and every repo you visit could be different. Erm...I'm confused. Why on earth every repo should have the same structure? I mean, I understand when you use a framework that prescribes you a layout, but even so, good frameworks try not to get into developer's way. Why the source code of a webapp should have the same structure as a, say, database? There were quite a few comments about standard project layout - I'm sure there is something similar for every language, but these things are just recommendations. And thank god they are not rules. Am I missing something here?
- oblio 8y ago
  Yes. Having a common overall structure is good. When I open a Maven project, the Java sources are always (99,99% of the time) in src/main/java, the resources are in /src/main/resources, the Java test sources are in src/test/java, etc. Every project has to have source code, every project could have resources. Every project could have test sources, etc.

by nstart 8y ago

jzoch 8y ago

To agree with you with a slight rephrase: what makes idiomatic go code is very murky lately. With new changes in the horizon (Go 2 proposals around error checking and generics) the current solutions just dont feel idiomatic. Before these proposals started coming in, people staunchly (and many still do) defended error checking and lack of generics. Now, it feels a bit weak. Why am I writing all this ceremony (comparatively little compared to other languages, but ceremony nonetheless) when the new, better way is coming? Additionally, I agree that the idiomatic design patterns of go aren't well defined beyond "use channels, share memory by communicating, handle errors, and dont ever use functional precepts". A lot of go feels really good which makes the not as good parts really stand out. Personally, I'd like to see small QoL improvements (beyond generics and error handling) like named arguments, native functional operators like map, reduce, filter that take advantage of go's great runtime, and something cool like kotlin's by keyword for delegating ( https://kotlinlang.org/docs/reference/delegation.html https://kotlinlang.org/docs/reference/delegation.html)

dcow 8y ago
I would argue `by` and `data` are the two most powerful keywords from any of the modern languages (~last 10 years) maybe next to `go`.
- dnautics 8y ago
  You should check out the "with" keyword from elixir, (but the #1 all time best elixir feature is the |> (pipe) operator combined with IO.inspect)...
- ngrilly 8y ago
  What does `data` do, and in which language?
  - letientai299 8y ago
    I think he means `data` class in kotlin. https://kotlinlang.org/docs/reference/data-classes.html https://kotlinlang.org/docs/reference/data-classes.html
    - ngrilly 8y ago
      Yes, it looks like this. Thanks!
- bluk 8y ago
  IMO `async/await` (C# / JavaScript), `defer` (Go), and `guard` (Swift) have changed the structure and flow of programs and are commonly used in their respective languages. Why do you believe that `by` and curiously `data` are so powerful?
- jstimpfle 8y ago
  > `data` > modern Everything old is new again.
  - dcow 8y ago

Groxx 8y ago

There are a couple implementations of this (e.g. staticcheck[1] is probably the biggest and most widely used), but none are really pluggable or easy to interact with. And nearly anything even slightly sophisticated needs to interact with the type checker, which has like one example repo[2] and no other documentation anywhere. There's a semi-recent experiment to try to make a pluggable lint system[3], but I'm not sure what the current status is. For my workplace, tbh I plan on making something semi-hacky just to get us off the ground + use real go plugins so we actually have some minor extensibility without reams of boilerplate. I've built several tiny things that just use the AST (which is not bad at all, and quite fast - several thousand source files take about 250ms), and they've been worth the effort like 100x over, but it's hard / impossible to do anything better without the type checker + significant amounts of work. [1]: very highly recommended, it has far more / better checks than others I've seen, but is also quite slow and hard to extend: https://staticcheck.io/ https://staticcheck.io/ [2]: it's honestly quite a good repo, but there needs to be more. it's a fairly unfriendly API and there are few helper libs as far as I've seen: https://golang.org/s/types-tutorial https://golang.org/s/types-tutorial [3]: https://docs.google.com/document/d/1-azPLXaLgTCKeKDNg0HVMq2ovMlD-e7n1ZHzZVzOlJk/edit#heading=h.yrkxrtoon8kq https://docs.google.com/document/d/1-azPLXaLgTCKeKDNg0HVMq2o...

Zach_the_Lizard 8y ago
I second the comments about the various AST and type packages. They are just absurdly unfriendly. I've written a linter / code formatter / auto bug repair tool internally for my current company and it sucked. Still sucks. Comments doubly so. The examples are few, undocumented, and don't always work with the vendor directory concept. I had to write my own custom importer to get vendor support to be more reliable. I like the concept of shipping with an AST package; it's very forward looking and useful. I too hope the go/analysis package could be the answer. I believe it has not merged but has a prototype version that conflicts with master. Maybe they'll patch it up and get it landed soon. I hope, anyways
- Groxx 8y ago
  AST for read access I find relatively decent. Straightforward and not complicated. For manipulating code tho (e.g. for code gen or rewriting), yeah - absurdly unfriendly fits pretty well, and comments only kinda sorta mostly work until you actually try to produce anything polished. It kinda feels like they prioritized forward-compatibility at the cost of usability (which could be a decent decision / a fair tradeoff, but it sucks as a user trying to do stuff now).

weberc2 8y ago

> How you structure your code beyond the src/git/path/your-code/ is completely up to you and every repo you visit could be different. This is an unusual criticism. Typically Go is faulted for being too opinionated, and it’s projects too predictable. In fact, this is why I took to the language—no need to see past every maintainer’s personal flourishes just to build the code or run the tests. No ceremoniously nested directory structure. No figuring out how to point the build tool to the source files or how to convince the build tool to output or run a test target. Everything is right there, rather plainly and consistently across all projects. This does mean I have less room for creativity which is an okay tradeoff for me because I have just enough creativity to spend on the application and its architecture and the rest should just work, but I recognize that some may disagree and that’s okay too.

Felz 8y ago
This sounds like tooling and formatting consistency versus abstraction consistency. Go isn't great for building powerful abstractions, so at a higher level implementations will trend towards inconsistency, however consistent the low level syntax.
- gcb0 8y ago
  in other words, it's consistent if you only look at it for a few minutes. use it for anything and it become an inconsistent mess.
  - kerng 8y ago
    Been trying it out and agree. I like it a lot for simple, stand alone tools. For more complex ones it appears strangely ill-suited and "messy".
- jonathanstrange 8y ago
  As if powerful abstractions lead to more consistency...
- weberc2 8y ago
  A few thoughts: 1. I don't think powerful abstractions are often that useful. I use Python in my day job, and we mostly don't use many high level abstractions. We never use monads, for example, and while we do use async futures, these are strictly worse than Go's concurrency features. 2. Pretty sure abstraction power drives _less_ consistency, not more. Effectually, it means there are more ways to do the same thing (and more ways to screw it up and make a mess), and consistency depends on organization discipline and less on the rails of the language. I don't mean to say abstraction is bad--only that consistency is one of the costs, not an advantage. I'm interested to hear your thoughts.

sjellis 8y ago

> Golang doesn't feel like a language that wants to prescribe a lot more than fundamentals. How you structure your code beyond the src/git/path/your-code/ is completely up to you and every repo you visit could be different. I only follow Go casually ATM, but I think that it might fairer to say that the core team wants to stay focused on delivering the language and implementations, so we get blog posts and conference talks, but not a big trove of guidance on patterns & practices. The best place to interact with the wider Go community is the Gophers Slack, and if you visit there, you will find that there's a lot of knowledge and thinking, but it's in scattered places. For example, this article will probably be cited in any discussion of application structure: https://medium.com/@benbjohnson/standard-package-layout-7cdbc8391fc1 https://medium.com/@benbjohnson/standard-package-layout-7cdb...

jcelerier 8y ago

> in the "this is how you should unpack dynamic json content" sense. I would be very wary of a language who has core features around such transient things than JSON unpacking.

alias_neo 8y ago

When i first started Golang professionally, over 3 years ago, my first gripe was the GOPATH. WHY SHOULD ALL MY CODE SIT IN ONE FOLDER? I say gripe, it was a huge annoyance. Why on earth, also, should i need to use the repo path in my structure and imports? It's obscene. My next annoyance was the utter inability to easily parse dynamic JSON. But you know what the JSON looks like? Great, you'll only have to wrap it in a few structs and check your capitalisation if you want it to parse at all, no problem you think before half a day has gone just parsing one response. The vendoring makes my month painful as I'm retooling the build system for the flavour of the month vendoring toy. Structuring large projects still causes me great pain. All of that said, Golang is now my favourite language to program in, and is my default for any new project.

dom96 8y ago
I've had a similar reaction when trying Go. While I'm biased, I strongly believe Nim offers a much better alternative which solves all of the problems you mention in a much better way. In particular, parsing JSON is a breeze, just like in Python. And there is no GOPATH weirdness. Give Nim a try if you haven't already, it may just become your new favourite language :)
- alias_neo 8y ago
  I'll look into it, thanks. I was planning on Rust being my next language but I'll see what Nim offers. I take it your bias is because your the/a creator?
  - dom96 8y ago
    I'm one of the core developers
    - alias_neo 8y ago
      Ok! What's its standard library like compared to Go? I like that I can write powerful projects with few external dependencies. I don't like that C binding is slow and C++ binding is missing. How does it compare to Rust, which is currently top of my list to learn next? Can you suggest a reason, or a few why Nim should knock Rust from that spot?

InGodsName 8y ago

Our agency most mostly does SaaS apps. We use Rails and React. We tried Go for backend but Go is missing ActiveRecorss, payment gateway libraries, etc... Where is migration management like sqlachemy or activ records? For building SaaS product i think you should choose Rails. It takes only few minutes to creare subscription billling, team accounts, invoice etc.. functionality. I would like to know what you guys use.

bpizzi 8y ago
Well, the comparison is not really fair, Rails is a framework for building webapp, whereas Go is a language with a standard library. To simplify a bit: Go is in the same bag as C++/C#/Java, Rails is in the same bag as PHP & [Symfony/Laravel]. If you're mass building CRUD web applications against customers requirements then, clearly, RoR is the best tool for the job (versus Golang).
- lowercased 8y ago
  > Go is in the same bag as C++/C#/Java, Rails is in the same bag as PHP & [Symfony/Laravel]. Go is in the same bag as C++/C#/Java/Ruby/PHP (languages) Rails is in the same bag as Symfony/Laravel (frameworks)
  - bpizzi 8y ago
    I literally said 'Rails is a framework for building webapp, whereas Go is a language with a standard library'. what's your point?
    - sixstringtheory 8y ago
      They moved PHP from framework to language, it’s a small nit but worth picking I suppose.
    - lowercased 8y ago
      Ruby is a language distinct from the Rails framework. PHP is a language distinct from the other frameworks listed. Small nitpick, but I always hate to see conflation of languages and frameworks when making comparisons.

Memosyne 8y ago

I try to adhere to https://github.com/golang-standards/project-layout https://github.com/golang-standards/project-layout, but I find that most repositories just have their own way of doing things. I really wish Go provided a standard structure for organizing projects, as I find it increasingly difficult to understand dozens of different structures.

AlexCoventry 8y ago

> es lint style tool that allows experts to share their best practices via plugins, Have you seen gometalinter? Its defaults are way too computationally expensive for me, but it brings together reports from a lot of different linters. https://github.com/alecthomas/gometalinter#supported-linters https://github.com/alecthomas/gometalinter#supported-linters

andreygrehov 8y ago

> How you structure your code beyond the src/git/path/your-code/ is completely up to you and every repo you visit could be different. Erm...I'm confused. Why on earth every repo should have the same structure? I mean, I understand when you use a framework that prescribes you a layout, but even so, good frameworks try not to get into developer's way. Why the source code of a webapp should have the same structure as a, say, database? There were quite a few comments about standard project layout - I'm sure there is something similar for every language, but these things are just recommendations. And thank god they are not rules. Am I missing something here?

oblio 8y ago
Yes. Having a common overall structure is good. When I open a Maven project, the Java sources are always (99,99% of the time) in src/main/java, the resources are in /src/main/resources, the Java test sources are in src/test/java, etc. Every project has to have source code, every project could have resources. Every project could have test sources, etc.