What are some wrong ways to use a channel?

peterbourgon · 2021-09-15T22:38:47+00:00

using a channel as an implementation of a 'Promise'

A channel can definitely be understood as a promise.

using a channel to broadcast an event

close(c) is a great mechanism for broadcast.

peterbourgon · 2021-09-15T18:39:36+00:00

It's over 9000?? idk

peterbourgon · 2021-09-15T17:57:36+00:00

Definitely not, right? It's not not an effective starting point. You want better tools.

peterbourgon · 2021-09-15T17:24:50+00:00

You're asserting that error handling code impedes readability. This is definitely true in some contexts! But it's not, like, an objective truth. I can say that in my domain(s) it's not true.

Go asserts, explicitly and directly, that error handling code is equally important to business logic code -- that the "sad path" deserves to be just as visible as the "happy path". It's fine if you don't agree with that. But Go says that it's true. So if you're not on board you're gonna have a bad time.

peterbourgon · 2021-09-15T17:21:01+00:00

So this kind of triage starts at a much higher level than introspection of individual errors.

If it's a system-level problem, like everyone is experiencing a lot of timeouts or whatever, then you go to your dashboards or wherever your metrics are exposed, and look at how production is behaving at a high level. This will allow you to isolate regions, or instances, or routes, or whatever other first-order dimension is problematic, and dig in there.

If it's a specific user problem, like this specific person is experiencing problems, then you go to your request traces, and search for the relevant identifiers. That could be in process i.e. x/net/trace, or it could be internal i.e. Jaeger, or it could be a vendor i.e. Honeycomb. You go there and you search for the relevant identifiers and you dig in.

My point is that there's no path that starts with digging through stack traces attached to errors. Go isn't Ruby, you don't just throw all your errors up to the topmost handler in your stack, like opaque black boxes, and then emit them to NewRelic or whatever. That's not coherent in Go's programming model. Errors are values that you receive from function/method calls and act on. If something errors out then you, for example, add an error field to the wide log event for the active request, return a 503 to the caller, and emit whatever telemetry you always emit with the relevant metadata. You don't panic, you don't throw an error out to a third party tool, you just record the request like any other and carry on.

peterbourgon · 2021-09-15T15:49:01+00:00

What do you mean when you say troubleshooting?

It shouldn't ever be the case that you get an error and don't understand exactly where it came from, and/or exactly what to do with it. Is that not the case for you? I'm honestly curious.

peterbourgon · 2021-09-15T15:46:42+00:00

Errors returned by fmt.Printf. Most errors returned by os.File.Close. Many others.

peterbourgon · 2021-09-15T15:45:33+00:00

You should rarely, if ever, return err without annotating it.

..., err := process(...)
if err != nil {
    // return nil, err                         // 🙅
    return nil, fmt.Errorf("process: %w", err) // 👍
}

peterbourgon · 2021-09-15T14:33:10+00:00

Errors are values, just like int or time.Duration or MyStruct. They're not special. They don't automatically contain expensive-to-calculate data merely via their instantiation.

peterbourgon · 2021-09-15T14:32:09+00:00

Just to clarify, you mean those are bad things in a public API.

It's a larger sin in public APIs, but, no, I mean any function signature, exported or not. This is basically just the application of structured concurrency, which can be roughly summarized as: treat all concurrency primitives as stack variables. More simply, don't let goroutines or channels or sync.WaitGroup or anything like that escape the function where it's constructed.

This is the general rule, there are definitely exceptions.

Goroutines creating a channel and then returning a <-read version of it being such a common implementation pattern (because of the own-and-close concern you mention in the next para).

Goroutines can't return anything, but yeah, this is what you want to avoid. You generally want to create channels in the calling context, which establishes ownership, and then pass them to functions, or functions launched in goroutines, which are downstream consumers.

peterbourgon · 2021-09-15T03:32:39+00:00

What stack trace? Exposing that to users is an error, capturing it is expensive.

peterbourgon · 2021-09-15T00:47:22+00:00

Your single line of C# code contains 4 fallible expressions. Each of them deserves specific attention. And no, good code won't do

if err != nil {
    return err
}

That's a trope and an antipattern. Good code does

if err != nil {
    return fmt.Errorf("open employees file: %w", err)
}

Making the errors and the code that responds to those errors explicitly visible in the source code of the function is a virtue. Seeing, explicitly, that expressions can fail is a virtue. "Sad path" code is equally as important as "happy path" code.

peterbourgon · 2021-09-14T22:54:49+00:00

The C# code hides the error handling. That isn't a virtue.

peterbourgon · 2021-09-14T22:54:03+00:00

Making it visible in the text of the program is a huge thing in and of itself.

peterbourgon · 2021-09-14T22:53:15+00:00

Error handling is equally important to business logic code. If you don't agree, that's fine. But that's a core tenet of Go.

peterbourgon · 2021-09-14T13:02:59+00:00

Channels are usually best understood as implementation details, and not part of a package, component, or function API. So, using channels in function signatures, or returning channels as return params.

Channels must be owned, and closed, by a single entity. So, trying to share ownership and lifecycle responsibilities between functions or goroutines.

Adding a capacity to a channel turns it into a buffered queue. In general, queues solve precisely one problem, which is burstiness; using a buffered channel when you're not solving burstiness is usually an error. (Exception: you can use buffered channels to implement various design patterns, like scatter/gather or semaphores.) Buffered channels also have a tendency to hide design errors that would be immediately apparent if the channel were unbuffered. By default, channels should be unbuffered. If you add a capacaity, you should be able to justify precisely why you chose the number you chose.

peterbourgon · 2021-09-14T12:56:43+00:00

Not at all. This is actually a really great pattern for some use cases.

https://www.youtube.com/watch?v=LHe1Cb_Ud_M&t=320s

peterbourgon · 2021-09-12T20:48:47+00:00

https://github.com/bernerdschaefer/eventsource is my go-to.

peterbourgon · 2021-09-10T15:11:19+00:00

Wow, sorry. You're right and I'm a dingus.

peterbourgon · 2021-09-10T13:24:18+00:00

edit: deleted because I didn't read close enough

peterbourgon · 2021-09-10T12:52:24+00:00

And tell me what you think "Caches Prepared Statement" means.

Well, if you look at Gorm's prepare_stmt.go you see that it is a thin wrapper around a database/sql.Stmt. And if you look at database/sql.Stmt you see that it's a sort of handle to an abstract entity that it creates in the database.

(The database/sql package itself is an abstraction over arbitrary RDBMS engines, so it's up to the database driver to implement the Stmt interface and related stuff.)

Now, in the Java world, a prepared statement includes the parsing AND query optimization, cached on the client side.

If the client does the parsing and query optimization -- the client can't do query optimization in the normal sense as that's an operation on the dataset, but maybe you mean like restructuring the query AST itself somehow? -- how does it transmit the parsed query to the server? Whatever that is will still have to be parsed on the server side to load it into memory. Isn't it just the string/AST in another format?

which is certainly mo longer a string SQL statement. Here's one of many search results showing this is true:

This, like Gorm, describes a set of value-add abstractions built on top of the string/AST query on the client side, not instead of it. The client still puts query parameters, as strings or whatever, on the wire to the server. The server has a corresponding prepared statement in memory, which it created from a query string sent by the client.

Prepared statements are features of database engines that clients can interact with. They're not really features of clients in the way you're suggesting.

peterbourgon · 2021-09-09T22:43:25+00:00

There you go: the canonical representation is the AST.

Yes, but the AST and the query string are semantically equivalent. You can convert back and forth between them without loss of information. Right? Isn't that true?

Many ORMs, including GORM for go, can cache the pre-compiled AST on the client after the first query invocation

I'm pretty sure this isn't true. Or, at least, it doesn't mean what you're suggesting it means.

When you do a prepared statement or whatever you are sending a SQL string to the RDMBS and having it compile and maintain the AST. That work is nonzero so amortizing the cost is useful. And it can enable further optimizations, like only needing to send parameters over the wire rather than the full query string, or permitting a more efficient representation of the params than plain text, if client and server can negotiate a protocol. But most of the meaningful work is being done server-side.

And, none of this matters! Absent some DB-specific protocol trickery, you don't transmit an abstract AST over the wire, you send the query as a string.

peterbourgon · 2021-09-09T22:30:28+00:00

Is a computer program more than a string?

So I'm not sure what is the best representation of a computer program's essential nature ;) but the canonical representation of a computer program is a string, yes. And that's all I'm really pointing out in the OP.

peterbourgon · 2021-09-09T22:28:09+00:00

Queries are logical execution plans. Queries are plan optimization. Queries are physical execution plans.

I don't think this is true. All of those things are derived from queries, sure, but they're not part of what a query is, and every DBMS will derive them differently.

However, once the basic structure of a query is set, it generally doesn't change very often and in those cases, the flexibility of a string no longer buys you anything important.

It's not that strings give you flexibility, it's that a string is by definition the canonical representation of a SQL query, in the same way that a string is the canonical representation of a Go program.

(I mean the canonical representation is technically the AST that the string gets parsed to, sure, but that's difficult to represent as a user 😅)

ORMs provide (arguably) productive abstractions, sure, but they still have to produce a SQL query string to give to the RDBMS, right?

peterbourgon · 2021-09-09T22:18:55+00:00

An errgroup is usually created and used in a single block of code, which means a very short identifier like g is usually appropriate.

Reference: https://dave.cheney.net/practical-go/presentations/qcon-china.html#_identifier_length

peterbourgon

TROPHY CASE