1. 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.

      1. 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.

        1. 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.

          1. 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.

            1. 17

              Easy fix: Don’t complain about existing emails, simply convert the signup into a password reset email and if usernames aren’t public don’t complain or even ask for one until a confirmation mail has been received.

              Username or Email disclosure can be very bad for privacy.

              1. 1

                This just delays disclosure. Eventually, the sign up is gonna fail because the username/email exists. Even if you push it later after an email.

                1. 8

                  Not necessarily. The signup could only continue with access to the targets email service. The attacker doesn’t know if the attack succeeded or not unless they have access to the email address. If that is the case, the entire point is moot anyway since you can click “reset password”.

                  1. 2

                    Let’s say I’m an attacker. I sign up on lobste.rs at hacker@gmail.com, sign up works and I get a confirmation email. I then sign up on lobste.rs with the email tscs37@gmail.com. Because your account exists already, I don’t get an email. The difference, even if it’s something not happening, tells me what I wanted to know.

                    1. 12

                      Yeah but you don’t know if you get an email for tscs37@gmail.com since you don’t have access to that account.

                      You wouldn’t get an email if the account existed or not.

                      1. 0

                        I do know though. I know I didn’t get an email for tscs37@gmail.com. That tells me just as much about the account’s existence if I had got the email.

                        1. 14

                          If you get that mail that implies you have control over tscs37@gmail.com, in which case the entire method doesn’t do anything. But it’s also not valid to say the entire method is therefore flawed.

                          You just gained access to my mail account, you can click “reset password”. Or signup for real. Or just check the emails in the archive folder.

                          If you do not have access to tscs37@gmail then you cannot tell if the email had signed up because you don’t get the email

                          1. 2

                            Ah I see what you’re saying now. Yeah that might work, it wouldn’t work for sites that have usernames, users could only be identified/login with email addresses.

                            1. 2

                              It can work with sites that have usernames, but only for display purposes.

                              So you can still be shown as “travisjeffery” or “ilikedeepthreads” or whatever rather than showing your email all over the place, but thats all it is - display text.

                            2. 1

                              This also takes the step of validating that an email address is active during signup, instead of after signup, which is a huge win, in and of itself.

                            3. 1

                              It tells you that somebody already registered that email address. It does not tell you if that somebody also has a lobsters account.

                          2. 2

                            You didn’t get any email because you don’t control the email account to be able to check it.

                            1. 1

                              Lobsters isn’t a good example for average case because it has a list of usernames. So, you can tell if the name is there. You might not know if it’s the target individual, though. Then, clicking on the profile may or may not tell you more about the individual. You can also social engineer users to find out identity information you might not get from a commercial service without more work and risk.

                              I do agree with you that it’s pointless to hide the username on a site where (a) you can see if it’s take and critically (b) username has something like email that uniquely identifies an individual. Other examples might be their Facebook or Twitter accounts. I’d still default on hiding it in the likely-reusable implementation of login since I can’t know ahead of time whether or not they’ll leak information like that. Secure by default.

                              1. 1

                                If email address was used for login (and usernames only for display) there’d be minimal attack surface there.

                        2. 1

                          This is definitely a good way to prevent those issues. For several times I thought about using this method on some projects.

                        1. 2

                          http://stash.cool/ - the personal finance mobile tool. Digging deep into d3.js.

                          1. 2

                            Working on Stash, the personal finance tool. Currently reading Tutfe and thinking about how to design the UI.