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

111–120 of 173 posts

Re: Go run

#111

Post by breadchris »

floating-io wrote: post #81
breadchris wrote: post #39

Earlier quoted context omitted.

have you ever used tinygo? I have been curious how much that project gets used. It seems to me that rust is probably going to be the language of choice some point in the future.

I looked at that recently for a project I'm working on, but walked away when I found that important parts of the net package are pretty much nonexistent on ESP32. You know, like net/http, for example... I might have misread the docs, but somehow I doubt it.

yeah it looks like you are right: https://arc.net/l/quote/veycnsqt

Re: Go run

#112

Post by kitd »

bottlepalm wrote: post #67
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?

Go fits in well in the backend where Java would have been, but with a better stdlib, simpler tooling and a smaller deployment footprint.

IMHO it's great for docker-based services. And that's a pretty big marketplace.

Re: Go run

#113

Post by sangnoir »

declan_roberts wrote: post #64
IggleSniggle wrote: post #27

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.

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!

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

Navigating unfamiliar Go codebases yields very few surprises: things are almost always where I expect to find them, and it's great! This is hardly the case with other languages, where I have to rely on grep or trace function-calls

Re: Go run

#114

Post by mariusor »

mqus wrote: 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.

> I don't think it's simple.

I mean, it kinda is. If you're a Go developer that went further than hello world, you will probably be aware of these two possibilities:

If . contains a "main" package then it's "go run .", otherwise the source for the binaries probably reside in "./cmd/X" and you have to run "go run cmd/X".

You can probably find Go projects that don't follow these rules, but I doubt anyone would want to interact with them.

Re: Go run

#115

Post by mseepgood »

ktm5j wrote: post #43
mseepgood wrote: post #36

Earlier quoted context omitted.

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.

In that case, it would have been necessary to specify the language they come from. The only hints given were 'classes' and 'modules'. Is it Java, Python, JavaScript, C++, Swift, Ruby, VB.NET? All these languages have classes and modules, and they all draw the line of encapsulation at different layers.

Re: Go run

#116

Post by todd3834 »

Sadly I haven’t been able to write any production Go for a few years now after switching companies. However, I got bit by the seemingly innocent _platform.go “feature”. I had a file that organized a bunch of windows for a cross platform GUI app. Well it turns out something like file_windows.go only compiles on windows. Our CI environment was compiling all the code but suddenly all platforms except windows started failing.

Was funny when it was diagnosed but not so funny for the time where I was deeply confused why things broke.

Re: Go run

#117

Post by bjackman »

reactordev wrote: post #35
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…

The build system should come with it. Even if it requires me to follow conventions, it’s magnitudes better than rolling my own. I can add to it if I need to. The worst offenders are C and C++ projects. Make? CMake? You’re on your own. During development, it’s so good to be able to just runtime run source like in go and bun.

Make and CMake are not examples of what I was talking about!

In Bazel (and, I assume, other similar systems), you can just "bazel run target" and it always works. Doesn't matter what languages the thing is written in.

Make and CMake are certainly not like what. (Yes, you can have a "run" target, but that's not the same thing).

So my minor gripe is that 'runtime run source' does not need to be a per-runtime thing.

Re: Go run

#118

Post by ReleaseCandidat »

triyambakam wrote: post #109
randomdata wrote: post #92

Earlier quoted context omitted.

> Where does Go fit in here? Where you move past academic language discussion and start using the tooling. Typescript is a pretty nice language but the tooling around it is practically unusable. It's laughable how bad it is. Outside of browser work, you're going to pick Go – and still would even if they made the language 10x more flawed – over Typescript every time just to not have to deal with that ecosystem. Grante…

Can you elaborate on what's hard about TS tooling? It's really easy to just use `npx tsc`

What in practice causes the most pain for mé are the various module formats in combination with TS. Just getting my test runner (Mocha) and Node and the bundler and... to work with TS and the chosen module format is always _not_ fun. Combined with package updates that break the current working solution because they now natively support es modules. I hope these problems will all disappear in the future, but I'm somewhat sceptical. And TS is slow - not C++, Haskell and Rust slow, but still. But I never used TS/Node for anything big (backendy), but just small frontends and VS Code extensions, where the time of getting everything set-up to work takes a relatively larger part of the "actual" work.

Re: Go run

#119

Post by SPBS »

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

Fun fact: `go run .` was retrofitted on after `go run main.go` because go run was initially designed to only accept explicit filenames as an argument [1]. I can't imagine how people used to use `go run` without the ability to specify whole packages (globs don't work well because it includes test files as well).

> Potential design based on discussion with proposal review:

> go run [go flags] [single-package-or-*.go-list] [subprocess flags]

before that it was just

> go run [go flags] [*.go-list] [subprocess flags]

[1] https://github.com/golang/go/issues/22726

Re: Go run

#120

Post by 8n4vidtmkvmk »

bjackman wrote: post #117
reactordev wrote: post #35

Earlier quoted context omitted.

The build system should come with it. Even if it requires me to follow conventions, it’s magnitudes better than rolling my own. I can add to it if I need to. The worst offenders are C and C++ projects. Make? CMake? You’re on your own. During development, it’s so good to be able to just runtime run source like in go and bun.

Make and CMake are not examples of what I was talking about! In Bazel (and, I assume, other similar systems), you can just "bazel run target" and it always works. Doesn't matter what languages the thing is written in. Make and CMake are certainly not like what. (Yes, you can have a "run" target, but that's not the same thing). So my minor gripe is that 'runtime run source' does not need to be a per-runtime thing.

I use Bazel's friend at work but can't imagine using it without also having build_cleaner. Is there an equivalent in the wild?
Post reply on HN