DEV Community: Nicolas Lepage

Testing Go WebAssembly code on Github actions

Nicolas Lepage — Fri, 20 Aug 2021 22:29:11 +0000

This small post will run you through how to setup Github actions to run tests for Go code targeting WebAssembly.

OK, take me straight to the complete setup!

Here is the most basic configuration suggested by Github for Go repositories:

name: Go

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:

  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2

    - name: Set up Go
      uses: actions/setup-go@v2
      with:
        go-version: 1.17

    - name: Build
      run: go build -v ./...

    - name: Test
      run: go test -v ./...

The first thing we need is to tell the go command we want to target WebAssembly, which can be done declaring the GOOS and GOARCH variables on the job:

jobs:

  build:
    runs-on: ubuntu-latest
    env:
      GOOS: js
      GOARCH: wasm

The "Build" step should now work as expected, checking that our code compiles to WebAssembly.

However for the "Test" step to work, we need some more configuration.

Of course we need an execution environment for our compiled WebAssembly, in our case Node.js will be perfect, so let's set it up in addition of Go:

    - name: Set up Node.js
      uses: actions/setup-node@v2.4.0
      with:
        node-version: 14

And finally we need to add go_js_wasm_exec to our PATH to enable go test running our tests using Node.js.

go_js_wasm_exec is located in the misc/wasm directory of the Go installation, we can add it to the PATH with a simple step:

    - name: Setup PATH for wasm
      run: echo "${{env.GOROOT}}/misc/wasm" >> $GITHUB_PATH

Complete setup

name: Go

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:

  build:
    runs-on: ubuntu-latest
    env:
      GOOS: js
      GOARCH: wasm
    steps:
    - uses: actions/checkout@v2

    - name: Set up Go
      uses: actions/setup-go@v2
      with:
        go-version: 1.17

    - name: Setup PATH for wasm
      run: echo "${{env.GOROOT}}/misc/wasm" >> $GITHUB_PATH

    - name: Set up Node.js
      uses: actions/setup-node@v2.4.0
      with:
        node-version: 14

    - name: Build
      run: go build -v ./...

    - name: Test
      run: go test -v ./...

This setup is based on the instructions in the Go WebAssembly wiki page, it can be adapted to run tests in a browser.

Gopher drawings!

Nicolas Lepage — Tue, 27 Jul 2021 07:51:59 +0000

Gophers 🐻

Hey 👋! Here are some drawings I have been using for talks about Golang.

These are mainly gophers, but also some dukes, and miscellaneous.

Gophers drawings are based on the original design of the Go gopher by Renee French.

See License for license information.

Gophers

Dukes

Miscellaneous

Uncolored

License

Original design of the Go gopher by Renee French.

View on GitHub

Emulate a Go HTTP server in your browser

Nicolas Lepage — Wed, 10 Feb 2021 11:30:20 +0000

Hi 👋 I'd like to share github.com/nlepage/go-wasm-http-server

Welcome to go-wasm-http-server 👋

Embed your Go HTTP handlers in a ServiceWorker (using WebAssembly) and emulate an HTTP server!

Examples

How?

Talk given at the Go devroom of FOSDEM 2021 explaining how go-wasm-http-server works:

The slides are available here.

Why?

go-wasm-http-server can help you put up a demonstration for a project without actually running a Go HTTP server.

Requirements

go-wasm-http-server requires you to build your Go application to WebAssembly, so you need to make sure your code is compatible:

no C bindings
no System dependencies such as file system or network (database server for example)

Usage

Step 1: Build to `js/wasm`

In your Go code, replace http.ListenAndServe() (or net.Listen()…

View on GitHub

This project allows you to build Go HTTP handlers to WebAssembly and embed it in a ServiceWorker to emulate an HTTP server!

I'd really appreciate to have feedback from people who would give it a try 🙂

The readme has a usage section and some examples to guide you.

Here is a video from FOSDEM 21 explaining how this works:

Contributions on the project are more than welcome.

Thanks!

JS tip: Create debug friendly unique references using String

Nicolas Lepage — Tue, 14 Jan 2020 08:20:41 +0000

Recently I've been facing a case where I needed to create some unique references.
I was creating a JS API and needed to maintain some internal state relative to elements created by the API.

In practice, I had a WeakMap where I maintained a private state for each public reference returned by the API.

Why a WeakMap?

The keys of a WeakMap are weak references, which means as soon as no one else holds the reference of a key, the key and its value get removed from the map and garbage collected.

The type of the public references didn't matter to me, I just needed unique references.
But it would be better if those references were easy to debug, which meant having at least a relevant toString() method.

⛔ Non choices ⛔

`{}`

What's the easiest way to create a unique reference in JS? Initializing an empty object!
But that doesn't satistfy the "easy to debug" requirement:

const ref = {}
console.log(`debug: ${ref}`)

// Output:
// debug: [object Object]

`String`

A string is easy to debug, you just print it:

let nextId = 1

const ref = `ref #${nextId++}`
console.log(`debug: ${ref}`)

// Output:
// debug: ref #1

But a string isn't a unique reference, anyone may obtain the same reference very easily.
And as a matter of fact, a WeakMap doesn't accept strings as keys, neither any other primitive type!

`Symbol`

The purpose of Symbol is to create unique references!
There I thought I had my solution...

let nextId = 1

const ref = Symbol(`ref #${nextId++}`)
console.log(`debug: ${ref}`)

// Output:
// TypeError: Cannot convert a Symbol value to a string

Wow! Far from what I expected...
Even though Symbol has a toString() method, putting it in a string interpolation yells at me!
Furthermore symbols are primitive values, hence WeakMap won't accept these as keys!

🟢 Solutions 🟢

`class`

There I found myself forced to write my own class:

let nextId = 1
class Ref {
  constructor() { this.id = nextId++ }
  toString() { return `ref #${this.id}` }
}

const ref = new Ref()
console.log(`debug: ${ref}`)

// Output:
// debug: ref #1

This is exactly what I wanted, but it feels like I'm squashing a fly with a sledgehammer...
Do I really have to create my own type?

`new String()`

Yes it's possible to use the String constructor, and it is equivalent to using a class:

let nextId = 1

const ref = new String(`ref #${nextId++}`)
console.log(`debug: ${ref}`)

// Output:
// debug: ref #1

It does create a unique reference, which isn't of a primitive type.
Hence it may be used as a key for a WeakMap!

Your turn!

Do you have any other ideas? Share them with me!

Thanks for reading, give a ❤️, leave a comment 💬, and follow me to get notified of my next posts.

Go channels in JS (Bonus 1): nil channel

Nicolas Lepage — Wed, 08 Jan 2020 07:14:54 +0000

This is a bonus post in the "Go channels in JS" series about how I wrote in JavaScript the equivalent of Go(lang) channels.
If you haven't already, I recommend reading at least the first post before reading this one:

Go channels in JS (1/5): Sending and Receiving

Nicolas Lepage for Zenika ・ Dec 2 '19

#javascript #go #node #tutorial

So did you know that Go allows using nil channels?
Now let's see how and why this is possible.

`nil` channel

Let's start by clarifying what is a nil channel.

So far when we wanted to create a channel, we used the make builtin function:

ch := make(chan int)

make returns a pointer to a channel, so a nil channel is just a nil pointer, in other words no channel at all:

// This a nil integer channel pointer:
var ch chan int

// Declared in a more explicit way:
var ch chan int = nil

So why would we need a nil channel?

You would think that sending to or receiving from a nil channel is an illegal operation, but it is actually allowed.
Both will block indefinitely!

Now the next question is how is this useful?
We don't want a goroutine to be blocked forever, this is actually a well known problem: a goroutine leak.

Well there is the select statement we haven't spoken of so far, which allows to wait for several channel operations at the same time:

func PrintValues(ints chan int, strings chan string) {
    for {
        select {
        case i := <-ints:
            fmt.Printf("Received integer: %d\n", i)
        case s := <-strings:
            fmt.Printf("Received string: %s\n", s)
        }
    }
}

But what if the sender closes the ints channel?
Receiving from a closed channel returns a nil value, so PrintValues will print "Received integer: 0" on the standard output indefinitely!

In order to avoid that, it is possible to use a nil channel to disable one case of the select:

func PrintValues(ints chan int, strings chan string) {
    for {
        select {
        case i, ok := <-ints:
            if !ok {
                ints = nil
                break
            }
            fmt.Printf("Received integer: %d\n", i)
        case s := <-strings:
            fmt.Printf("Received string: %s\n", s)
        }
    }
}

As soon as the ints channel is closed, we replace it by a nil pointer, which disables the first case of the select.

Of course we have to do the same for the strings channel, but it would end up blocking the entire select, and the goroutine executing it...
PrintValues must return when both channels are closed:

func PrintValues(ints chan int, strings chan string) {
    for {
        select {
        case i, ok := <-ints:
            if !ok {
                if strings == nil {
                    return
                }
                ints = nil
                break
            }
            fmt.Printf("Received integer: %d\n", i)
        case s, ok := <-strings:
            if !ok {
                if ints == nil {
                    return
                }
                strings = nil
                break
            }
            fmt.Printf("Received string: %s\n", s)
        }
    }
}

Run it on Go playground

Now that we know what nil channels may be used for, let's add the same feature to our JS channels.

Implementing `nil` channels

As our JS channels don't have a select for now, our implementation of nil channels will be partial.

The equivalent of a nil channel in JS will be a null or undefined channel.

So far when we created or executed send and receive operations, we didn't check at all that the channel key was actually defined or different of null.

Hence sending to or receiving from a null/undefined channel would have ended up in a TypeError somewhere in our code.

Now let's modify the existing send operation in order to accept null/undefined channel keys and return a never resolved Promise:

export const channelMiddleware = () => (next, ctx) => async operation => {
  // ...

  if (operation[SEND]) {
    if (!operation.chanKey) return new Promise(() => {})

    // Actually perform send operation...
  }

  // ...
}

The receive operation uses the doRecv() function, which is mutualized with the range operation (see previous post).
So let's modify the doRecv() function to also accept null/undefined channel keys and return a never resolved Promise:

const doRecv = async (ctx, chanKey) => {
  if (!chanKey) return new Promise(() => {})

  // Actually perform receive operation...
}

And that's it!
Of course, we just implemented the "bad part" of nil channels, and we will have to add the good part next time when implementing the select...

What next

Next time we will finally implement the select, and complete the full feature set of channels.

I hope you enjoyed this small bonus post, give a ❤️, 💬 leave a comment, or share it with others, and follow me to get notified of my next posts.

What the for? One loop to rule them all!

Nicolas Lepage — Tue, 31 Dec 2019 12:37:35 +0000

When I first learned that Go has only one keyword for loops, I thought to myself "What the f***? Aren't they oversimplifying things?".

Now, looking back, I think getting rid of while and do...while in favor of having only for, is a good choice.

I wouldn't say this is easier to learn for beginners. Replacing several keywords by several forms of the same keyword doesn't minimize what you have to learn as a total newbie.

However, having used Go for several years now, I feel comfortable with its for loop keyword. Writing it or reading it from other people's code always feels simple.

Now let's have a look at its different syntaxes.

Forever

Starting with my favorite one:

package main

import "fmt"

func main() {
    // Don't try this at home
    for {
        fmt.Println("To infinity and beyond!")
    }
    // This infinite loop prints a message to standard output
}

Run it on Go playground

Nice and pure, the infinite loop needs only the for keyword and its brackets.

This is compact, and in my opinion pretty intuitive.

Good ol' for

Of course there is the classic for, with an initialization, a condition, and an afterthought, separated by semicolons:

package main

import "fmt"

func main() {
    // Count to ten on standard output:
    for i := 1; i <= 10; i++ {
        fmt.Println(i)
    }
}

Run it on Go playground

Notice the absence of parentheses? Go doesn't have parentheses around statement's parameters.

Each part may be ommited:

package main

import "fmt"

// This function counts down from n to 1
func countDown(n int) {
    // No initialization is needed
    for ; n >= 1; n-- {
        fmt.Println(n)
    }
}

func main() {
    countDown(10)
}

Run it on Go playground

The two semicolons must be kept for the syntax to be valid (only one semicolon is forbidden).

You may omit all the parts, which is the equivalent of an infinite for loop.

For a while

If you need the equivalent of a while, that is a loop with only a condition, just use for like you would use a while:

package main

import "fmt"

// This function adds leading zeros to str
// in order ot reach a length of n
func padZeros(str string, n int) string {
    for len(str) < n {
        str = "0" + str
    }
    return str
}

func main() {
    // Prints "0000000123"
    fmt.Println(padZeros("123", 10))
}

Run it on Go playground

Not much to say, this is rather intuitive, still no parentheses.

`for...range`

A common use case is to iterate over a list of items.

This can be done using the range keyword in conjunction with for:

package main

import "fmt"

func main() {
    var messages = []string{"May", "the", "for", "be", "with", "you"}

    // Prints each message preceded by its index
    for i, message := range messages {
        fmt.Println(i, message)
    }
}

Run it on Go playground

As you can see, for...range allows to retrieve each index and its associated value.

range may also be used with maps, in which case it retrieves a key instead of an index.

If you need only the value, the index/key may be discarded using _:

package main

import "fmt"

func main() {
    var messages = []string{"May", "the", "for", "be", "with", "you"}

    // Prints each message
    for _, message := range messages {
        fmt.Println(message)
    }
}

Run it on Go playground

And in case you need only the index/key, the value may be ommited:

package main

import "fmt"

func main() {
    var messages = []string{"May", "the", "for", "be", "with", "you"}

    // Prints each message
    for i := range messages {
        fmt.Println(messages[i])
    }
}

Run it on Go playground

Finally, if you don't need the index/key or the value, both can be omitted:

package main

import "fmt"

func main() {
    var messages = []string{"May", "the", "for", "be", "with", "you"}

    // Allows you to iterate len(messages) times
    for range messages {
        fmt.Println("Do something...")
    }
}

Run it on Go playground

`for...range` with channels

Go is well known for its CSP concurrency model, which favors goroutines and channels over threads and mutexes.

for...range may also be used when receiving values from a channel:

package main

import "fmt"

func main() {
    ch := make(chan int) // Create a channel
    go send123(ch)       // Start send123() in a new goroutine

    // Receive and print integers from channel
    for i := range ch {
        fmt.Println(i)
    }
}

func send123(ch chan int) {
    // Send 3 integers through channel
    for i := 1; i <= 3; i++ {
        ch <- i
    }

    close(ch) // Close channel
}

Run it on Go playground

Used on a channel, for...range will wait for a value to be received at each iteration, blocking the goroutine which is executing it.

The loop ends when the channel is closed by the sending goroutine.

Conclusion

As you can see having only one keyword for loops doesn't change things much if you were used to C-style languages.

It makes for rather understandable code, which I think is one of the most important things if you have to work with a team.

I hope you enjoyed this quick introduction to Go's loops, give a ❤️, 💬 leave a comment, or share it with others, and follow me to get notified of my next posts.

Go channels in JS (4/5): Ranging

Nicolas Lepage — Mon, 23 Dec 2019 23:15:22 +0000

This post is the fourth of a series about how I wrote in JavaScript the equivalent of Go(lang) channels.

If you haven't already, I highly recommend reading at least the first post before reading this one:

Go channels in JS (1/5): Sending and Receiving

Nicolas Lepage for Zenika ・ Dec 2 '19

#javascript #go #node #tutorial

So far we have built an equivalent of Go channels in JS, which allows us to create channels, buffered or unbuffered, send values to these, receive values from these, and finally close these.

This time we will use the closing feature we added last time as a base to build a new feature: Ranging.

First, let's have a look at how to range over a channel in Go.

Ranging over channel

If you remember last time, we used the ability of the receive operator to return two values in order to know if a channel has been closed:

for { // This is like while (true)
  i, ok := <-ch
  if !ok {
    break
  }
  fmt.Println(i)
}

The second value returned by the receive operator is a boolean which tells us if something has actually been received.

However Go offers a better syntax to do the exact same thing, which is the range operator:

for i := range ch {
  fmt.Println(i)
}

This range loop will iterate over the values received from ch until this one is closed.

Let's take back our send123() example:

func main() {
  ch := make(chan int) // Create an integer channel

  go send123(ch) // Start send123() in a new goroutine

  // Receive an integer from ch and print it until ch is closed
  for i := range ch {
    fmt.Println(i)
  }
}

func send123(ch chan int) {
  // Send 3 integers to ch
  for i := 1; i <= 3; i++ {
    ch <- i
  }

  close(ch) // Close ch
}

This is much easier to read than last time!
Now how could we transpose this in JS?

Of course using a for ... of would be nice.
But for ... of uses the iterator protocol which is synchronous, whereas the receive operation is asynchronous.

Good news, JS has asynchronous iteration since ES2018, which comes with a new for await ... of syntax.
So we could create a new range operation, which would return an asynchronous iterable.

Let's try this with our send123() example:

async function* main() {
  const ch = yield chan() // Create a channel

  yield fork(send123, ch) // Start send123()

  // Receive a value from ch and log it to console until ch is closed
  for await (const i of yield range(ch)) {
    console.log(i)
  }
}

function* send123(ch) {
  // Send 3 integers to ch
  for (let i = 1; i <= 3; i++) {
    yield send(ch, i)
  }

  yield close(ch) // Close ch
}

Nice! Like in Go the code is much easier to understand, even if having a yield inside a for await ... of is not simple.

Now let's implement our new range operation!

Implementing ranging over channel

As usual we need an operation factory:

const RANGE = Symbol('RANGE')
export const range = chanKey => {
  return {
    [RANGE]: true,
    chanKey,
  }
}

We have only one chanKey argument which is the key of the channel we want to iterate over.

Then we have to handle range operations in the channel middleware:

export const channelMiddleware = () => (next, ctx) => async operation => {
  // ...

  if (operation[RANGE]) {
    // Handle range operation
  }

  // ...
}

for await ... of needs an asynchronous iterable, which is an object able to return an iterator.
A common pattern is to use the same object as iterable and iterator:

if (operation[RANGE]) {
  const it = {
    [Symbol.asyncIterator]: () => it,
  }

  return it
}

As you can see it returns itself when asked for an iterator, and will therefore satisfy the async iterable protocol.
Now it needs to implement the async iterator protocol.

All the async iterator protocol needs is an async next() function, which must return an object with two properties:

value which is the current value
done, a boolean which tells us if the iterator has ended, in which case value may be omitted

This looks a lot like the detailed receive operation we created last time, which returns a scalar with a value and a boolean which tells us if a value was actually received.
The only actual difference is that the boolean is inverted.

So we should be able to use the doRecv() function we created last time to implement next():

const it = {
  [Symbol.asyncIterator]: () => it,

  next: async () => {
    const [value, ok] = await doRecv(ctx, operation.chanKey)

    return {
      value,
      done: !ok,
    }
  }
}

And this is it! Well that was easy.
Let's try this out on repl.it with our send123() example (it uses esm to benefit from modules):

What next

With ranging done, we are not far from having the full feature set of channels, the only thing missing is select.

The last post "Go channels in JS (5/5): Selecting" will be a big one, I'll need some time to write it...
In the meantime I might publish some bonus posts (did you know that Go allows receiving from a nil channel?), so stay tuned.

I hope you enjoyed this fourth post, give a ❤️, 💬 leave a comment, or share it with others, and follow me to get notified of my next posts.

Go channels in JS (3/5): Closing

Nicolas Lepage — Tue, 17 Dec 2019 07:44:13 +0000

This post is the third of a series about how I wrote in JavaScript the equivalent of Go(lang) channels.

If you haven't already, I highly recommend reading at least the first post before reading this one:

Go channels in JS (1/5): Sending and Receiving

Nicolas Lepage ・ Dec 2 '19 ・ 11 min read

#javascript #go #node #tutorial

In the previous posts we built an equivalent of Go channels in JS.
We were able to create channels, buffered or unbuffered, send values to these, and receive values from these.

This time we will add a new feature to our JS channels: Closing.

But why the heck would we want to close a channel? Let's answer this for a start.

Closing channels

Closing a channel in Go is pretty easy, you just have to call the close() built-in function (built-in functions like close() and make() are available without importing any package):

func example() {
  ch := make(chan int) // Create a channel

  // Use the channel...

  close(ch) // Close the channel
}

Closing the channel has several effects.

First, it is not possible to send values to a closed channel, it will panic (throw an error) if you do.
Therefore it is always the responsibility of the sender to close a channel.

Second, once the channel's buffer is empty, the information that it is closed will be broadcasted to any further receivers.

But what does "broadcasting the information that it is closed" mean? How is this done in concrete terms?
Well a receive operation on a closed channel (with no values left in its buffer) will return instantly with a zero value.

Let's take back our send123() example from the previous posts:

func main() {
  ch := make(chan int) // Create an integer channel

  go send123(ch) // Start send123() in a new goroutine

  // Receive an integer from ch and print it to stdout 6 times
  fmt.Println(<-ch) // Prints 1
  fmt.Println(<-ch) // Prints 2
  fmt.Println(<-ch) // Prints 3
  fmt.Println(<-ch) // Prints 0
  fmt.Println(<-ch) // Prints 0
  fmt.Println(<-ch) // Prints 0
}

func send123(ch chan int) {
  // Send 3 integers to ch
  ch <- 1
  ch <- 2
  ch <- 3

  close(ch) // Close 
}

As you can see, once ch is closed, any further receive operation returns the zero value, which is 0 for integers.

We could make a loop to receive integers from ch and assert that it is closed as soon as we receive 0.
But what if we want to send 0 over ch?

We need a better way of knowing if the channel is closed.
And Go provides that by allowing to receive two values from a channel:

func example(ch chan int) {
  i, ok := <-ch

  if ok {
    fmt.Println("Received:", i)
  } else {
    fmt.Println("Channel closed")
  }
}

As you can see when receiving two values from a channel, the second value is a boolean which tells us whether we actually received something or not, in which case the channel is closed.

So let's use this second value to build a loop, and iterate over the integers received from send123():

func main() {
  ch := make(chan int) // Create an integer channel

  go send123(ch) // Start send123() in a new goroutine

  // Receive an integer from ch and print it until ch is closed
  for { // This is like while (true)
    i, ok := <-ch
    if !ok {
      break
    }
    fmt.Println(i)
  }
}

func send123(ch chan int) {
  // Send 3 integers to ch
  ch <- 1
  ch <- 2
  ch <- 3

  close(ch) // Close ch
}

Now how could we do the same thing in JS?

In JS it is not possible to return two values, but we can use a scalar.
However the receive operation won't be able know if we want only the value, or a scalar with the value and a boolean...

We are forced to add an optional argument to the receive operation, which we will use when we want to know if the channel is closed.
Now let's transpose our example to JS:

function* main() {
  const ch = yield chan() // Create a channel

  yield fork(send123, ch) // Start send123()

  // Receive a value from ch and log it to console until ch is closed
  while (true) {
    const [i, ok] = yield recv(ch, true)
    if (!ok) break
    console.log(i)
  }
}

function* send123(ch) {
  // Send 3 integers to ch
  yield send(ch, 1)
  yield send(ch, 2)
  yield send(ch, 3)

  yield close(ch) // Close ch
}

The second argument of our receive operation allows us to ask for a detailed receive by setting it to true.

And of course, there is the new close operation that allows us to close the channel.

Now let's add this closing feature to our JS channels!

Implementing channel closing

Let's start with the close operation.

Close operation

As usual we need an operation factory:

const CLOSE = Symbol('CLOSE')
export const close = chanKey => {
  return {
    [CLOSE]: true,
    chanKey,
  }
}

This operation needs only chanKey which is the key of the channel we want to close.

Then we also need a boolean in the channel's state in order to know if the channel is closed.
Let's initialize this boolean when we create a channel:

export const channelMiddleware = () => (next, ctx) => async operation => {
  if (operation[CHAN]) {
    const key = chanKey(operation.bufferSize)

    ctx[CHANS].set(key, {
      sendQ: [],
      recvQ: [],
      buffer: Array(operation.bufferSize),
      bufferLength: 0,
      closed: false, // New closed flag
    })

    return key
  }

  // ...
}

Finally we need to handle close operations in the channel middleware:

export const channelMiddleware = () => (next, ctx) => async operation => {
  // ...

  if (operation[CLOSE]) {
    const chanState = ctx[CHANS].get(operation.chanKey)

    if (chanState.closed) throw TypeError(`close on closed ${operation.chanKey}`)

    chanState.closed = true

    return
  }

  // ...
}

First we check if the channel was already closed, in which case we throw an error.
If not, we flag the channel as closed.

However this isn't enough, we also need to drain the waiting receivers out of the receive queue:

if (operation[CLOSE]) {
  // ...

  let recver
  while (recver = chanState.recvQ.shift()) recver([undefined, false])

  return
}

We are giving a scalar with an undefined value and a false boolean to the receiver, meaning that nothing was received and the channel is closed.
It will be the responsibility of the receiver to decide whether to return the scalar or only the value, but we'll talk about that later...

At this point you may wonder why we aren't checking the channel's buffer or even send queue.
But you have to remember that every operation leaves the channel in a stable state, so if we have receivers in the receive queue we can safely assert that there is no senders in the send queue and no values in the buffer.

And this is it for the close operation! Let's move on to the receive operation...

Receive operation

The receive operation must now be able to return either only the value, or a scalar with the value and a boolean, what we will call a "detailed receive".

So let's start by adding an optional detail argument to the operation factory:

const RECV = Symbol('RECV')
export const recv = (chanKey, detail = false) => {
  return {
    [RECV]: true,
    chanKey,
    detail,
  }
}

detail defaults to false, so by default a receive operation will return only the value.

Now let's use this new detail flag in the channel middleware.

We could use it in every case where we are returning from a receive operation... But we would duplicate the same code.
Instead, let's extract a new doRecv() function which will always return a detailed receive:

const doRecv = async (ctx, chanKey) => {
  const chanState = ctx[CHANS].get(chanKey)

  if (chanState.bufferLength !== 0) {
    const value = chanState.buffer[0]
    chanState.buffer.copyWithin(0, 1)

    // ...

    return [value, true]
  }

  const sender = chanState.sendQ.shift()
  if (sender) return [sender(), true]

  return new Promise(resolve => {
    chanState.recvQ.push(resolve)
  })
}

We return a scalar when receiving from the buffer or from the receive queue.

There is still the third case when we are pushing a receiver in the receive queue, this receiver must be called with a detailed receive, so let's keep this in mind for the send operation.

We also have to check if the channel is closed.
Receiving values from a closed channel is possible, hence we must do it only if its buffer and send queue are empty, just before pushing to the receive queue:

const doRecv = async (ctx, chanKey) => {
  // ...

  if (chanState.closed) return [undefined, false]

  return new Promise(resolve => {
    chanState.recvQ.push(resolve)
  })
}

If the channel is closed, we return a scalar with an undefined value and a false boolean, meaning that nothing was received.

Finally let's use our new doRecv() function in the channel middleware:

export const channelMiddleware = () => (next, ctx) => async operation => {
  // ...

  if (operation[RECV]) {
    const res = await doRecv(ctx, operation.chanKey)
    return operation.detail ? res : res[0]
  }

  // ...
}

Pretty simple, we are using the detail flag only once when doRecv() returns, to decide whether to return the scalar or only the value.

And this is it for the receive operation! Let's end with the send operation...

Send operation

This one is going to be much simpler.

The first thing we need to do is check that we are not sending on a closed channel:

if (operation[SEND]) {
  const chanState = ctx[CHANS].get(operation.chanKey)

  if (chanState.closed) throw TypeError(`send on closed ${operation.chanKey}`)

  // ...
}

Then all we have to do is make sure that we are giving a detailed receive when calling a receiver from the receive queue:

if (operation[SEND]) {
  // ...

  const recver = chanState.recvQ.shift()
  if (recver) {
    recver([operation.value, true])
    return
  }
}

We give to the receiver a scalar with the value and a true boolean, meaning that something has actually been received.

And we have made it! We are now able to close our JS channels.
Let's try this out on repl.it with our send123() example (it uses esm to benefit from modules):

What next

Next time, we are going to take full advantage of what we have built so far, and add a cool feature to our JS channels: Ranging!

So I have two more posts coming:

Go channels in JS (4/5): Ranging
Go channels in JS (5/5): Selecting

And maybe some bonus posts.

I hope you enjoyed this third one, give a ❤️, 💬 leave a comment, or share it with others, and follow me to get notified of my next posts.

Go channels in JS (2/5): Buffering

Nicolas Lepage — Tue, 10 Dec 2019 06:57:04 +0000

This post is the second of a series about how I wrote in JavaScript the equivalent of Go(lang) channels.

If you haven't already, I highly recommend reading the first post before reading this one:

Go channels in JS (1/5): Sending and Receiving

Nicolas Lepage for Zenika ・ Dec 2 '19

#javascript #go #node #tutorial

In the last post we built a basic equivalent of Go channels in JS.
We were able to create channels, send values to these, and receive values from these.

This time we will add a new feature to our JS channels: Buffering.

So let's start with a quick presentation of buffered channels in Go.

Buffered channels

Last time we saw that the send and receive operations of channels are blocking operations.
A send operation will block until a receive operation is ready on the same channel, and vice versa.

At least this is true for unbuffered channels, but a channel may have a buffer!
Let's take back our send123() example from last time, with a buffered channel:

func main() {
  ch := make(chan int) // Create an integer channel

  go send123(ch) // Start send123() in a new goroutine

  // Receive an integer from ch and print it to stdout 3 times
  fmt.Println(<-ch)
  fmt.Println(<-ch)
  fmt.Println(<-ch)
  fmt.Println(<-ch)
}

func send123(ch chan int) {
  // Send 3 integers to ch
  ch <- 1
  ch <- 2
  ch <- 3

  close(ch) // Close 
}

As you can see make() accepts a second argument which is the size of the channel's buffer.
Our channel ch now has a buffer with a size of 3, which means that it is able to store 3 values.

As a result, send123() doesn't have to wait for main() to be ready to receive from ch.
Of course the order of execution isn't deterministic, however it is possible that send123() sends the three integers at once to the channel, which will store these into its buffer.

The send operation becomes a non blocking operation.
And the reverse is also true, as long as ch has values in its buffer, receiving values from ch won't be a blocking operation for main().

However what happens if the buffer is "too small", if ch has a buffer of size 1 for example?
Well send123() will be able to perform only one non blocking send operation, then it will have to wait for a receive operation to free some space in the ch's buffer.

To sum it up:

Send operations block if the channel's buffer is full
Receive operations block if the channel's buffer is empty

Buffered channels are often used to smooth the execution of send/receive intensive processings.
With the right buffer size, it allows the different involved goroutines to face very few blocking time.

Let's transpose our example to JS:

function* main() {
  const ch = yield chan(3) // Create a buffered channel

  yield fork(send123, ch) // Start send123()

  // Receive a value from ch and log it to console 3 times
  console.log(`main() received ${yield recv(ch)}`)
  console.log(`main() received ${yield recv(ch)}`)
  console.log(`main() received ${yield recv(ch)}`)
}

function* send123(ch) {
  // Send 3 integers to ch
  yield send(ch, 1); console.log('send123() sent 1')
  yield send(ch, 2); console.log('send123() sent 2')
  yield send(ch, 3); console.log('send123() sent 3')
}

The only thing that has changed compared to last time, is the chan() operation factory which now accepts an optional buffer size.
We also added some logs in order to see the order of execution.
Now let's add this buffering feature to our JS channels!

Implementing buffered channels

Let's start with buffered channels creation.

Buffered channel creation

To begin with, we have to change our chan() operation factory in order to take a bufferSize argument:

export const chan = (bufferSize = 0) => ({
  [CHAN]: true,
  bufferSize,
})

bufferSize defaults to 0, so by default we will create an unbuffered channel.

Last time we decided to create channel keys using the String constructor, which ensures us a unique reference and gives us a toString() method out of the box.
We won't change that, but we can add the buffer size in the string for debug purposes:

let nextChanId = 1
const chanKey = bufferSize => new String(
  `chan #${nextChanId++} { bufferSize: ${bufferSize} }`
)

Now we must change our channelMiddleware, so that it will manage the creation of buffered channels.

For now our channels' state contained only a receive queue and a send queue.
Let's add the necessary to make buffered channels work:

export const channelMiddleware = () => (next, ctx) => async operation => {
  if (operation[CHAN]) {
    const key = chanKey(operation.bufferSize)

    ctx[CHANS].set(key, {
      sendQ: [],
      recvQ: [],
      buffer: Array(operation.bufferSize),
      bufferLength: 0,
    })

    return key
  }

  // ...
}

The buffer array will have two purposes:

it will store buffered values
its length will tell us the buffer's size (or capacity if you prefer)

And the bufferLength integer will tell us how many values there actually are in the buffer.

This should give us enough information:

does our buffer have values: bufferLength !== 0
is our buffer at full capacity: bufferLength === buffer.length

And now the fun part! We have to modify the send and receive operations to manage buffered channels.

Send to buffered channel

Until now when we sent a value to a channel, we did only two things: check the receive queue for a waiting receiver and send to it, or push a sender in the send queue.
Now we must also check if there is some place left in the buffer before pushing a sender in the send queue:

if (operation[SEND]) {
  const chanState = ctx[CHANS].get(operation.chanKey)

  const recver = chanState.recvQ.shift()
  if (recver) {
    recver(operation.value)
    return
  }

  if (chanState.bufferLength != chanState.buffer.length) {
    // Store value in the buffer
  }

  return new Promise(resolve => {
    chanState.sendQ.push(() => {
      resolve()
      return operation.value
    })
  })
}

Values should be received in the order they were sent so the buffer must be a FIFO queue, this means that we are always going to store values at then end of the buffer.
We cannot push values, because this would change buffer.length which tells us the buffer's capacity, but we can use bufferLength to know the index where to store our value:

if (chanState.bufferLength != chanState.buffer.length) {
  chanState.buffer[chanState.bufferLength++] = operation.value
  return
}

chanState.bufferLength++ allows use to store operation.value at the current chanState.bufferLength index and increment it afterward.

And this it! Now our channels will store values in the buffer as long as there is some space left, and push senders in the send queue only if the buffer is full.

Receive from buffered channel

Until now when we received from a channel, all we did was check the send queue for a waiting sender and receive from it, or push a receiver in the receive queue.
Now we must check if the buffer contains any values beforehand:

if (operation[RECV]) {
  const chanState = ctx[CHANS].get(operation.chanKey)

  if (chanState.bufferLength !== 0) {
    // Receive from buffer
  }

  const sender = chanState.sendQ.shift()
  if (sender) return sender()

  return new Promise(resolve => {
    chanState.recvQ.push(resolve)
  })
}

The buffer being be a FIFO queue, we have to take values from the head of the buffer.
And just like when receiving, we cannot use buffer.shift() or we would accidentally change the buffer's capacity.

What we should do is read the index 0 and then move all the buffer's values one index to the left without changing its length.
Arrays have a method for this called copyWithin:

if (chanState.bufferLength !== 0) {
  const value = chanState.buffer[0]
  chanState.buffer.copyWithin(0, 1)

  chanState.bufferLength--

  return value
}

We also decrement ch.bufferLength to reflect the new buffer's content.

But there is still a problem, when we free some space in the buffer, we should check if there are senders in the send queue.
Having a non full buffer and senders in the send queue would be an invalid state for the channel.

So let's check the send queue when we take a value from the buffer:

if (chanState.bufferLength !== 0) {
  const value = chanState.buffer[0]
  chanState.buffer.copyWithin(0, 1)

  const sender = chanState.sendQ.shift()
  if (sender) {
    chanState.buffer[chanState.bufferLength - 1] = sender()
  } else {
    chanState.bufferLength--
  }

  return value
}

If there is a sender in the send queue, we receive from it and put the value at the end of the buffer.
As a consequence we decrement chanState.bufferLength only if there is no sender in the send queue.

And this is it! We now have fully working buffered channels.

What next

Next time we are going to see how channels may be closed, maybe not the funniest part, but definitely a key feature of channels.

So I have three more posts coming:

Go channels in JS (3/5): Closing
Go channels in JS (4/5): Ranging
Go channels in JS (5/5): Selecting

I hope you enjoyed this second post, give a ❤️, 💬 leave a comment, or share it with others, and follow me to get notified of my next posts.

Go channels in JS (1/5): Sending and Receiving

Nicolas Lepage — Mon, 02 Dec 2019 12:20:36 +0000

This post is the first of a series about how I wrote in JavaScript the equivalent of Go(lang) channels.

I did this mainly for fun, I really like Go's concurrency model, and as a daily JS developer I thought it was a good challenge to recreate it in JS.

Whether you already know Go's concurrency model or not isn't important, I'll show very simple examples along the way, and it's a good opportunity to learn a different paradigm from Promise and async/await.

Furthermore, I'm making an extensive use of JS's generator functions, and some other funny things such as WeakMap or async iterables (with for await ... of), so you might also learn a few things about JS!

Now let's start with a short presentation of Go channels and their basic usage.

Go channels

Go has a really simple way of starting new threads (these are very lightweight threads called goroutine) with the go keyword:

func main() {
    go func1()
    ...
}

func func1() { ... }

In the above example, func1() will start in a new goroutine and execute concurrently with main().
The equivalent in JS would be calling an async function without using await:

async function main() {
    func1()
    ...
}

async function func1() { ... }

When several functions execute concurrently in JS, it is safe to share some memory between these.

This is one of the nice properties of JS's event loop, as a developer you don't have to ensure that you're accessing memory in a safe way, it is always the case!

This differs from Go where, if using shared memory, you must protect it using mutex to ensure that only one goroutine at a time is accessing some variable(s).

However in Go you also have the possibility to avoid the use of shared memory, and that's where channels come in handy:

func main() {
  ch := make(chan int) // Create an integer channel

  go send123(ch) // Start send123() in a new goroutine

  // Receive an integer from ch and print it to stdout 3 times
  fmt.Println(<-ch)
  fmt.Println(<-ch)
  fmt.Println(<-ch)
}

func send123(ch chan int) {
  // Send 3 integers to ch
  ch <- 1
  ch <- 2
  ch <- 3
}

In the above example, main() creates an integer channel, starts send123() in a new goroutine, and then receives an integer from the channel and prints it to standard output 3 times.
send123() sends 3 integers to the channel. On each side, the channel operations are blocking (main() will block until send123() sends an integer, and vice versa).

As you can see channels are pretty simple to use, and allow to avoid sharing memory between main() and send123() except for the channel reference.

So basically I've just said earlier that channels are useless in JS 🤪! They resolve the problem of shared memory which doesn't exist in JS...

But! There's more to channels. They offer a different way of programming concurrent applications, which might feel more natural to a lot of people.

They also come with some interesting concurrency patterns such as:

Pipeline
Fan in
Fan out
Timeout

Finally, I already said this but I'm going to repeat myself, I did this mainly for fun!
Now let's start exploring how we might implement channels in JS...

Implementing channels in JS

We now have a rough idea of what Go channels are and how they are used, but how could we implement the same thing in JS?

We could use async/await in some different ways:

Use a plain object to hold the state of a channel, and define send() and recv() async functions which would take a channel's state as first argument
Define a Channel prototype or ES6 class which would hold the state of a channel and have send() and recv() async methods

Or we could use generator functions and the yield keyword to hide the magic away: channels would be just references, and we would yield receive and send operations on these references.

I won't really discuss the pros and cons of using one solution or another here, I chose to use generator functions for the following reasons:

Generator functions (and the yield keyword) will allow us to implement channels with a way of working closer to that of Go channels
A friend and I have been developing a generator functions runner framework called Cuillere (🥄 spoon in french) and I love using it 😁

So now that we I have decided to use generator functions, we can imagine what the final result would look like.
Let's transpose our Go example with send123():

function* main() {
  const ch = yield chan() // Create a channel

  yield fork(send123, ch) // Start send123()

  // Receive a value from ch and log it to console 3 times
  console.log(yield recv(ch))
  console.log(yield recv(ch))
  console.log(yield recv(ch))
}

function* send123(ch) {
  // Send 3 integers to ch
  yield send(ch, 1)
  yield send(ch, 2)
  yield send(ch, 3)
}

Pretty cool! And using the yield keyword we are going to make sure that recv() and send() operations are blocking, just like in Go! (main() blocks until send123() sends an integer, and vice versa).

There are two additional operations:

chan() creates a new channel
fork() starts the execution of a generator function without waiting for it to complete (this one might look familiar if you are a redux-saga user)

Great! We have defined what we want, our goal now is to implement all the hidden mechanics which will allow this code to work.

But before diving into this, let me give you a short presentation of what cuillere is and how it is going to help us.

🥄 Cuillere! (queeyeah!)

CuillereJS is an extensible asynchronous execution framework based on generator functions.

So you are probably wondering why we created this Cuillere thing in the first place...
Well the goal of Cuillere is to abstract some inevitable technical complexity in plugins, and keep business code as simple and focused as possible.

At the time, we were working on a NodeJS/GraphQL backend API with a PostgreSQL database, and in order to ensure the integrity of our data we had to manage transactions properly.

I won't get into the details here, but managing transactions soon became a real pain for two reasons:

using a callback function every time we had to ensure a transaction was opened
passing the "transaction aware" PostgreSQL client everywhere we had to perform a database operation

Our code had become overly complex just because of transactions management... It was hard to read and often buggy!
That is when we created Cuillere, which allowed us to strip our business code from all the complexity of transactions management.

Here is a simple example of how cuillere is used with PostgreSQL:

const cuillere = require('@cuillere/core')
const {
  poolMiddleware, transactionMiddleware, queryMiddleware
} = require('@cuillere/postgres')

const cllr = cuillere(
  poolMiddleware({ /* postgres config */ }), // Manages connection pool
  transactionMiddleware(), // Manages transactions
  queryMiddleware() // Executes queries
)

const addUserAddress = (userId, address, setDefault) => cllr.call(function*() {
  const res = yield query({
    text: `INSERT INTO addresses (userId, street, postalcode, city)
           VALUES ($1, $2, $3, $4)
           RETURNING *`,
    values: [userId, address.street, address.postalCode, address.city]
  })
  if (setDefault) {
    const addressId = res.rows[0].id
    yield query({
      text: `UPDATE users
             SET defaultaddressid = $1
             WHERE userid = $2`,
      values: [addressId, userId]
    })
  }
})

As you can see the business code doesn't have to manage transactions, neither manipulate PostgreSQL clients.
It is all taken care of by the plugins!

The plugins are responsible for executing the operations yielded by the business code.
Cuillere gives them a context object, which they can use to store state or communicate for example.

I will probably write some more about Cuillere itself in the future, for now let's focus back on our JS channels...

Implementing channels

We are going to need a channel plugin to give to Cuillere, which will take care of channel operations (creation, sending and receiving):

const cllr = cuillere(
  channelMiddleware()
)

cllr.call(function* () {
  const ch = yield chan()
  // ...
})

It is in this channelMiddleware that we are going to implement all the mechanics to make channels work as expected.

The signature of a cuillere middleware is pretty simple (the first level of currying isn't necessary, but it is a convention to have a factory):

export const channelMiddleware = () => (next, ctx) => async operation => {
  // ...
}

The middleware has a first level with the next and ctx arguments:

next is the next middleware and should be called when the current middleware doesn't know how to handle the received operation
ctx is the context object

The second level of the middleware has the operation argument, and is called each time an operation is yielded.

Let's start by implementing all the mechanics for creating a channel.

channel creation

The first thing we need is a factory for channel creation operations:

const CHAN = Symbol('CHAN')
export const chan = () => {
  return {
    [CHAN]: true
  }
}

We use an unexported Symbol to mark the operation and be able to recognize it in the middleware:

export const channelMiddleware = () => (next, ctx) => async operation => {
  if (operation[CHAN]) {
    // Create channel
  }

  return next(operation)
}

As I said earlier we want the channels to be just references. We could use empty plain objects, but for debugging purposes let's use something a little less opaque:

let nextChanId = 1
const chanKey = () => new String(`chan #${nextChanId++}`)

The String constructor gives us a unique reference (new String('foo') !== new String('foo') is always true), with a ready to use toString() method.

Creating a new channel reference isn't enough, we also need to initiate the channel's state and store it somewhere.
Cuillere's context is precisely made for storing this kind of information, so let's use it:

if (operation[CHAN]) {
  const key = chanKey()
  if (!ctx[CHANS]) ctx[CHANS] = new Map() // another Symbol we created
  ctx[CHANS].set(key, {
    // channel's initial state
  })
  return key
}

We create the channel's key, store it's initial state, then return the key.
We also initialize a Map to store the channels' states if not already done (Why a Map? Well unlike plain objects whose keys need to be plain strings, Maps accept any type of keys).

This is not bad but there is still a problem, the Map will keep the channel's key and state references forever and prevent them to be garbage collected when the channel isn't used anymore...

Ideally we would like the channel's key and state to be garbage collectable as soon as no one else holds the channel's key reference anymore.
Well this is one of the use cases for WeakMaps, their keys are week references therefore their content is naturally cleaned up by the garbage collector.

Let's use a WeakMap instead of a Map:

if (!ctx[CHANS]) ctx[CHANS] = new WeakMap()

Now we have to decide what the channel's initial state should be. What do we need to make the receive and send operations work?
Something to store waiting senders and receivers should be enough for now, let's call that the receive queue and send queue:

ctx[CHANS].set(key, {
  recvQ: [],
  sendQ: [],
})

Nice! I think we are ready to move on and start implementing the receive and send operations.

One last thing that can be improved for the channel creation is the WeakMap initialization.
Cuillere has a special start operation which happens only once just after calling cllr.call(), let's use this instead of a lazy initialization:

if (isStart(operation)) ctx[CHANS] = new WeakMap()

Our complete code now looks like this:

import { isStart } from '@cuillere/core'

const CHANS = Symbol('CHANS')

const CHAN = Symbol('CHAN')
export const chan = () => {
  return {
    [CHAN]: true
  }
}

let nextChanId = 1
const chanKey = () => new String(`chan #${nextChanId++}`)

export const channelMiddleware = () => (next, ctx) => async operation => {
  if (isStart(operation)) ctx[CHANS] = new WeakMap()

  if (operation[CHAN]) {
    const key = chanKey()
    ctx[CHANS].set(key, {
      recvQ: [],
      sendQ: [],
    })
    return key
  }

  return next(operation)
}

And now the fun begins! Let's start with the receive operation.

Receive from a channel

Just like the channel creation, the receive needs an operation factory, except this time we need to give the channel's key from which we want to receive:

const RECV = Symbol('RECV')
export const recv = (chanKey) => {
  return {
    [RECV]: true,
    chanKey,
  }
}

Then we must handle the operation in the middleware:

export const channelMiddleware = () => next => async (operation, ctx) => {
  // ...

  if (operation[RECV]) {
    const chanState = ctx[CHANS].get(operation.chanKey)

    // Receive from channel...
  }

  return next(operation)
}

We fetch the state of the channel from the context using the channel's key of the operation.

Now there are two possibilities when receiving from a channel:

the send queue has senders: we receive from the first sender
the send queue is empty: we add a receiver in the receive queue

Let's handle the case of a non empty send queue first:

if (operation[RECV]) {
  // ...

  const sender = chanState.sendQ.shift()
  if (sender) return sender()
}

This is pretty straightforward, we just shift the first sender from the send queue (shift() returns undefined if the send queue is empty).
If the sender is defined we call it to get the value and return it right away.

Now let's handle the case of the empty send queue:

if (operation[RECV]) {
  // ...

  return new Promise(resolve => {
    chanState.recvQ.push(resolve)
  })
}

This is pretty simple too, we create and return a new Promise and push its resolve function at the end of the receive queue.
As soon as a sender will call the receiver with a value, the Promise will be resolved.

As you can see, by using push() and shift() on both the receive and send queues, we can make them act as FIFO queues.

And we are done with the receive operation! Let's move on to the send operation.

Send to channel

The send operation's factory looks like the receive operation's one with one more argument:

const SEND = Symbol('SEND')
export const send = (chanKey, value) => {
  return {
    [SEND]: true,
    chanKey,
    value,
  }
}

value is the value to be sent to the channel.

Now let's handle the operation in the middleware:

export const channelMiddleware = () => (next, ctx) => async operation => {
  // ...

  if (operation[SEND]) {
    const chanState = ctx[CHANS].get(operation.chanKey)

    // Send to channel...
  }

  return next(operation)
}

Just like when receiving, there are two possibilities when sending to a channel:

the receive queue has receiver: we send to the first receiver
the receive queue is empty: we add a sender in the send queue

The case of a non empty receive queue should be pretty straightforward:

if (operation[SEND]) {
  // ...

  const recver = chanState.recvQ.shift()
  if (recver) {
    recver(operation.value)
    return
  }
}

We shift the first receiver from the receive queue and, if it is defined, we call it with the operation's value, then we return right away.

The empty receive queue case is a little more complex:

if (operation[SEND]) {
  // ...

  return new Promise(resolve => {
    chanState.sendQ.push(() => {
      resolve()
      return operation.value
    })
  })
}

We create and return a new Promise, but this time we cannot push the raw resolve function in the senders queue.
We have to create a sender arrow function which resolves the Promise and returns the operation's value.

🎉 And this is it! We have all we need to make our send123() example work (we don't need to implement the fork operation which is already built into cuillere).

The full example is available on repl.it (it uses esm in order to benefit of modules):

What next?

As you already know or as you may have guessed, Go channels offer a larger feature set than just sending and receiving values:

channels may have a buffer
channels may be closed
range lets you iterate over a channel
select lets you wait on multiple channel operations

So I have four more posts coming in which I will implement the full feature set of channels:

Go channels in JS (2/5): Buffering
Go channels in JS (3/5): Closing
Go channels in JS (4/5): Ranging
Go channels in JS (5/5): Selecting

I hope you enjoyed this first post, give a ❤️, 💬 leave a comment, or share it with others, and follow me to get notified of my next posts.

DEV Community: Nicolas Lepage

Testing Go WebAssembly code on Github actions

Complete setup

Gopher drawings!

nlepage / gophers

Some gophers 🐻

Gophers 🐻

Gophers

Dukes

Miscellaneous

Uncolored

License

Emulate a Go HTTP server in your browser

nlepage / go-wasm-http-server

Embed your Go HTTP handlers in a ServiceWorker and emulate an HTTP server!

Welcome to go-wasm-http-server 👋

Examples

How?

Why?

Requirements

Usage

Step 1: Build to js/wasm

JS tip: Create debug friendly unique references using String

Why a WeakMap?

⛔ Non choices ⛔

{}

String

Symbol

🟢 Solutions 🟢

class

new String()

Your turn!

Go channels in JS (Bonus 1): nil channel

Go channels in JS (1/5): Sending and Receiving

Nicolas Lepage for Zenika ・ Dec 2 '19

nil channel

Implementing nil channels

What next

What the for? One loop to rule them all!

Forever

Good ol' for

For a while

for...range

for...range with channels

Conclusion

Go channels in JS (4/5): Ranging

Go channels in JS (1/5): Sending and Receiving

Nicolas Lepage for Zenika ・ Dec 2 '19

Ranging over channel

Implementing ranging over channel

What next

Go channels in JS (3/5): Closing

Go channels in JS (1/5): Sending and Receiving

Nicolas Lepage ・ Dec 2 '19 ・ 11 min read

Closing channels

Implementing channel closing

Close operation

Receive operation

Send operation

What next

Go channels in JS (2/5): Buffering

Go channels in JS (1/5): Sending and Receiving

Nicolas Lepage for Zenika ・ Dec 2 '19

Buffered channels

Implementing buffered channels

Buffered channel creation

Send to buffered channel

Receive from buffered channel

What next

Go channels in JS (1/5): Sending and Receiving

Go channels

Implementing channels in JS

🥄 Cuillere! (queeyeah!)

Implementing channels

channel creation

Receive from a channel

Send to channel

What next?

Step 1: Build to `js/wasm`

Why a `WeakMap`?

`{}`

`String`

`Symbol`

`class`

`new String()`

`nil` channel

Implementing `nil` channels

`for...range`

`for...range` with channels