Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go run

breadchris.com

Post reply on HN
Print view View original

141–150 of 173 posts

Re: Go run

#141

Post by dijit »

giovannibajo1 wrote: post #137
IggleSniggle wrote: post #24

Earlier quoted context omitted.

I'm not sure there really is a good technical reason they exist. It's cultural. It basically goes like this: - the inventor of new language 'coolang' has a way that they make their project - it's kinda messy, so they clean it up into a tidy script with a few clear and straightforward commands and/or flags, and give you "cool build," "cool install" for making sure all the necessary dependencies are present, etc - a co…

There's also a technical reason, which is that the build system is written in the language it targets. So the cool tool is written in coolang. That's obviously not required, you could use any programming language for the cool tool, it just happens that all people that care about the cool tool, understand the needs of the ecosystem, have issues with missing features etc. already have a non zero intersection of languag…

A nit (hopefully a welcome one given that it supports your statement) is that Bazel's rules are written in a language called Starlark, which has python syntax just without classes and a bunch of limitations surrounding switch statements and loops.

The core of your point is correct: who wants to both support an additional tool chain and an additional language for building things? Terrible sell.

Go itself is a little bit of an edge case because they recommend leaning on Make, but ironically they do not use Make for its intended purpose and all the (actually good) functionality that Make gives you is reimplemented from within the go compiler.

Re: Go run

#142

Post by dijit »

breadchris wrote: post #62
bjackman wrote: post #14

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 ne…

bazel is pretty cool, I have seen it work at Uber for the go monorepo at impressive scale (and of course it works for google). When I need to scale up the build process this will be the tool i reach for, but for starting out it is another technology that someone would have to learn.

Bazel is one of those tools that either someone teaches you or you need a PhD to figure it out. Which is massively frustrating.

The Opensource rulesets are also not fantastic in my opinion compared to the Google ones, so most peoples first impression of the tool is sub-par.

Re: Go run

#143

Post by brlewis »

BillyTheKing wrote: post #94
brlewis wrote: post #90

This article would have worked a lot better without the second paragraph. The writer's simple pleasure of typing "go run ..." should not be predicated on believing that deno doesn't exist.

is anyone actually using Deno in production for larger projects?

That's missing the point. The article isn't about an advantage for large production projects.

Re: Go run

#145

Post by kunley »

lopkeny12ko wrote: post #68

> Yeah, and then what happens if you want to use modern syntax like esmodule, or maybe you want to use types with typescript? You are going to have to use npm. I don't understand what the problem is here? Every installation of Node comes bundled with npm. If it doesn't, that is a package maintenance problem. > Fun fact: One of the understated features go run is that it will automatically download any dependencies the…

> Every installation of Node comes bundled with npm. If it doesn't, that is a package maintenance problem.

Not really.

Ubuntu's node comes without npm, and to install the latter it wants to get about a hundred of dependencies. Mind you, this is still one of the most popular distros. Would you call their approach "a problem"?

Re: Go run

#147

Post by lenkite »

BillyTheKing wrote: post #123
scubbo wrote: post #97

Earlier quoted context omitted.

> Also, with this comment I hope to get some pushback: I haven't kept up with the latest typescript, python or any other language features. I'm talking from almost a purely ignorant perspective so I hope to learn a bit more on how developing with other languages feels like. Can't push back there - every other language I'm aware of uses at least one (and often both) of "throwing exceptions" or "returning Result types…

how does that work with try/catch? try/catch is significantly more verbose than just if err != nil // do something imo, and also much more brittle. Agree re: Results type in Rust and Ocaml, etc. Those are better in my view too. And yes, you can define a Result return type in Typescript as well (and in fact that's what I mostly when I write typescript and works ok) but unlike Rust this is definitely not 'idiomatic typ…

There is no need to have try-catch at every function invocation. One can do this only at the level at which one needs to handle the error.

In Go, every call made to a function is 5 statements and lines. Go code tends to bloat up the screen quite a bit and eyes glaze over.

    result, err := f()
    if err != nil {
      return nil, err // I don't want to handle this here but at callers.caller.
    }
    return result

Re: Go run

#148

Post by lenkite »

moondev wrote: post #15

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'

Gosh is a dead project currently, right ?

Re: Go run

#149

Post by lenkite »

denysvitali wrote: post #2

`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

Wish `go run` worked for hashbang shell scripts. But you have to do a lot of hacks to make it work like: https://gist.github.com/posener/73ffd326d88483df6b1cb66e8ed1... describes

Re: Go run

#150

Post by bjackman »

breadchris wrote: post #62
bjackman wrote: post #14

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 ne…

bazel is pretty cool, I have seen it work at Uber for the go monorepo at impressive scale (and of course it works for google). When I need to scale up the build process this will be the tool i reach for, but for starting out it is another technology that someone would have to learn.

I think the issue with Bazel may be that it works extremely well at Google where for 80% of the code at the company, building is just a completely solved problem, with amazing tooling integration, and it's glorious.

Whereas in the open source there is much more manual setup to get it working smoothly. And the manual setup is much easier in the tool your ecosystem already knows.

So it may not actually be a wonderful system in and of itself (outside of the Google monorepo). My comment was mainly about the principle rather than an endorsement to adopt Bazel!

Post reply on HN