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

101–110 of 173 posts

Re: Go run

#101

Post by Zababa »

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 agree, especially since 'go build', 'go install', 'go test', 'go generate', 'go vet', 'go fmt', etc will do what you expect when you run them without parameters. I think the difference may be that 'go run' expect one package to run, while the others can take multiple. If you have a library (no top-level main package) that comes with two tools foo and bar, I don't think 'go run' could know which package to run. Example tree:

    go.mod
    go.sum
    library.go     // package library
    cmd/foo/foo.go // package main
    cmd/bar/bar.go // package main

Re: Go run

#102

Post by maerF0x0 »

999900000999 wrote: post #88
bottlepalm wrote: post #67

Earlier quoted context omitted.

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?

Rust is also really really hard. A lot of this is just syntax, but I've just about come to the conclusion that I'm too stupid to learn it. Golang is very easy, I can generate small binaries to do cool things without too much code. Typescript is dragged down by the legacy of JavaScript, things randomly break all the time, configuring babel is the stuff of nightmares.

I felt the same way about rust until I started working on https://google.github.io/comprehensive-rust/ and in a couple days have wrote several working rust programs.(trivial ones)

It took me from a couple years of "I should learn rust" to "I've written some rust and ran rust programs" in a few hours.

Re: Go run

#103

Post by maerF0x0 »

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?

I look at Go like Python + multicore world. (and nice to have speed from compilation vs JIT). And in my career that's almost exactly what we've used it for: rewriting higher load services from Python (2.7 at the time) to Go.

Re: Go run

#104

Post by jitl »

winrid wrote: post #98
jitl wrote: post #95

Earlier quoted context omitted.

If Node/Typescript isn't performant enough, you need to move a lot of bytes around, but training a developer team on Rust seems like a massive organizational expenditure. Go is probably the most efficient language for 0 -> Production. The standard library has everything you need to build a production backend service. There's zero build system shenanigans. Anyone who's seen a C-like language can start writing mediocre…

I mostly agree but... you can't use worker threads or something with Node to distribute the work? It's only like one line to submit a job to a worker thread, how is that much more than "go thing()"?

There’s tools for parallel execution in Javascript like Worker or node:worker_threads but they have two big drawbacks that make them somewhere between annoying and useless:

1. No shared objects between threads. You can share non-resizable contiguous byte arrays (SharedArrayBuffer) but 98% of existing code makes normal objects and arrays, and if you want to send those to another thread, you pay a serialization memcopy round trip (no cast a buffer in this language). This severely limits threading to “shared nothing” style workloads. Can you pass a node HTTP request to another thread? No :(

2. Each thread worker needs to boot up from scratch from its own entry point file. This forces some pretty weird code layout and imposes a big boilerplate overhead as well as runtime overhead. And remember - no sharing! So if your threads need a common resource like a Postgres connection pool, they’re going to create their own copy.

Re: Go run

#105

Post by breadchris »

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…

> 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.

Node and npm are two commands, and when you go to find packages, you will see people telling you to use pnpm, yarn, or npm. I would expect one tool to do this for me, especially for the most popular language in the world.

> 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, like "npm install"?

https://chat.openai.com/share/8bd82c15-c939-4e82-aad8-086995...

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

I find this to lend itself to a more decentralized future. I see notable projects owning their code and distributing it positively. You still need the source code for something to run at the end of the day. If you are worried about the code continuing to be there, that is the purpose of a proxy cache, which makes it very easy: https://proxy.golang.org/. Also, the code is distributed on github. So, if github working is a concern, we probably have much bigger problems.

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

A hammer looks like a hammer because that is the most effective way to hit a nail. Since I am "building" code, I want my tools to feel as reliable as a hammer. I will not argue that Go is the best language ever invented; I see it as the most accessible language to make things happen fast and reliably until a better one emerges. When that happens, AI-generated refactoring tools will be so good, and Go code is so quickly parseable that I will let it loose in my Go code bases to refactor them into that language.

Re: Go run

#106

Post by reactordev »

throwway120385 wrote: post #38
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.

As an embedded developer I shudder to think of all of the work that would go into /runtime run source/ to have it build objects, link them into some kind of format, convert the format to a series of flash addresses and data, connect to my JTAG over a network, halt execution, erase the flash, load the executable file into flash, verify the load, and try to signal a PMIC or other chip to reset the device to start it ba…

As I stated, for C/C++ - folks like their build systems the way it is.

For everyone else, they want runtime run sourcefile and can then build scripts around that to package it up how they want to. For local development, I shouldn't have to wait 40 minutes for a compile to see a div change.

The toolchains that would benefit from being able to run quickly, compile quickly, are what we want. Having to do 15 steps to get your code on an embedded device is just part of the territory. The rest of us have pipelines.

Re: Go run

#107

Post by tapirl »

"go run" was a great way to run go code as scripts. But maybe it is not now. Why? because Go 1.22 introduced a change that breaks backwards compatibility (changing the semantics of "for;;" loops). Without language version specified (such as in go.mod files), the change will often cause unintended damage.

Re: Go run

#108

Post by NewJazz »

cpuguy83 wrote: post #12
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.

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.

Temporary gopath, "go install ./...", list contents of bin.

Re: Go run

#109

Post by triyambakam »

randomdata wrote: post #92
bottlepalm wrote: post #67

Earlier quoted context omitted.

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?

> 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`

Re: Go run

#110

Post by lloeki »

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

Isn't it supposed to be `go run ./...`?

(long time I didn't use Go, back then at least, using `.` instead of `./...` could cause subtle issues)

Post reply on HN