Live data from Hacker News

Go run

breadchris.com

41–50 of 173 posts

Re: Go run

#41

Earlier quoted context omitted.

Yup. This was the main thing that bit me when I was first getting into Go. File names are kind of like classes, and directories are kind of like modules. The encapsulation sits at a slightly different layer than you might expect.

Your expectations may vary depending on where you come from. There are many places one can come from. It's advisable to minimize expectations or assumptions when learning something new, as they could impede your learning process.

Yes, absolutely. Thank you for clarifying what I was saying. Regardless of where you are coming from, it's likely to be the places where there unstated assumptions / cultural-norms that differ from your own where you will experience the biggest "lift" when encountering a new technology. The more a culture aligns with a "lowest common denominator," the more it will be readily understood, and the less it does, the more it will act as an exclusivity gate.

Either could be desirable or undesirable depending on your goals. It's good to be aware of the dynamics so that you can make an informed choice about how to present your code.

Re: Go run

#42

Earlier quoted context omitted.

Yup. This was the main thing that bit me when I was first getting into Go. File names are kind of like classes, and directories are kind of like modules. The encapsulation sits at a slightly different layer than you might expect.

Your expectations may vary depending on where you come from. There are many places one can come from. It's advisable to minimize expectations or assumptions when learning something new, as they could impede your learning process.

[deleted]

Re: Go run

#43

Earlier quoted context omitted.

Yup. This was the main thing that bit me when I was first getting into Go. File names are kind of like classes, and directories are kind of like modules. The encapsulation sits at a slightly different layer than you might expect.

Your expectations may vary depending on where you come from. There are many places one can come from. It's advisable to minimize expectations or assumptions when learning something new, as they could impede your learning process.

It's natural to have expectations based on your experiences.. I think the person you replied to is just trying to help people who might misunderstand go based on those expectations. I think you're getting unnecessarily deep here.

Re: Go run

#44

Except I cannot `go run ~/that/project/over/there` as the use of go modules means I have to change directory to be inside the package first. I'm not sure why that is exactly, but it's always been a nit I've found frustrating.

Especially when you can `go run that/project/over/there@latest`

Although, with slight modification, you can `go run -C ~/that/project/over/there .`

Re: Go run

#45

Earlier quoted context omitted.

This is a good tip! It also captures what has been frustrating about golang for me. The language feels a bit stuck between simple default cases and allowing complexity. I feel like there are two relatively distinct populations of go developer: those who love how easy it is to start (true!) and those who are frustrated by the compromises the language has made to allow for more complex cases (required!). There's also a…

I don't get it. The default case is simple (go run .), and the complex case (specifying the relevant .go files one by one) is a little bit more complex. What's frustrating with that?

> I don't get it. The default case is simple (go run .), and the complex case (specifying the relevant .go files one by one) is a little bit more complex. What's frustrating with that?

The problem is many Go tutorials start out by teaching the complex case first and leave the simple case to later (if they cover it at all).

Re: Go run

#46
Wait until you discover `nix run`. If I want to one-shot a command and not even worry about dropping into and out of a shell: `nix run nixpkgs#file some_mystery_file.xyz` will do the trick.

Re: Go run

#47
You can build the equivalent simple c++ program by just calling `make` with no arguments.

Though TBF then you have to type ./a.out, and so then you want to do `make && ./a.out` and then...

Re: Go run

#48
post #6

I don't think it's simple. Just `go run` would be far more simple. Right now I first have to figure out if its `go run .` or `go run cmd/main.go` or some other thing.

Or, even better, `./main`

Re: Go run

#49

Earlier quoted context omitted.

I don't get it. The default case is simple (go run .), and the complex case (specifying the relevant .go files one by one) is a little bit more complex. What's frustrating with that?

> I don't get it. The default case is simple (go run .), and the complex case (specifying the relevant .go files one by one) is a little bit more complex. What's frustrating with that? The problem is many Go tutorials start out by teaching the complex case first and leave the simple case to later (if they cover it at all).

Maybe it is because the simple way requires knowledge of packages, which are covered later perhaps, since many tutorials go straight to "go run helloworld.go"

Re: Go run

#50

Except I cannot `go run ~/that/project/over/there` as the use of go modules means I have to change directory to be inside the package first. I'm not sure why that is exactly, but it's always been a nit I've found frustrating.

[deleted]
Post reply on HN