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

61–70 of 173 posts

Re: Go run

#61

Post by skybrian »

cxr wrote: post #55

> One of the understated features go run is that it will automatically download any dependencies the code references; how cool is that! All this plus talk about non-standard JS runtimes like Node, but no mention that this is how browsers have worked almost forever.

JavaScript started out as an interpreted language but ended up more like a compiled language due to minifying, TypeScript, JSX/TSX, and so on. So it's not simple anymore.

At this point, URL imports are actually bad due to the confusion between source and compiled code. Ideally, imports should always point to source code. Bundling / minification should happen at the application level; it's not a library concern.

So in that sense, Go's a lot cleaner since it's always been a compiled language.

Re: Go run

#62

Post by breadchris »

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.

Re: Go run

#63

Post by declan_roberts »

I love it! Go is simple. Sometimes too simple, but that works for me.

I do see makefiles periodically like the author notes, but that’s almost always related to secondary build objectives, such as cross-compile or containers etc.

Re: Go run

#64

Post by declan_roberts »

IggleSniggle wrote: post #27
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

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.

In many ways this just took what people were already doing with other languages and codified it.

The main benefit is that you can easily figure out what is where!

Re: Go run

#65

Post by shpx »

Clicking is my favorite part of JavaScript. I just move my mouse onto some blue text and click and the software that I want to use is installed/updated and runs, usually in under a second.

In the 50+ year history of software development I haven't heard of any other software stack has been able to realize this is important. go run is close but it's still 10 times slower, maybe even 100 times slower, depending on if you want to count the git clone and how good you are at typing.

Re: Go run

#66

Post by 999900000999 »

Golang is such a elegant language.

But comparing it to JavaScript isn't fair. JavaScript has paid my bills for years, but it's held together by collective hope.

The only thing missing is a decent mobile framework. I'm using Fyne, but it just looks dated. At least for my current app it's functional though.

Re: Go run

#67

Post by bottlepalm »

999900000999 wrote: post #66

Golang is such a elegant language. But comparing it to JavaScript isn't fair. JavaScript has paid my bills for years, but it's held together by collective hope. The only thing missing is a decent mobile framework. I'm using Fyne, but it just looks dated. At least for my current app it's functional though.

Eh, I still don't get it.

Go seems too high level for low level work - use Rust, manage your own memory, no garbage collector.

Go also seems too low level for high level work - use TypeScript with all the nifty ES6 features, powerful type system, exceptions, etc..

Where does Go fit in here?

Re: Go run

#68

Post by lopkeny12ko »

> 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 code references; how cool is that!

This feels like a massive antipattern. Why is this lauded as a "feature"? Why do I want my build system to automatically reach out to the Internet and download random code, without an explicit request to do so like "npm install"?

This is even more antipattern-ish when you consider that Go dependencies are literally just repos on Github (or possibly on some random git server), instead of a centralized and moderated registry like npmjs.org.

> amazing, for js we not only have npm, yarn, pnpm, and bower (am I missing any?) but we also have completely new runtimes bun and deno.

So it's now considered bad to have multiple implementations of an open standard, compared to the exclusively-Google-developed Go runtime? This sounds akin to arguing in favor of a monopoly over a competitive market with consumer choice.

Re: Go run

#69

Post by pkilgore » 

    $ cat helper.mjs
    export const sleep = (dur) => new Promise(resolve => setTimeout(resolve, dur))

    $ cat main.mjs
    import { sleep } from './helper.mjs'
    await sleep(1000)
    console.log("Go is great; but weird throwing node under a bus here?")

    $ node main.mjs
    Go is great; but weird throwing node under a bus here?

Re: Go run

#70

Post by cxr »

skybrian wrote: post #61
cxr wrote: post #55

> One of the understated features go run is that it will automatically download any dependencies the code references; how cool is that! All this plus talk about non-standard JS runtimes like Node, but no mention that this is how browsers have worked almost forever.

JavaScript started out as an interpreted language but ended up more like a compiled language due to minifying, TypeScript, JSX/TSX, and so on. So it's not simple anymore. At this point, URL imports are actually bad due to the confusion between source and compiled code. Ideally, imports should always point to source code. Bundling / minification should happen at the application level; it's not a library concern. So in…

Go (the language) is a lot "cleaner" (than JavaScript, the language—and not the various runtimes, previously mentioned in the earlier comment), because with Go (the language), there's more code mangling going on.
Post reply on HN