Go: Google's Plan9 refugees are staging a breakout

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Go: Google's Plan9 refugees are staging a breakout

skul-gun: Dec 24, 2001; I got this account for Xmas.

Winkle-Daddy posted:

Thanks! I'll see if this is easier to work with next. I have a project where I'll need to spin off a large work load into various go routines and then organize them, so I'm just creating super small examples to help get my brain around how this all works.

You might find these presentations/articles helpful, if you haven't seen them already:
Go Concurrency Patterns
Advanced Go Concurrency Patterns
Go Concurrency Patterns: Pipelines and cancellation
Go Concurrency Patterns: Context

# ¿ Jun 27, 2016 23:33

Adbot: ADBOT LOVES YOU

# ¿ May 5, 2024 17:35

skul-gun: Dec 24, 2001; I got this account for Xmas.

Twerk from Home posted:

The impression that I get about Go is that it's excellent at concurrency and bad at parallelism, somewhat like a strongly-typed NodeJS. Am I wrong? I've been looking for a chance to do some real work using Golang but the project I'm about to start has a serious need for parallel computation so I'm thinking I'll just try C# on .NET Core or Kotlin.

I guess that depends on how you mean "bad at parallelism." Go programs aren't stuck to being single-threaded as with node. There is a setting (GOMAXPROCS) that controls how many OS threads can be used to execute goroutines. GOMAXPROCS used to default to 1, but now defaults to the logical number of CPUs.

But if you're looking for built-in utilities like java.util.concurrent, no, go doesn't have those.

I hope that helps.

# ¿ Jun 27, 2017 17:53

skul-gun: Dec 24, 2001; I got this account for Xmas.

DukeDuke posted:

Is there a way to hook up a middleware of type �func(http.Handler) http.Handler� (like gorilla/mux uses) to a Gin router?

I have not used gin, but it seems like you should be able to wrap an http.Handler:

code:

func wrap(h http.Handler) gin.HandlerFunc {
	return func(c *gin.Context) {
		h.ServeHTTP(c.Writer, c.Request)
	}
}

# ¿ Jul 4, 2020 07:43

skul-gun: Dec 24, 2001; I got this account for Xmas.

Go modules are identified by url. From their go.mod, go.senan.xyz/gonic is the official name of the module. One reason to use your own domain is to not be tied down to one code hosting site. Another example of a project that uses its own domain is k8s.io/kubernetes

Checking out the git repo and compiling from there is totally fine. But I would point out that for the dependencies specified in gonic's go.mod, the go tool is effectively doing "go install ..." (actually go get) for each of those, and that's normal.

skul-gun fucked around with this message at 10:26 on Aug 31, 2023

# ¿ Aug 31, 2023 10:16

skul-gun: Dec 24, 2001; I got this account for Xmas.

fletcher posted:

So at least installing from source (using the naive way described above) I would just have to worry about somebody re-tagging a compromised revision of the code. That's easy to handle though - I can just switch to a copy of the code that I've frozen at a point in time. Assuming I also do the same for all the dependencies, of course.

Have a look at the gonic go.sum file. The go tool uses this file to verify the integrity of gonic's direct and indirect dependencies. Additionally, the go project runs a module proxy/mirror/checksum database, which the go tool uses by default.

So let's say one of gonic's dependencies secretly re-tags a release. If the go module proxy has already seen the module at that version, you'll get a checksum error. Even if the proxy hasn't seen the module before, there's still the checksums committed to the gonic repository. Here's an example I found on github of what a checksum error looks like: https://github.com/ameshkov/dnscrypt/issues/7

# ¿ Aug 31, 2023 20:11

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Go: Google's Plan9 refugees are staging a breakout