5 ms·

Oh god no, this draft is actually pretty good, don't ruin it by infecting it with context. Context is the worst library in Go: it's a pile of hacks to get cance

Oh god no, this draft is actually pretty good, don't ruin it by infecting it with context. Context is the worst library in Go: it's a pile of hacks to get cancellation and goroutine-local storage by manually passing new heap-allocated objects through every function interface in every library between low-level IO up to task management. It infects everything, obliterating separation of concerns making even libraries that should have nothing at all do do with timeouts include code for it. And it includes an untyped key-value store implemented as a linked-list of pairs (!!!!), because why not? If you can't tell, I don't like context. I've said before [0] I really hope that Go 2 comes up with an actual solution to the cancellation and task-local storage problems and deprecates context. Some comments in that thread pointed to alternatives that looked pretty decent, I wonder what state they're in these days. [0]: https://news.ycombinator.com/item?id=18561884 https://news.ycombinator.com/item?id=18561884

solatic 6y ago
Everything old is new again. This challenge is basically why monads exist, because the monad allows you to cleanly separate between the state in which the algorithm is running and the algorithm itself. Reminds me of: https://philipnilsson.github.io/Badness10k/posts/2017-05-07-escaping-hell-with-monads.html https://philipnilsson.github.io/Badness10k/posts/2017-05-07-... I wonder what poor abstraction the Go authors will come up with instead?
- philosopher1234 6y ago
  How would you apply monads to solve the context problem? Hard for me to imagine what that would look like
  - dllthomas 6y ago
    I think what they have in mind is a Reader monad. newtype Reader r a = Reader { runReader :: r -> a } instance Monad (Reader r) where pure x = Reader (\ _ -> x) m >>= f = Reader (\ r -> runReader (f (runReader m r)) r) which allows us to define: getContext :: Reader r r getContext = Reader (\ r -> r) and which spares us threading the context manually. I don't think that's such a big deal, so long as there's only one thing we're threading. In some languages, we can be generic over "contexts which provide the thing I want, whether they do other things or not", which is sometimes a much bigger win.
  - solatic 6y ago
    Context is like Schrödinger's Cat, you don't know if the Context you're working in is alive or dead (i.e. cancelled, timed out, etc.), but you have to keep passing it forward, one intermediate network call after the next, as long as its status is uncertain. Only when the request fully returns, or is actively cancelled, do you know whether the request is alive or dead. The Maybe monad deals with the same issue. You have a series of function calls, each of which might or might not be legal, because you never know if you actually have the parameter for the next function call. Maybe you do, maybe you don't. If you take the naive approach to solving the issue, you pass along Schrödinger's Cat each step along the way. You intertwine the concern of the algorithm you're trying to write with the uncertainty of whether you're carrying a live cat or a dead one. It can work, but it's ugly. The monadic approach allows you to separate these concerns. You write your algorithm as if you know for a fact that the cat is alive. If the cat were ever to be revealed to be dead along the path, it doesn't matter, the monad separated the consequences of dealing with the live or dead cat from the rest of your algorithm. The rest of your algorithm simply doesn't get run. Context is the same. You get to write code as if the context is always valid. You don't have to worry about context being cancelled, or timed out, or anything else. You take all those concerns and relate to them separately, in one place, where they can be neatly dealt with. The whole point of the monadic pattern is to propagate state in such a way that it doesn't interfere with the pure algorithm which you're trying to write. You write the pure algorithm separately, and then use it within the monadic context of Context, so to speak.
- voldacar 6y ago
  the gophers hated him because he told them the truth
- nyanpasu64 6y ago
  > https://philipnilsson.github.io/Badness10k/posts/2017-05-07-escaping-hell-with-monads.html https://philipnilsson.github.io/Badness10k/posts/2017-05-07-... Every "monadic solution" prints the same code block without explaining how it would work, the types of the various variables, the semantics of the <- operator. I didn't leave the page with an understanding of how monads achieve these tasks.
  - virtue3 6y ago
    The article is literally: "Hell thing" Step 1 -> monads step 2 -> ???? step 3 -> profit? This is apparently the monads curse where people that get them can't effing explain them to save their life.
    - strbean 6y ago
      Monads are just monoids in the category of endofunctors! /s The issue is pretty much a language barrier. All these articles talking about benefits of / interesting ways to use monads are written by people who speak the language, assuming the reader speaks the language as well. As with many functional programming topics, the fundamentals aren't incredibly easy to wrap your head around. But if you already understood monads, can you imagine how annoying it would be if every resource, discussion, article, etc. relating to them started with a pages-long introduction on What is a Monad? In Haskell, this is a fundamental topic. Monads are used everywhere. If people always explained how they worked when discussing them, it would be like looking up sorting algorithms and having every algorithm description start with a long-winded explanation of how for loops work.
      - infogulch 6y ago
        > But if you already understood monads, can you imagine how annoying it would be if every resource, discussion, article, etc. relating to them started with a pages-long introduction on What is a Monad? I agree that it would be unreasonable for every article that uses monads to describe what they are. But I don't think it would be unreasonable for every one of them to link to another article that does explain them.
networkimprov 6y ago
No Go 2.0 release is planned. Go2 is a marketing label (I guess?) meant to imply that the Go 1.x language and stdlib are still evolving. The term is a mistake, as it creates the impression that a backwards-incompatible product is in the works.
- infogulch 6y ago
  I'm familiar with go team's compatibility plan for "Go 2", or whatever it will be called, which is why I used "deprecate" not "delete". Though I agree that there's no requirement to have a new major version in order to introduce big fixes like this.
zeveb 6y ago
I quite like the concept of contexts, I just wish they were implicit rather than explicit. The idea of a function taking place in a dynamic context makes perfect sense (because, after all, it does); the only thing which doesn't really make sense is having to pass it along by hand. Imagine how terrible it would be if we had to explicitly pass the return stack everywhere[0]! It needs to 'infect' (as you put it) everything because it needs to pervade everything, so a library can pass it through to anything it calls. This is a good argument for making it implicit. > And it includes an untyped key-value store implemented as a linked-list of pairs (!!!!), because why not? That is just a cons chain, famous for example as the foundation of the Lisp programming language, and there is nothing wrong with it. Note that it is unfair to say that it is untyped: the values themselves are strongly typed, and the cells too are typed — interface{} (or T in Lisp terms) is still a type! A cons chain has advantages for inheritance of values in a DAG of calls. It is not necessarily the most efficient, but simplicity is a virtue. 0: Continuation-passing style is both really powerful and well-nigh unreadable, for a reason.
thiht 6y ago
I love contexts. They're a simple solution to a complicated problem. They take up space in the functions signatures but they're sooo easy to read and to use. I really hope they'll stay.

solatic 6y ago

Everything old is new again. This challenge is basically why monads exist, because the monad allows you to cleanly separate between the state in which the algorithm is running and the algorithm itself. Reminds me of: https://philipnilsson.github.io/Badness10k/posts/2017-05-07-escaping-hell-with-monads.html https://philipnilsson.github.io/Badness10k/posts/2017-05-07-... I wonder what poor abstraction the Go authors will come up with instead?

philosopher1234 6y ago
How would you apply monads to solve the context problem? Hard for me to imagine what that would look like
- dllthomas 6y ago
  I think what they have in mind is a Reader monad. newtype Reader r a = Reader { runReader :: r -> a } instance Monad (Reader r) where pure x = Reader (\ _ -> x) m >>= f = Reader (\ r -> runReader (f (runReader m r)) r) which allows us to define: getContext :: Reader r r getContext = Reader (\ r -> r) and which spares us threading the context manually. I don't think that's such a big deal, so long as there's only one thing we're threading. In some languages, we can be generic over "contexts which provide the thing I want, whether they do other things or not", which is sometimes a much bigger win.
- solatic 6y ago
  Context is like Schrödinger's Cat, you don't know if the Context you're working in is alive or dead (i.e. cancelled, timed out, etc.), but you have to keep passing it forward, one intermediate network call after the next, as long as its status is uncertain. Only when the request fully returns, or is actively cancelled, do you know whether the request is alive or dead. The Maybe monad deals with the same issue. You have a series of function calls, each of which might or might not be legal, because you never know if you actually have the parameter for the next function call. Maybe you do, maybe you don't. If you take the naive approach to solving the issue, you pass along Schrödinger's Cat each step along the way. You intertwine the concern of the algorithm you're trying to write with the uncertainty of whether you're carrying a live cat or a dead one. It can work, but it's ugly. The monadic approach allows you to separate these concerns. You write your algorithm as if you know for a fact that the cat is alive. If the cat were ever to be revealed to be dead along the path, it doesn't matter, the monad separated the consequences of dealing with the live or dead cat from the rest of your algorithm. The rest of your algorithm simply doesn't get run. Context is the same. You get to write code as if the context is always valid. You don't have to worry about context being cancelled, or timed out, or anything else. You take all those concerns and relate to them separately, in one place, where they can be neatly dealt with. The whole point of the monadic pattern is to propagate state in such a way that it doesn't interfere with the pure algorithm which you're trying to write. You write the pure algorithm separately, and then use it within the monadic context of Context, so to speak.
voldacar 6y ago
the gophers hated him because he told them the truth
nyanpasu64 6y ago
> https://philipnilsson.github.io/Badness10k/posts/2017-05-07-escaping-hell-with-monads.html https://philipnilsson.github.io/Badness10k/posts/2017-05-07-... Every "monadic solution" prints the same code block without explaining how it would work, the types of the various variables, the semantics of the <- operator. I didn't leave the page with an understanding of how monads achieve these tasks.
- virtue3 6y ago
  The article is literally: "Hell thing" Step 1 -> monads step 2 -> ???? step 3 -> profit? This is apparently the monads curse where people that get them can't effing explain them to save their life.
  - strbean 6y ago
    Monads are just monoids in the category of endofunctors! /s The issue is pretty much a language barrier. All these articles talking about benefits of / interesting ways to use monads are written by people who speak the language, assuming the reader speaks the language as well. As with many functional programming topics, the fundamentals aren't incredibly easy to wrap your head around. But if you already understood monads, can you imagine how annoying it would be if every resource, discussion, article, etc. relating to them started with a pages-long introduction on What is a Monad? In Haskell, this is a fundamental topic. Monads are used everywhere. If people always explained how they worked when discussing them, it would be like looking up sorting algorithms and having every algorithm description start with a long-winded explanation of how for loops work.
    - infogulch 6y ago
      > But if you already understood monads, can you imagine how annoying it would be if every resource, discussion, article, etc. relating to them started with a pages-long introduction on What is a Monad? I agree that it would be unreasonable for every article that uses monads to describe what they are. But I don't think it would be unreasonable for every one of them to link to another article that does explain them.

networkimprov 6y ago

No Go 2.0 release is planned. Go2 is a marketing label (I guess?) meant to imply that the Go 1.x language and stdlib are still evolving. The term is a mistake, as it creates the impression that a backwards-incompatible product is in the works.

infogulch 6y ago
I'm familiar with go team's compatibility plan for "Go 2", or whatever it will be called, which is why I used "deprecate" not "delete". Though I agree that there's no requirement to have a new major version in order to introduce big fixes like this.

zeveb 6y ago

I quite like the concept of contexts, I just wish they were implicit rather than explicit. The idea of a function taking place in a dynamic context makes perfect sense (because, after all, it does); the only thing which doesn't really make sense is having to pass it along by hand. Imagine how terrible it would be if we had to explicitly pass the return stack everywhere[0]! It needs to 'infect' (as you put it) everything because it needs to pervade everything, so a library can pass it through to anything it calls. This is a good argument for making it implicit. > And it includes an untyped key-value store implemented as a linked-list of pairs (!!!!), because why not? That is just a cons chain, famous for example as the foundation of the Lisp programming language, and there is nothing wrong with it. Note that it is unfair to say that it is untyped: the values themselves are strongly typed, and the cells too are typed — interface{} (or T in Lisp terms) is still a type! A cons chain has advantages for inheritance of values in a DAG of calls. It is not necessarily the most efficient, but simplicity is a virtue. 0: Continuation-passing style is both really powerful and well-nigh unreadable, for a reason.

thiht 6y ago

I love contexts. They're a simple solution to a complicated problem. They take up space in the functions signatures but they're sooo easy to read and to use. I really hope they'll stay.