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

81–90 of 176 posts

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

#81

Post by giancarlostoro »

kgeist wrote: post #38
vbezhenar wrote: post #31

Earlier quoted context omitted.

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.

I already talked about it above. Main problems with passing dependencies in function argument lists: 1) it pollutes the code and makes refactoring harder (a small change in one place must be propagated to all call sites in the dependency tree which recursively accept user ID/tenant ID and similar info) 2) it violates various architectural principles, for example, from the point of view of our business logic, there's…

I have a feeling, if Context disappears, you'll just see "Context" becoming a common struct that is passed around. In Python, unlike in C# and Java, the first param for a Class Method is usually the class instance itself, it is usually called "self" so I could see this becoming the norm in Go.

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

#83

Post by agumonkey »

kloop wrote: post #73
agumonkey wrote: post #21

Earlier quoted context omitted.

I've always been curious about how this feature ends up in day to day operations and long term projects. You're happy with it ?

As a veteran of a large scala project (which was re-written in go, so I'm not unbiased), no. I was generally not happy. This was scala 2, so implicit resolution lookup was a big chunk of the problem. There's nothing at the call site that tells you what is happening. But even when it wasn't hidden in a companion object somewhere, it was still difficult because every import change had to be scrutinized as it could caus…

thanks a lot for your answer

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

#84

Post by bheadmaster »

orf wrote: post #78
bheadmaster wrote: post #77

Earlier quoted context omitted.

Thank you for your helpful input.

No worries, this help also generalises to any time you want to add locking/synchronisation or other overheads to a hot code path. It’s best not to acquire a mutex and launch a goroutine to read 3 bytes of data at a time. Also, hot tip: you can like… benchmark this. It’s not illegal.

> It’s best not to acquire a mutex and launch a goroutine to read 3 bytes of data at a time.

io.Copy uses 32KB buffers. Other parts of standard library do too. If you're using Read() to read 3 bytes of data at a time, mutex is the least of your worries.

Since you seem to be ignoring sarcasm of my previous comment - just saying "don't do that" without suggesting an alternative way in the particular code context you're referring to, isn't useful at all. It's just annoying.

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

#85

Post by lmm »

kloop wrote: post #73
agumonkey wrote: post #21

Earlier quoted context omitted.

I've always been curious about how this feature ends up in day to day operations and long term projects. You're happy with it ?

As a veteran of a large scala project (which was re-written in go, so I'm not unbiased), no. I was generally not happy. This was scala 2, so implicit resolution lookup was a big chunk of the problem. There's nothing at the call site that tells you what is happening. But even when it wasn't hidden in a companion object somewhere, it was still difficult because every import change had to be scrutinized as it could caus…

> 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 completely explicit and completely invisible.

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

#86

Post by phire »

9rx wrote: post #43
phire wrote: post #26

Earlier quoted context omitted.

The the introduction of Python 3 wasn't a mistake. The mistake was discontinuing Python 2. Just look at how rust does it. Rust 1.0 code still works in the latest version of rustc, you just need to set the project to the Rust 2015 edition. You can even mix-and-match editions, as each crate can have a different edition. Newer versions of rustc will always support all previous editions, and breaking changes are only eve…

It seems you are both saying the same thing. Had Python not introduced a line in the sand and instead continued to support Python 2 amid future updates there would have been no reason for Python 3. The Python 2 line could have kept improving instead. Just as you say, Python could have introduced what is found in Python 3 without breaking Python 2 support. Which is the direction Go has settled on; hence why Go 2 is of…

No. The point of rust editions is that they do break support for older code, which is very different to what go has now settled on.

IMO, it's the best of both worlds. Old code continues to work forever, but your language design isn't held back by older design mistakes.

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

#87

Post by lmm »

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…

> Implicit context (properly integrated into the type system) is something I would consider in any new language.

Those who forget monads are doomed to reinvent dozens of limited single-purpose variants of them as language features.

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

#88

Post by skywhopper »

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?

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.

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

#89

Post by [deleted] »

youerbt wrote: post #49
kgeist wrote: post #38

Earlier quoted context omitted.

I already talked about it above. Main problems with passing dependencies in function argument lists: 1) it pollutes the code and makes refactoring harder (a small change in one place must be propagated to all call sites in the dependency tree which recursively accept user ID/tenant ID and similar info) 2) it violates various architectural principles, for example, from the point of view of our business logic, there's…

> it violates various architectural principles, for example, from the point of view of our business logic, there's no such thing as "tenant ID" I'm not sure I understand how hiding this changes anything. Could you just not pass "tenant ID" to doBusinessLogic function and pass it to saveToDatabase function?

[deleted]

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

#90

Post by orf »

bheadmaster wrote: post #84
orf wrote: post #78

Earlier quoted context omitted.

No worries, this help also generalises to any time you want to add locking/synchronisation or other overheads to a hot code path. It’s best not to acquire a mutex and launch a goroutine to read 3 bytes of data at a time. Also, hot tip: you can like… benchmark this. It’s not illegal.

> It’s best not to acquire a mutex and launch a goroutine to read 3 bytes of data at a time. io.Copy uses 32KB buffers. Other parts of standard library do too. If you're using Read() to read 3 bytes of data at a time, mutex is the least of your worries. Since you seem to be ignoring sarcasm of my previous comment - just saying "don't do that" without suggesting an alternative way in the particular code context you're…

It may well use 32KB buffers, or any size, but that doesn’t translate to “reading 32KB at a time”.

If you’re aborting specifically an io.Copy, then there are better ways to do that: abort in the write path rather than the read path.

It’s not my job to provide you with alternative code. That’s your job.

Post reply on HN