Live data from Hacker News

Context should go away for Go 2 (2017)

faiface.github.io

151–160 of 176 posts

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

#151
post #149

Earlier quoted context omitted.

Most popular languages support annotations of one type or another, they let you do all that in a type safe way. It's Go that's decided to be different for difference sake, and produced a complete mess.

IMO Go is full of stuff like this where they do something different than most similar languages for questionable gains. `iota` instead of enums, implicit interfaces, full strings in imports (not talking about URLS here but them having string literal syntax), capitalization as visibility control come to mind immediately, and I'm sure there are others I'm forgetting. Not all of these are actively harmful, but for a lan…

the second i tried writing go to solve a non-trivial problem the whole language collapsed in on itself. footguns upon footguns hand-waved away with "it's the go way!". i just don't understand. the "the go way" feels more like a mantra that discourages critical thinking about programming language design.

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

#152
post #147

Earlier quoted context omitted.

I like explicit over implicit. I will take passing down context (in the sense of the concept, not the specific Go implementation) explicitly everywhere over implicit ("put it somewhere and I'll trust I can [probably, hopefully] get it back later") any day of the week. I've seen plenty of issues in Java codebases where there was an assumption some item was in the Thread Local storage (e.g. to add some context to a log…

Most recently ive been bit by this with datadog. The Python version does some monkeypatching to inject trace info. The go version you need to inject the trace info explicitly. While the latter takes more setup, it was much easier to understand what was going on and to debug when we ran into issues.

This is why I avoid Python. I started doing Go after looking for few solutions written and Python and I couldn’t use it.

Some magic values inside objects of recursive depth changing dynamically at the runtime. After working for some time with functional languages and languages with non-mutable structures I’m afraid of such features today.

Context is nice because it’s explicit. Even function header spills the detail. `GetXFromName(context.Context, string)` already says that this call will do some IO/remote call and might never return or be subject of cancellation.

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

#153
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". 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.

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?

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

#154
post #49

Earlier quoted context omitted.

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

That's exactly what what they're talking about, "tenantId" shouldn't be in the function signature for functions that aren't concerned with the tenant ID, such as business logic

But they chose a solution (if I understand correctly), where tenant ID is not in the signature of functions that use it, either.

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

#155
post #76

Earlier quoted context omitted.

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.

Go tell that to Amazon, Facebook and Microsoft.

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

#156
post #147

Earlier quoted context omitted.

I like explicit over implicit. I will take passing down context (in the sense of the concept, not the specific Go implementation) explicitly everywhere over implicit ("put it somewhere and I'll trust I can [probably, hopefully] get it back later") any day of the week. I've seen plenty of issues in Java codebases where there was an assumption some item was in the Thread Local storage (e.g. to add some context to a log…

Most recently ive been bit by this with datadog. The Python version does some monkeypatching to inject trace info. The go version you need to inject the trace info explicitly. While the latter takes more setup, it was much easier to understand what was going on and to debug when we ran into issues.

Sounds very familiar. I was a Java developer for a long time, and in that ecosystem adding a library to your project can be enough for code to be activated and run. There are plenty of libraries where the idea is: just include it, magic stuff will happen, and everything works! That is, until it doesn't work. And then you have to try and debug all this magic stuff of how Java automatically loads classes, how these classes are created and run, and what they do. Didn't happen very often, but when it happened usually a full week was wasted with this.

I really prefer spending a bit more time to set it up myself (and learn something about what I'm using in the process) and knowing how it works, than all the implicit magic.

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

#157

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…

> React has "Context", SwiftUI has "@Environment", Emacs LISP has dynamic scope (so I heard). C# has AsyncLocal, Node.JS AsyncLocalStorage. Emacs Lisp retains dynamic scope, but it's no longer a default for some time now, in line in other Lisps that remain in use. Dynamic scope is one of the greatest features in Lisp language family, and it's sad to see it's missing almost everywhere else - where, as you noted, it's…

raku's take on gradual typing may be to your taste; i likewise prefer to leave irrelevant types out and use maximally-expressive types where it makes sense¹. i feel this is helped by the insistence on sigils because you then know the rough shape of things (and thus a minimal interface they implement: $scalar, @positional, %associative, &callable) even when you lack their specific types. in the same vein, dynamically scoped variables are indicated with the asterisk as a twigil (second level sigil).

  @foo
is a list (well, it does Positional anyway), while

  @*foo
is a different variable that is additionally dynamically scoped.

it's idiomatic to see

  $*db
as a database handle to save passing it around explicitly, env vars are in

  %*ENV
things like that. it's nice to have the additional explicit reminder whenever you're dealing with a dynamic variable in a way the language checks for you and yells at you for forgetting.

i would prefer to kick more of the complex things i do with types back to compile time, but a lot of static checks are there. more to the point, raku's type system is quite expressive at runtime (that's what you get when you copy common lisp's homework, after all) and helpful to move orthogonal concerns out into discrete manageable things that feel like types to use even if what they're doing is just a runtime branch that lives in the function signature. doing stuff via subset types or roles or coercion types means whatever you do plays nicely with polymorphic dispatch, method resolution order, pattern matching, what have you.

in fact, i just wrote a little entirely type level... thing? to clean up the body of an http handler that lifts everything into a role mix-in pipeline that runs from the database straight on through to live reloading of client-side elements. processing sensor readings for textual display, generating html, customizing where and when the client fetches the next live update, it's all just the same pipeline applying roles to the raw values from the db with the same infix operator (which just wraps a builtin non-associative operator to be left associative to free myself from all the parentheses).

not getting bogged down in managing types all the time frees you up to do things like this when it's most impactful, or at least that's what i tell myself whenever i step on a rake i should have remembered was there.

¹ or times where raku bubbles types up to the end-user, like the autogenerated help messages generated from the type signature of MAIN. i often write "useless" type declarations such as subset Domain-or-IP; which match anything² so that the help message says --host[=Domain-or-IP] instead of --host[=Str] or whatever

² well, except junctions, which i consider the current implementation of to be somewhat of a misstep since they're not fundamentally also a list plus a context. it's a whole thing. in any case, this acts at the level of the type hierarchy that you want anyway.

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

#158

Contexts in Go are generally used for convenience in request cancellation, but they're not required , and they're not the only way to do it. Under the hood, a context is just a channel that's closed on cancellation. The way it was done before contexts was pretty much the same: func CancellableOp(done chan error /* , args... */) { for { // ... // cancellable code: select { case Some compare context "virus" to async vi…

Consider this: ctx, cancel := context.WithTimeout(context.Background(), 60*time.Second) reader := ioContextReader(ctx, r) ... ctx, cancel := context.WithTimeout(ctx, 1*time.Second) ctx = context.WithValue(ctx, "hello", "world") ... func(ctx context.Context) { reader.Read() // does not time out after one second, does not contain hello/world. ... }(ctx)

Of course not - you're not handling the context at all in the called function. What's there to consider, reader.Read() has no idea about your timeout and value store intent. How would it, telepathy?

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

#159

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

It is not.

Link to previous discussion: https://news.ycombinator.com/item?id=14958989

> https://golang.org/doc/faq#What_is_the_purpose_of_the_projec...: "By its design, Go proposes an approach for the construction of system software on multicore machines."

> That page points to https://talks.golang.org/2012/splash.article for "A much more expansive answer to this question". That article states:

> "Go is a programming language designed by Google to help solve Google's problems [...] More than most general-purpose programming languages, Go was designed to address a set of software engineering issues that we had been exposed to in the construction of large server software."

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

#160
post #142
post #100

Earlier quoted context omitted.

They're basically dynamic scoping and it's both a very useful and powerful and very dangerous feature ... scheme's dynamic-wind model makes it more obvious when the particular form of magic is in use but isn't otherwise a lot different. I would like to think that somebody better at type systems than me could provide a way to encode it into one that doesn't require typing out the dynamic names and types on every singl…

Basically you'd be asking for inferring a record type largely transparently. That's going to quickly explode to the most naive form because it's very hard to tell what could be called, especially in Go.

I don't think you could fit it to Go, no.

But see https://hackage.haskell.org/package/effectful for work in the general area that seems rather promising.

Post reply on HN