[HN Gopher] Go Run
___________________________________________________________________
Go Run
Author : breadchris
Score : 39 points
Date : 2024-02-21 22:17 UTC (43 minutes ago)
(HTM) web link (breadchris.com)
(TXT) w3m dump (breadchris.com)
| denysvitali wrote:
| `go run main.go` breaks if your `main` module is divided into
| multiple files.
|
| Use `go run .` instead - it's shorter and it works with multiple
| files
| pizzafeelsright wrote:
| Huh. Learned something today. Thank you.
| pizzafeelsright wrote:
| Huh. Learned something today. Thank you.
| JBorrow wrote:
| This isn't a benefit of go, but rather a drawback of the counter-
| example of typescript... All tools generally designed to work for
| creating small utilities ({ba,z,...}sh, python, perl, go, swift,
| ...) have this feature.
| parkcedar wrote:
| Most of these examples don't automatically fetch the
| dependencies. Having come from Python, Go's tools are notably
| simple.
| pdonis wrote:
| _> Most of these examples don't automatically fetch the
| dependencies._
|
| Quite frankly, I don't _want_ to automatically fetch
| dependencies _at the same time I am running the code_. IMO
| those should be separate steps, and combining them together
| in one is not a good idea.
| codegeek wrote:
| Why not ?
| cpuguy83 wrote:
| "go mod download && go run ."
|
| What's the point in making `go run` error out when it
| already knows what dependencies to get and how to get them.
| skybrian wrote:
| For TypeScript, "deno run" seems much the same?
|
| (It's only a subset of the JavaScript ecosystem, but you can
| import a lot of npms nowadays.)
| mqus wrote:
| 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.
| cpuguy83 wrote:
| This one was voted down but there is a good point here. There
| is no way to figure out what binaries there are (maybe you
| could make `go list` show all the `package main`s?, not sure).
|
| Beyond that there's no way to discover what build flags may be
| needed to give you the binary that the developer intended. Be
| it tags, ldflags, cgo support.
| madeofpalk wrote:
| > _Yeah, and then what happens if you want to use modern syntax
| like esmodule [...] You are going to have to use npm._
|
| Why? Node's had built-in support for ES Modules for eons now.
|
| Everything's easy when you stick to default tooling, _duh_ , like
| `node run.js` or `go run.go`. You'll loose that `go run.go` the
| moment you need code generation.
| bjackman wrote:
| It's not really a Go thing but a build system thing. It's useful
| to have your build system know what is an "executable target" and
| how to run it.
|
| Bazel does this for _all_ languages. I'm sure most other modern
| generic build systems do too.
|
| AFAIK "go run" is trivial and for single-file scripts it's fine.
| But for more complex cases (like the NPM equivalent thing) I
| actually think it's a bit of a shame that it's even needed. I
| don't really know why we have per-ecosystem build systems (Maven,
| Go, cargo, whatever the hell you're supposed to do in Python
| these days, the nebula of web front-end tooling, etc etc).
|
| Admittedly I do not really know the ins and outs of any of these
| systems in detail. I'm sure there are some good reasons why they
| exist under the hood.
| moondev wrote:
| combined with gosh - a golang shell interpreter it's pretty easy
| to create scripts that run on all the platforms and
| architectures, even future targets go run
| mvdan.cc/sh/v3/cmd/gosh@latest -c ' go run
| github.com/mikefarah/yq/v3@latest n foo.bar.hello world | go run
| github.com/cezarsa/glolcat@latest'
___________________________________________________________________
(page generated 2024-02-21 23:00 UTC)