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

131–140 of 176 posts

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

#131

Post by cyberax »

pjmlp wrote: post #76
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…

In an alternative timeline, had Rust 1.0 been available when Docker pivoted away from Python into Go, and Kubernetes from Java into Go, due to having Go folks pushing for the rewrite, and most likely they would have been taken by RIIR instead, nowadays spreading across Python and JavaScript ecosystem, including rewriting tools originally written in Go.

Nope. Rust is not a good tool for servers. It's downright terrible, in fact. Goroutines help _a_ _lot_ with concurrency.

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

#133

Post by smashedtoatoms »

n144q wrote: post #79

I find "CancellationToken" in VSCode extension APIs quite clear and usable, and not overly complicated. Wonder if anyone has done a conparison of Go's context and CancellationToken.

Yeah, .NET developers have been passing CancellationTokens around in the places where they have needed them for 15 years. The tokens are basically invisible until their existence emerges when someone decides they want to cancel a long-running API call or something. At that point, they are plumbed as deeply as seems fit for the problem at hand and then hardly thought about ever again. CancellationTokens are generally a delightful pattern, especially when the language allows sensible defaults.

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

#134

Post by ncruces »

kflgkans wrote: post #127
Thaxll wrote: post #123

Earlier quoted context omitted.

Because you should wrapp that in a type safe function. You should not use the context.GetValue() directly but use your own function, the context is just a transport mechanism.

If it is just a transport mechanism, why use context at all ant not a typed struct?

Because dozens of in between layers don't need to know the type, and should in fact work regardless of the specific type.

Context tells you enough: someone, somewhere may do magic with this if you pass it down the chain.

And in good Go tradition it's explicit about this: functions that don't take a context don't (generally) do that kind of magic.

If anything it mixes two concerns: cancelation and dynamic scoping.

But I'm not sure having two different parameters would be better.

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

#135

Post by bvrmn »

danudey wrote: post #112
neonsunset wrote: post #103

Earlier quoted context omitted.

Under the hood, in both Java and C# the first argument of an instance method is the instance reference itself. After all, instance methods imply you have an instance to work with. Having to write 'this' by hand for such is how OOP was done before OOP languages became a thing. I agree that adopting yet another pattern like this would be on brand for Go since it prizes taking its opinionated way of going about everythi…

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". For example, I hate that there's no inheritance. I wish I could create a ContainerImage object and then a RemoteContainerImage subclass and then QuayContainerImage and DockerhubContainerImage subclasses…

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

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

#136

Post by bvrmn »

vbezhenar wrote: post #31
kgeist wrote: post #27

Earlier quoted context omitted.

Passing the current user ID/tenant ID inside ctx has been super useful for us. We’re already using contexts for cancellation and graceful termination, so our application-layer functions already have them. Makes sense to just reuse them to store user and tenant IDs too (which we pull from access tokens in the transport layer). We have DB sharding, so the DB layer needs to figure out which shard to choose. It does that…

An alternative is to add all dependencies explicitly into function argument list or object fields, instead of using them implicitly from the context, without documentation and static typing. Including logger.

You can't add arguments to vendor library functions. It's super convenient to have contexted logging work for any logging calls.

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

#137

Post by lawrjone »

skywhopper wrote: post #88
frankie_t wrote: post #53

Earlier quoted context omitted.

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?

Precisely because you need to be able to pass it through third party libraries and into callbacks on the other side where you need to recover the values.

Yeah most people talking here are unlikely to have worked on large scale Go apps.

Managing a god-level context struct with all the fields that ever could be relevant and explaining what they mean in position independent ways for documentation is just not scalable at all.

Import cycles mean you’re forced into this if you want to share between all your packages, and it gets really hairy.

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

#138

Post by lawrjone »

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.

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 never a good idea!

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

#139

Post by lmm »

kloop wrote: post #124
lmm wrote: post #85

Earlier quoted context omitted.

> There's nothing at the call site that tells you what is happening. A decent IDE highlights it at the call site. It's definitely an abusable feature, but I find it very useful. In most other languages you end up having to have completely invisible parameters (e.g. database session bound to the thread) because it would be too cumbersome to pass them explicitly. In Scala you have a middle ground option between complet…

I'm not sure what you consider a decent scala ide, but it was a problem with IntelliJ in several of our code bases, and I'd have to crawl the implicit resolution path. I eventually opted to desugaring the scala completely, but we were already on the way out of scala by that point

> it was a problem with IntelliJ in several of our code bases

It shouldn't be, unless you were using macros (always officially experimental) or something - I was always primarily an Eclipse guy but IntelliJ worked well. Did you not get the green underline?

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

#140

Post by lmm »

agumonkey wrote: post #107
lmm wrote: post #85

Earlier quoted context omitted.

> There's nothing at the call site that tells you what is happening. A decent IDE highlights it at the call site. It's definitely an abusable feature, but I find it very useful. In most other languages you end up having to have completely invisible parameters (e.g. database session bound to the thread) because it would be too cumbersome to pass them explicitly. In Scala you have a middle ground option between complet…

yeah that's what i thought, but maybe scala implicit param not being perfect will help finding a better linguistic trait (maybe they should enforce purity on these parameters)

IMO it is perfect, or at least better than anything else that's been found so far.

"Purity" means different things in different contexts. Ultimately you can give programmers more tools, but you can't get away from relying on their good judgement.

Post reply on HN