Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

golang is a colored language since "context.Context" needs to be passed to all asynchronous calls. This is explained very well in the Zig talk: https://kristoff.it/blog/zig-colorblind-async-await/


sort by: page size:

You can use contexts to send a cancellation signal to goroutines: https://blog.golang.org/context.

This is more of an implementation detail you make on a case-by-case language rather than a builtin to go.


If you're looking for alternate ways of designing an asynchronous coroutine API, Zig (https://ziglang.org/) and Go (https://golang.org/) have different implementations which might be worth reading into. Both avoid special syntax in the common beginner case, until you know enough to correctly write concurrent code (then you need async in Zig, and goroutines in Go). :)

The language is called Go not golang [1].

[1] https://twitter.com/rob_pike/status/886054143235719169?lang=...


Moving forward, of course, it's preferable to use the official context package: http://godoc.org/golang.org/x/net/context

Here's some Golang code that does it:

https://github.com/kawasin73/gointr

I think you could use that technique to make blocking syscalls that take a context.Context and return early if the context becomes done.


People really seem to dislike context in the standard library too:

https://github.com/golang/go/issues/20280


Goroutines are asynchronously preemptible since Go 1.14, released February 25th, 2020.

https://blog.golang.org/go1.14


These days you have http requests with context (I think starting from Go 1.8), see https://golang.org/pkg/net/http/#Request.Context


The Go1 promise (https://golang.org/doc/go1compat) means that they cannot refine the language any further. It's frozen.

For example, there's a mess of different error handling techniques (e.g. err == io.EOF vs os.IsNotExist(err) vs perr, ok := err.(*os.PathError); ok).

This also prevents the language from evolving, as can be seen in the case of the context package (see 'Frozen' in this post https://github.com/golang/go/issues/14660#issue-138695431 )

While the above poster didn't explain his problem clearly, it is a valid complaint.



Go is not fully preemptive, but in practice it usually is (it preempts at function calls): https://github.com/golang/go/issues/10958.

> Writing an Interpreter in Go https://amzn.to/2PA5LEh

+1



Shameless plug; I now use Golang for all my scripting needs. I wrote about it and shared a sample here: https://news.ycombinator.com/item?id=24392172

Two things:

1) It's Go, not GoLang (god I hate being that guy, but it drove me up the wall). 2) Why is the link on this article to a tweet about the article instead of the post itself?


A commenter on /r/haskell[0] noted that there is actually a library that mimics Go Channels a bit closer, called GoChan[1]. That said, I think `async` is the idiomatic choice, so it probably makes more sense to keep it.

[0] https://www.reddit.com/r/haskell/comments/7ilhb9/a_tour_of_g...

[1] https://hackage.haskell.org/package/gochan-0.0.2/docs/Contro...


> flag (command-line context)

Looks like Google backed golang needs to change their library: https://golang.org/pkg/flag/


Golang is a common way to refer to Go, especially for SEO purposes. “Go” is hard to search for.

https://go.dev/doc/faq#go_or_golang

I use “golang” for clarity all the time, and I’m sure many others do as well. There’s no ambiguity you’re talking about the language then.

next

Legal | privacy