1. 10
  1.  

  2. 6

    I’ve begun using pkg. […] And I need not explain why I don’t use pkg anymore.

    So do you use it, or not?

    1. 7

      I do. I don’t have to explain why I don’t use pkg anymore because I do.

      1. 4

        Oh, this took me some time to parse. Thanks.

        1. 2

          It really isn’t clear.

          1. 1

            I think a lot of it is a modal/AmE thing, “need not” seems more common in BrE and older English. I’ve switched to AmE very to help make the sentence easier to parse. Also, I’m giving the facts and testifying how I see things so others can think about it and make their own decision. Compared to that, what I do isn’t important.

            1. 1

              Maybe I’m not understanding but I think:

              And I need not explain why I don’t use pkg anymore.

              Should really be:

              And I won’t have to explain why I don’t use pkg anymore.

              But given that the summary list was saying ‘you’, it should be:

              And you won’t have to explain why you don’t use pkg anymore.

              1. 2

                “Don’t need to” and “don’t have to” are synonymous, same with “need not” and “don’t need to”. Style is the difference. But the consistent first/second person inconsistency is bad. I updated to use first person consistently.

                1. 1

                  They’re not synonymous. I need to eat, but I don’t have to eat.

      2. 4

        Sorry for being dense, but I read the whole article and still dont get it. Are you using pkg just to stop the nagging, or actually another reason?

        1. 2

          With that said: I’ve begun using pkg. pkg is consistent with cmd and internal and other non-package directories. You know what packages contain Go code and which don’t. You structure your project without making all your packages internal.

          In other words; to add structure to your projects without making all your packages internal/private, make the layout of your packages consistent when you use the cmd directory or have other non-package directories at your project’s root, stopping the nagging is a bonus.

          1. 2

            And what are the downsides of using pkg? That wasn’t totally clear to me either even after reading the article.

            Just that they’re “empty” and don’t serve any compiler or naming related purpose? Is that the only complaint or is there another one I missed?

            1. 2

              Main issue is that “pkg” will be in your import paths. But some people don’t like their project’s having pkg in the project’s tree either.

        2. 1

          Project structure seemed, to me, to be a big community discussion and in some places disagreement, during my short sojourn with Golang. I didn’t write enough projects to have an opinion on the matter. Maybe communities like this need to have these kinds of small disagreements, project structure taking the place of the normally opinionated discussions on tabs vs spaces and different code formatting.

          Edit: spelling

          1. 2

            I’d thought about that and I added a paragraph, second-to-last, talking about this:

            Go popularized no-style programming. We all defer to gofmt. Rob Pike coined the proverb: “Gofmt’s style is no one’s favorite, yet gofmt is everyone’s favorite,” Pike continued, “A lot of people say—especially beginners—I want to move the braces; why tabs instead of spaces? Or whatever. [And I say] Who cares? Shut up.” Go is not a there’s more than one way to do it language. There’s one way to format code, one way to write a loop, one way to increment a number. But before you code Go you must decide how to lay out your project. Most popular language communities have layout conventions: Rust , Python , Java , Ruby . Rust has rules that say: Name an executable’s main source file src/main.rs. Name a library’s main source file src/lib.rs. Put other executable flies in src/bin/.rs. Rust programmers think about project layouts like Go programmers think about code formatting—they don’t. Java, Ruby. Rust has rules that say: If your package is an executable, name the main source file src/main.rs. If it’s a library, name the main source file src/lib.rs. Files in src/bin/.rs are executables. Rust programmers think about project layouts like Go programmers think about code formatting—they don’t.

            1. 3

              This is a glaring hole, and one of the biggest pain points using Go, especially on a team.

              For a “one way to do things” language, having almost no guidance on one of the highest level decisions (package layout and file organization) is just odd. I guess the Go team’s reply might be, “well, it doesn’t matter, do it how you want,” but it really does matter, it wastes a ton of time, and creates inconsistencies both within and between projects.

              If you want sanity around this issue, you are pretty much forced to invent your own guidelines or adopt one of the community guidelines like the one linked in your article. I’d really like to see official guidelines.

          2. 1

            This post seems to miss the point of internal. It’s special because it allows authors to restrict who depends on their code. It can also be used anywhere in the go package. It’s not an either/or situation. Use pkg if you follow that convention and also use internal to give you freedom to change your code without breaking your users.

            1. 1

              You use internal directories to make packages private. If you put a package inside an internal directory, then other packages can’t import it unless they share a common ancestor. Internal packages enable you to export code for reuse in your project while reducing your public API. Russ Cox, in his proposal for internal packages, used the standard library as an example of where you want them.

              I then talk about how the way people use internal is more nuanced.

              1. 1

                Your piece should make it clear that they are not alternatives but complementary.