Refactor Asynchronous JS to Go

[Shubh Karman Singh]

Hi, 

I am refactoring a JS library to Go. I have some questions but I'm not able to find some concrete answers for this. 

1. What's the idiomatic way to refactor Asynchronous JS APIs to Go? 

2. How to refactor Callbacks from JS to Golang? I have seen some Go code which takes function as an input parameter. Is the intent same here? 

[Rusco]

Some time ago I compared Functional Reactive Programming FRP with Golang Channels (CSP), might be useful to you as a starter:

https://rusco.github.io/

[Kurtis Rader]

I've been programming for more than four decades. In that time I've personally rewritten three apps in a different language. I've also read several post translation reports for other projects. The most important lesson is that it is usually a mistake to perform a literal translation. In fact, of the rewrites I've participated in or read about a literal translation was appropriate in only one case. That was the first one I ever did: translating Donald Knuth's TeX typesetting program from Pascal to C.

I haven't written any Javascript in over a decade. But translating its async API pattern to idiomatic Go is likely to involve starting a goroutine for each async op and having the goroutine communicate a result via a channel. For your second question, yes, functions are first-class objects in Go and can be passed to other functions to perform a specialized operation or act as a callback.

--

Kurtis Rader

Caretaker of the exceptional canines Junior and Hank

[Konstantin Khomoutov]

While my exposure to programming is twice as less than that of Kurtis,
I would like to support his view on this.
The chief idea of Go's concurrency is that it's integrated into the language's
code - as opposed to be bolted on in form of a library, as is the case with
most other popular programming languages out there. This is one of the reasons
why you don't see many callbacks in idomatic Go code: they are either not
needed or their functionality is implemented via sending values via channels
and a set of patterns involving them (see [1, 2, 3]).

For a good and fun overview of that "in core" vs "as a library" distinction
please see [4].

1. https://go.dev/blog/concurrency-timeouts
2. https://go.dev/blog/pipelines
3. https://go.dev/blog/io2013-talk-concurrency
4. https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

[Konstantin Khomoutov]

On Sun, Nov 06, 2022 at 02:42:52PM +0400, Konstantin Khomoutov wrote:

[...]

> The chief idea of Go's concurrency is that it's integrated into the language's
> code - as opposed to be bolted on in form of a library

Sorry, I meant core, of course, not code.