3 ms·

i don't like this post because it makes golang feel overwhelming when the stdlib + default tooling is plenty good for most use-cases. it's as if someone made a

by j3s 3y ago

i don't like this post because it makes golang feel overwhelming when the stdlib + default tooling is plenty good for most use-cases. it's as if someone made a post called "how to go hiking in 2023" and spent 10 pages linking to gear on amazon. how should you actually start hiking? grab a water bottle, get outside, and hike. here is how you should _actually_ start a go project in 2023: $EDITOR main.go go run . everything else you should add as needed. don't overcomplicate things.

opportune 3y ago
Yeah, for a basic Go service or tool I don’t think you usually need anything besides the standard lib. Maybe you will want to use a client library but most of the time it’s only thinly wrapping various http functionality. I work on some go binaries used at massive scale that have little/no dependencies.
shepherdjerred 3y ago
On the other hand, the article contains information about things you are likely to need. This is the exact article I would want to present to someone new to the language. It isn't recommending every tool in existence (well, until you reach the very end) -- it's simply giving information about what you'll almost certainly need to know
- nirui 3y ago
  > the article contains information about things you are likely to need Then maybe write something on the specific topic in detail than bundling them into a How-To tutorial. A How-To tutorial is suppose to show "how to" do something correctly, it's a teach than showcase. I do understand that the author was writing this article with best intentions in their mind, but the resulting article is not a How-To, rather, it's a How-Do-I which is opinionated. I think when reading articles like this, it is important to remember that, sometimes, more is less. You import this many tools into your project, many of them are unnecessary and will not help you completing the project, now they've been download and installed, maybe they're even interfering with other tools. You look at them and starts to think "hey, make be I should learn to integrate and utilize them". Then you wasted an afternoon trying to utilize the tool, but by the evening you realized that in order to use the tool correctly, you must restructure your project. This is not how you can finish things, you know? If you want to write a new project, just `go mod init` it and write the code. And during the writing, if you found the need for some tools, just introduce those tools one by one to fulfill the need. Don't downloading tools or creating "project layouts" just because some tutorial said so.
JetSetIlly 3y ago
That used to be how you started a go project. Unfortunately, modern Go requires you to first setup a go.mod file with: go mod init <project name> Still simple but for better or worse it's now a necessary part of the process.
- foldr 3y ago
  You can still do go run main.go So no need to init a package if you are just using the stdlib and you’re in a hurry.
  - JetSetIlly 3y ago
    I didn't know that. That's genuinely useful to know.

by j3s 3y ago

opportune 3y ago

Yeah, for a basic Go service or tool I don’t think you usually need anything besides the standard lib. Maybe you will want to use a client library but most of the time it’s only thinly wrapping various http functionality. I work on some go binaries used at massive scale that have little/no dependencies.

shepherdjerred 3y ago

On the other hand, the article contains information about things you are likely to need. This is the exact article I would want to present to someone new to the language. It isn't recommending every tool in existence (well, until you reach the very end) -- it's simply giving information about what you'll almost certainly need to know

nirui 3y ago
> the article contains information about things you are likely to need Then maybe write something on the specific topic in detail than bundling them into a How-To tutorial. A How-To tutorial is suppose to show "how to" do something correctly, it's a teach than showcase. I do understand that the author was writing this article with best intentions in their mind, but the resulting article is not a How-To, rather, it's a How-Do-I which is opinionated. I think when reading articles like this, it is important to remember that, sometimes, more is less. You import this many tools into your project, many of them are unnecessary and will not help you completing the project, now they've been download and installed, maybe they're even interfering with other tools. You look at them and starts to think "hey, make be I should learn to integrate and utilize them". Then you wasted an afternoon trying to utilize the tool, but by the evening you realized that in order to use the tool correctly, you must restructure your project. This is not how you can finish things, you know? If you want to write a new project, just `go mod init` it and write the code. And during the writing, if you found the need for some tools, just introduce those tools one by one to fulfill the need. Don't downloading tools or creating "project layouts" just because some tutorial said so.

JetSetIlly 3y ago

That used to be how you started a go project. Unfortunately, modern Go requires you to first setup a go.mod file with: go mod init <project name> Still simple but for better or worse it's now a necessary part of the process.

foldr 3y ago
You can still do go run main.go So no need to init a package if you are just using the stdlib and you’re in a hurry.
- JetSetIlly 3y ago
  I didn't know that. That's genuinely useful to know.