Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Context should go away for Go 2 (2017)

faiface.github.io

Post reply on HN
Print view View original

161–170 of 176 posts

Re: Context should go away for Go 2 (2017)

#161

Post by eadmund »

frankie_t wrote: post #53
rubenv wrote: post #47

Earlier quoted context omitted.

> As I understand they propose to pass the data explicitly, like a struct with fields for all possible request-scoped data. So basically context.Context, except it can't propagate through third party libraries?

If you use a type like `map[string]any` then yes, it's going to be the same as Context. However, you can make a struct with fields of exactly the types you want. It won't propagate to the third-party libraries, yes. But then again, why don't they just provide an explicit way of passing values instead of hiding them in the context?

> why don't they just provide an explicit way of passing values instead of hiding them in the context?

Hiding them in a context is the explicit way of passing values through oblivious third-party libraries.

In some future version of Go, it would be nice to just have dynamic scoping. But this works now, and it’s a good pattern. The only real issue is the function-colouring one, and that’s solvable by simply requiring that every exported function take a context.

Re: Context should go away for Go 2 (2017)

#162

Post by eadmund »

dfawcus wrote: post #115
bryancoxwell wrote: post #45

Earlier quoted context omitted.

This works, but goes against convention in that (from the context package docs) you shouldn’t “store Contexts inside a struct type; instead, pass a Context explicitly to each function that needs it.”

It does seem an unnecessarily limiting convention. What will go wrong if one stores a Context in a struct? I've done so for a specific use case, and did not notice any issues.

> What will go wrong if one stores a Context in a struct?

Contexts are about the dynamic contour, i.e. the dynamic call stack. Storing the current context in a struct and then referring to it in some other dynamic … context … is going to lead to all sorts of pain: timeouts or deadlines which have already expired and/or values which are no longer pertinent.

While there are some limited circumstances in which it may be appropriate, in general it is a very strong code smell. Any code which passes a context should receive a context. And any code which may pass a context in the future should receive one now, to preserve API compatibility. So any exported function really should have a context as its first argument for forwards-compatibility.

Re: Context should go away for Go 2 (2017)

#163

Post by pkilgore »

dlisboa wrote: post #109
miffy900 wrote: post #34

> First things first, let’s establish some ground. Go is a good language for writing servers, but Go is not a language for writing servers. Go is a general purpose programming language, just like C, C++, Java or Python Really? Even years later in 2025, this never ended up being true. Unless your definition of 'general purpose' specifically excludes anything UI-related, like on desktop, web or mobile, or AI-related. I…

> Unless your definition of 'general purpose' specifically excludes anything UI-related, like on desktop, web or mobile, or AI-related. By that definition no language is general purpose. There is no language today that excels in GUI (desktop/mobile), web development, AI, cloud infrastructure, and all the other stuff like systems, embedded...And all at the same time. For instance I have never seen or heard of a succes…

I think the whole argument here is silly, but I do know kitty (terminal) and Calibre (ebook manager) are two rather popular cross platform python desktop apps.

Re: Context should go away for Go 2 (2017)

#164

Post by 9rx »

phire wrote: post #150
9rx wrote: post #148

Earlier quoted context omitted.

> The actual backwards compatibility in go is achieved by never removing functionality or syntax. The previous version removed functionality related to loop variables, so that is not strictly true. You might be right that the project doesn't take change lightly. There has to be a very compelling reason to justify such change, and why would it be any other way? If something isn't great, but still gets the job done, th…

> Go 1.22, for example, removed functionality related to loop variables, so that is not strictly true. Ah, interesting. I searched but I couldn't find any example of go actually making a breaking change. Rust has a massive document [1] documenting every single breaking in single document. With go you kind of have to dig through the release notes of each version. So, maybe Golang are relaxing their stance slightly on…

> My original point is that "never make breaking changes" is the wrong lesson to take away from Python 3. And that Rust's editions provide a very good example of how to do breaking changes correctly.

Here we go again, but the point of editions, as far as I can tell, is so that there are no breaking changes. A value Go also holds. As a result, both projects are still at version 1 and will likely always forever be at version 1.

So, if we round back to the start of our discussion, if Python 2 had taken the same stance, there would never be a Python 3. What we know of as Python 3 today would just be another Python 2 point release. Which is what the earlier commenter that started all this was saying – Go will not move to Go 2, and Rust won't move to Rust 2, because nobody wants to make the same mistake Python did.

I understand you have an advertising quota to fill, but introducing Rust into the discussion was conversationally pointless.

Re: Context should go away for Go 2 (2017)

#165

Post by [deleted] »

phire wrote: post #150
9rx wrote: post #148

Earlier quoted context omitted.

> The actual backwards compatibility in go is achieved by never removing functionality or syntax. The previous version removed functionality related to loop variables, so that is not strictly true. You might be right that the project doesn't take change lightly. There has to be a very compelling reason to justify such change, and why would it be any other way? If something isn't great, but still gets the job done, th…

> Go 1.22, for example, removed functionality related to loop variables, so that is not strictly true. Ah, interesting. I searched but I couldn't find any example of go actually making a breaking change. Rust has a massive document [1] documenting every single breaking in single document. With go you kind of have to dig through the release notes of each version. So, maybe Golang are relaxing their stance slightly on…

[deleted]

Re: Context should go away for Go 2 (2017)

#166

Post by tubthumper8 »

9rx wrote: post #164
phire wrote: post #150

Earlier quoted context omitted.

> Go 1.22, for example, removed functionality related to loop variables, so that is not strictly true. Ah, interesting. I searched but I couldn't find any example of go actually making a breaking change. Rust has a massive document [1] documenting every single breaking in single document. With go you kind of have to dig through the release notes of each version. So, maybe Golang are relaxing their stance slightly on…

> My original point is that "never make breaking changes" is the wrong lesson to take away from Python 3. And that Rust's editions provide a very good example of how to do breaking changes correctly. Here we go again, but the point of editions, as far as I can tell, is so that there are no breaking changes. A value Go also holds. As a result, both projects are still at version 1 and will likely always forever be at v…

> I understand you have an advertising quota to fill

This is a ridiculous statement and you are intentionally engaging in bad faith. There's no need for this in response to people genuinely trying to answer your questions. Be better

Re: Context should go away for Go 2 (2017)

#167

Post by Ferret7446 »

captainmuon wrote: post #12

This is about an explicit argument of type "Context". I'm not a Go user, and at first I thought it was about something else: an implicit context variable that allows you to pass stuff deep down the call stack, without intermediate functions knowing about it. React has "Context", SwiftUI has "@Environment", Emacs LISP has dynamic scope (so I heard). C# has AsyncLocal, Node.JS AsyncLocalStorage. This is one of those id…

We already have implicit context. It's called thread local storage and dynamic scoping, and we figured out it's a bad idea a long time ago.

Explicitly passing data and lexical scoping is better for understandability.

Re: Context should go away for Go 2 (2017)

#168

Post by bvrmn »

mroche wrote: post #153
bvrmn wrote: post #135

Earlier quoted context omitted.

> As a newcomer to Go, a lot of their design decisions made a lot of sense when I realized that a lot of the design is based around this idea of "make it impossible to do something that could be dumb in some contexts". You are indeed a newcomer :) God bless you to shoot feet only in dev environments.

It sounds like you may have some friction-studded history with Go. Any chance you can share your experience and perspective with using the language in your workloads?

It's mostly dead locked networking code. Hard to investigate, hard to search the culprit. And of course code bases without linter for err propagation and handling. And this-null for "methods".

Re: Context should go away for Go 2 (2017)

#169

Post by dfawcus »

lawrjone wrote: post #138
dfawcus wrote: post #115

Earlier quoted context omitted.

It does seem an unnecessarily limiting convention. What will go wrong if one stores a Context in a struct? I've done so for a specific use case, and did not notice any issues.

This guidance is actually super important, as contexts are expected to be modified in a code flow and apply to all functions that are downstream of your current call stack. If you store contexts on your structs it’s very likely you won’t thread them correctly, leading to errors like database code not properly handling transactions. Actually super fragile and you should avoid doing this as much as is possible. It’s ne…

What do you mean by "won't thread them correctly"?

The specific use case I had was where the context represented the lifetime of a (shared) TCP connection. I then wanted to use its cancellation to drive the destruction of various dynamic graph elements hanging off that shared connection.

Think a graph of muxes/demuxes in a dynamic message graph while the whole program is a CSP style thing.

I needed something to drive destruction, the context provided what I needed.

Re: Context should go away for Go 2 (2017)

#170

Post by dfawcus »

eadmund wrote: post #162
dfawcus wrote: post #115

Earlier quoted context omitted.

It does seem an unnecessarily limiting convention. What will go wrong if one stores a Context in a struct? I've done so for a specific use case, and did not notice any issues.

> What will go wrong if one stores a Context in a struct? Contexts are about the dynamic contour, i.e. the dynamic call stack. Storing the current context in a struct and then referring to it in some other dynamic … context … is going to lead to all sorts of pain: timeouts or deadlines which have already expired and/or values which are no longer pertinent. While there are some limited circumstances in which it may be…

Except Contexts provide a cancellation mechanism which can be used outwith of a specific dynamic call graph.

The documented semantics of the facility (and the implementation) seemed perfect for destroying a dynamic graph of CSP elements, which were exchanging messages. Where the cancellation causes the goroutines within the (think Actor-like) CSP element to clean up, tear down, and exit.

The warning about not storing it in a struct seems to assume it can only be used for one specific type of purpose, say web server processes and/or related database requests.

If I hadn't used it, I would have had to create something almost identical - but without the ability to store a data element.

Post reply on HN