DEV Community: Tonghe Wang

Some thoughts on Rust and Elm

Tonghe Wang — Sun, 05 Mar 2023 12:00:23 +0000

Last week, my friend Joe asked me what's the best way to learn a programming language.

I replied: Go through the basics as quickly as possible. Then begin building things with it. This is how I learn Golang.

I had been curious about Rust for a while. And a coworker talked about how Rust was his favorite language with a lot of exuberance. I thought to myself, maybe I could do the same with Rust.

I was intimidated by “the Rust book”. It's a huge book of I don't know how many pages. And I never got past hello world and the curious exclamation mark after println.

That's when I discovered Tour of Rust after some random Googling. Tour of Rust is a pleasant introduction to the basic syntax and concepts of Rust. With a compiler on the right side of the page, it adds some nice interactivity to the tutorial. It makes it easier to understand when you can try and change things and see how it fails.

So far my feeling is a few concepts (borrowing and referencing) in Rust are quite clever. I don't understand under what circumstances lifetime needs to be managed manually. Then it feels like a few things are added as an afterthought, which leads to a certain degree of internal incongruity in its syntax.

Yet despite the tribal sentiment among Go developers and Rust developers, these languages feel more similar than different.

Curiously, after searching Rust on YouTube, the algorithm god recommended a million Elm talks with one of them promising to give you happiness.

Incidentally, I read a blog post from the Warp team about building a UI in Rust.

In a gist, it was difficult to build a UI in Rust if they followed the widget tree approach of Flutter. Because multilayers of object inheritance do not feel natural or intuitive in Rust.

Although they used a close but different approach, the Model-View-Update approach used in the Elm architecture was an inspiration for the Warp team.

To use an inaccurate analogy in React terms, Model is like Redux, it manages all the states in your entire app. View manages the virtual DOM that renders the page as the states change. Update makes changes to the state upon receiving messages (events) when the user interacts with your app. Pretty neat.

What's charming about Elm is it's easier, way easier, linting and debugging that works out of the box. You don't need to configure anything, it just works. This is so much better than React.

But you do need to learn a new language and get used to the functional programming way of thinking.

Bottom line: Rust and Elm are both fun. Don't know if or when they will be useful at work.

Go GUI: Trying out Fyne

Tonghe Wang — Sun, 09 Oct 2022 20:33:59 +0000

The idea of building a piece of software once and run it everywhere is certainly charming. And Go supports cross-compiling out of the box.

Fyne is a very promising GUI package for Go that helps you build a GUI app and cross-compile it all devices and OSes.

Heres is a simple example

This code gives you a small window with a label and input field. Grab this piece of code, init a mod and tidy it, and you are good to go.

package main

import (
    "fyne.io/fyne/v2/app"
    "fyne.io/fyne/v2/widget"
    "fyne.io/fyne/v2/container"
)

func main() {
    a := app.New()
    w := a.NewWindow("Hello, you!")

    l := widget.NewLabel("Hello! What is your name?")
    e := widget.NewEntry()
    e.SetPlaceHolder("Input your name...")

    w.SetContent(container.NewVBox(l, e))
    w.ShowAndRun()
}

First, we define an app in a. Then we define a window w with title “Hello, you!”.

Then we create a new label and a new input field (entry). These are all “widgets”. So their constructors are inside the widget package. We set a placeholder for the input field for good measure.

Next we create a vertical box (which is a container) and set it as the content of the window w.

When we build and run this program, this is how it looks like:

You might have noticed the quirks. When you resize the window, you can see the content shivers. This is because Fyne tries to automatically adjust the window size and layout.

And when you try to display something that's not rendered by the default typeface, it becomes a block. CJK characters, Arabic letters and emojis are all mangled.

Using a custom font

In order to correctly display Unicode characters, you need to bundle a custom font and include it in your custom theme. Then this font is applied globally to your app as part of the theme. From what I read the issues section, as of now only TTF is supported.

I downloaded Source Han Serif in TTF format. And ran this command to bundle it as a resource.

fyne bundle SourceHanSerifSC.ttf > bundled.go

Next thing we do is get a theme from one of Fyne's demo apps – “Notes”.

The only thing we need to do is change the name of the font in Font() method in theme.go:

func (m *myTheme) Font(s fyne.TextStyle) fyne.Resource {
    return resourceSourceHanSerifSCTtf
}

See? Not bad.

Data-binding

I grabbed the theme from Fyne Notes and didn't change the color. That explains the yellow background color. New theme is applied by calling the SetTheme() method.

In this example, whenever the user types in or clears the text field, the greeting changes. This is done by setting up data-binding. (If the action to link two things is “binding”, then each of the two things are “bound” together. I guess I'll call them “bound variables” and “bound widgets”.)

First we need to declare bound string variables. Then we need to use these variables to create bound widgets. Note you use different methods to create bound widgets.

At this point, we need to link the two bound variables. There are methods that allow bi-directional conversion between a number and a string. Some conversion methods even support string formats. There's also a method to convert strings to and from a URI.

But it seems the only way to change greeting whenever userinput changes is adding a listener. To add a listener, you need to create a data listener from an anonymous function.

With this, whenever userinput changes, the callback function is executed. Notice how we get and set the value of a bound variable.

package main

import (
    "fmt"
    "fyne.io/fyne/v2/app"
    "fyne.io/fyne/v2/widget"
    "fyne.io/fyne/v2/container"
    "fyne.io/fyne/v2/data/binding"
)

func main() {
    a := app.New()
    // Setting the theme. `myTheme` is defined in `theme.go`
    a.Settings().SetTheme(&myTheme{})
    w := a.NewWindow("你好 Hello")

    // Declare two binding string variables
    greeting := binding.NewString()
    userinput := binding.NewString()

    // Adding a listener
    userinput.AddListener(
        binding.NewDataListener(func() {
            if val, ok := userinput.Get(); val == "" || ok != nil {
                greeting.Set(
                    "你叫什么名字？\nWhat is your name?"
                    )
            } else {
                greeting.Set(
                    fmt.Sprintf("你好，%s！\nHello, %s!", val, val)
                    )
            }
        }))

    // Creating binding widgets
    l := widget.NewLabelWithData(greeting)
    e := widget.NewEntryWithData(userinput)

    w.SetContent(container.NewVBox(l, e))
    w.ShowAndRun()
}

A few words

I tried two other pure-Go GUI packages. They are Gio and Nuxui. Both are ingenious projects. (There are quite a few other packages that help bind Go apps to more established GUI engines.)

Gio seems much more flexible than Fyne. And the way it uses contexts and channels seems more Go-ish. But typing Chinese in the input field simply doesn't work. The way an IME for CJK works is you type a sequence of letters, a popup menu shows up, from which you to choose a character or a word. Ideally, when an IME is active, keydown events should not be registered. The input field should only get data when a word has been composed in IME and is “committed” (selected by the user). But when you type in Gio's default input field, each letter in the sequence, as well the committed word, are all registered in the input field. This probably has to do with how Gio handles keyboard events.

Nuxui uses a backtick-wrapped string to declaratively define the UI. This is way less cumbersome than calling a bunch of nested constructors. I didn't spend too much time on it as breaking changes are introduced to some basic functions from v0.6 to 0.8. This resulted in some sample projects failing to compile.

I spent the most time on Fyne because Fyne is the best documented among the three. There are a few demo videos and even a book!

Fyne is designed with unit testing in mind. It provides helper functions to mock events. It supports comparing to snapshots to ensure correct rendering of UI.

Fyne is also well structured. Although so much so that it occasionally feels there's too much boilerplate.

But all in all, Fyne is great and very promising. I had a great time playing with it. I'm sure you will too.

#15

Tonghe Wang — Wed, 05 Oct 2022 08:35:34 +0000

Table-driven tests

Go has superb built-in support for good programming practices, such as test-driven development. In fact, I'm learning a lot about TDD while learning Go from this book: “Learn Go with Tests”.

If you want to test a bunch of similar inputs and outputs, it's handy to run table-driven tests. What you do is list input values and expected output in an array, then loop through all the test cases.

I found this blog post by Lorenzo Peppoloni quite helpful. It gives examples in both Golang and Python for table-driven tests.

Create your own keyboard layout optimized to reduce finger fatigue

We all push buttons for a living. Most of us spend enormous amount of time with the Qwerty keyboard layout.

I came across this fascinating video about making your own perfect keyboard layout.

By perfect, “adumb” refered to the shortest distance your fingers travel while typing on the keyboard. And the corpus he used to calculate the total distance is arXiv abstracts.

He first randomly generated keyboard layouts then crossed over the best ones. Until after 1000 generations of crossover, the total finger travel distance stopped decreasing.

If I were to make a keyboard layout, I would use a larger corpus that includes English, Swedish, Chinese as typed using Pinyin, and a bunch of programming languages.

On top of the larger number of symbols to rearrange, when you type CJK (and other complex, non-alphabetic) languages, you need to deal with the complicated relationship between the input method and the keyboard layout, especially on Linux.

zsh

For quite a while, I found I couldn't use commands I clearly had installed properly (macOS 12.2).

After some digging, I used an export command in .zshrc file and forgot to include $PATH: when setting the PATH value.

This answer on StackOverflow was helpful.

Using prepared statements & pointers in Golang

Tonghe Wang — Tue, 26 Jul 2022 18:36:00 +0000

In MySQL, you can use a question mark (?) in a prepared statement to stand in for a value.

func GetUserId(name string) (int, error) {
  stmt, err := dbconn.Db.Prepare(`SELECT id FROM user
    WHERE name="?";`) // (1) - BAD
  stmt, err := dbconn.Db.Prepare(`SELECT id FROM user
    WHERE name=?;`) // (2) – GOOD
  if err != nil {
    log.Fatal(err)
  }
  defer stmt.Close()

  var userId int
  err = stmt.QueryRow(name).Scan(&userId) // (3)
  if err != nil {
    if err != sql.ErrNoRows {
      log.Fatal(err)
    }
    return 0, err
  }
  return userId, nil
}

In the Go code above, dbconn is a connection to a MySQL server. Line 1 defines a prepared statement. And Line 3 queries the table for a row where the name column matches the value of variable name. I assumed the ? in this query would be interpolated with an actual string. I added quotation marks since they are needed around strings in MySQL CLI.

This fails to return anything. Removing the quotation marks solved the problem. The correct code is on Line 2.

I also find Line 3 quite interesting. Here, first, stmt.QueryRow() returns a pointer to a sql.Row object. Its Scan() method then does two fascinating things: a) it sets a “dest” to the output value and b) returns an error if there's an error or nil if there's no error.

Thingy a is quite interesting. In this case, Scan() method will find the memory address of variable userId and write the output value (the user's ID) there.

It feels as if getting the value from a DB is a side effect.

The same goes when you decode a JSON string. In this example, on Line 4, Unmarshal() method unpacks the JSON string and writes it to &animals, the address of animals variable. And this is a side effect. The return value is again, either an error or nil — if there is an error, you simply can't ignore it.

var jsonBlob = []byte(`[
    {"Name": "Platypus", "Order": "Monotremata"},
    {"Name": "Quoll",    "Order": "Dasyuromorphia"}
]`)
type Animal struct {
    Name  string
    Order string
}
var animals []Animal
// (4)
err := json.Unmarshal(jsonBlob, &animals)

A study of bugs

Tonghe Wang — Wed, 20 Jul 2022 06:11:34 +0000

I changed the name of my blog to “A study of bugs”.

It had been called “my notes”. But that feels quite formal. It suggests there are concrete thoughts presented in them. (Maybe I feel this way because in a zettelkasten system, each note is supposed to be a self-contained bit of thought.)

In programming and debugging, I see bugs and solve them. Each bug is bewildering in its own way. Solving them problems they pose is usually a haphazard fumbling.

All I’m saying is I like this new name a lot.

Emulating Python's zip() and zip_longest() in JavaScript

Tonghe Wang — Tue, 21 Sep 2021 22:28:24 +0000

This is essentially how you emulate the way Python's zip() function works using JavaScript.

let a = [1, 3, 5];
let b = [2, 4, 6];
const mapping = a.map((item, idx) => [item, b[idx]]);
console.log(mapping);
// result
[ [ 1, 2 ], [ 3, 4 ], [ 5, 6 ] ]

What makes this possible is the fact that JavaScript array methods — map(), forEach() and even filter() — take up to three arguments (element, index, array) while they iterate through the array.

In which element is the element that the iterator points to at each step, index is the index of this item in the original array. And it's worth noting the third argument is the original array.

Since map() method of the JavaScript array is more flexible than zip(), we can do more stuff to the iterated item or the array. But if you want to do anything with array, remember the original array changes accordingly. In this case, a:

let a = [1, 3, 5];
let b = [2, 4, 6];
const mapping = a.map((item, idx, array) => { 
    array.push(item*2);
    return [item, b[idx]]} );
console.log(mapping);
// Result
[ [ 1, 2 ], [ 3, 4 ], [ 5, 6 ] ]
console.log(a);
// Result
[ 1, 3, 5, 2, 6, 10 ]

As we can see, integers 2, 6 and 10 are pushed to the end of the array.

Python provides a zip_longest() function in itertools.

While zip() cuts off longer lists to fit the shortest, zip_longest() stretches shorter lists to match the longest. Empty slots in shorter lists are filled with a given value. By default this fillvalue is None.

This is how this function works:

import itertools

a = [1, 3, 5, 7, 9]
b = [-1, -3, -5]
c = itertools.zip_longest(a, b)

print(list(c))
# Result
[(1, -1), (3, -3), (5, -5), (7, None), (9, None)]

Below I try to emulate this function in JavaScript.

First let's take a look at line 👀. Notably, In order to take indefinite number of arguments, I'm using the ellipsis operator. Unlike unpacking a list using the star operator (*) in Python, using something like ...args, fillvalue=null will raise an error. So I have to use a pair of square brackets to allow for a fillvalue argument. (Let's give it a duck.)

let a = [5, 3, 1, -1, -3, -5]
let b = [6, 4, 2, 0, -2, -4, -6, -8]
let c = ['a', 'b', 'c', 'd']

const zipLongest = ([...args], fillvalue=null) => {  👀
    const result = []
    let i=0
    while (args.some( argArray=> argArray[i])) {
        const ithColumn = args.map(
            argArray=> {
              item = (typeof argArray[i] === 'undefined')  👓
              ? fillvalue
              : argArray[i]
              return item
            }
            )
            result.push(ithColumn)
            i++
    }
    return result
}

console.log(zipLongest([a, b, c], fillvalue="duck"))

// Result
[
  [ 5, 6, 'a' ],
  [ 3, 4, 'b' ],
  [ 1, 2, 'c' ],
  [ -1, 0, 'd' ],  🙄
  [ -3, -2, 'duck' ],
  [ -5, -4, 'duck' ],
  [ 'duck', -6, 'duck' ],
  [ 'duck', -8, 'duck' ]
]

Then let's move to line 👓. Empty slots in the JavaScript array are considered undefined.

But undefined and other falsy values, eg empty strings and 0, all evaluates to false. This will confused this ternary conditional. As a result we will get [ -1, undefined, 'd' ] on line 🙄.

A better way is to check the type of item as we iterate. However, a wrong way to do it is using typeof nonExistentValue === undefined.

Although the nonExistentValue is indeed not defined, typeof returns "undefined", which is a string. And this string is a string. It is by no means equal to the reserved word for non-existent things. Thus the condition we used on line 👓.

Don't Edit Hosts File With Nano on a Mac

Tonghe Wang — Tue, 21 Sep 2021 22:23:20 +0000

TLDR: If you are using a Mac, don't edit your hosts file with Nano and save it in Mac format. It will cause bizarre bugs in places you won't expect. If you are seeing bugs on a Mac with errors saying localhost is missing, try opening the hosts file and save it with Unix line ending.

I learned this while working on a React Native project, where Expo's development server just wouldn't start up. After a long and patient wait, an elaborate error message showed up. In which the most eye-catching line said:

RangeError [ERR_SOCKET_BAD_PORT]: options.port should be >= 0 and < 65536. Received 65536.

After multiple trials, including upgrading Node.js to the latest version and upgrading Catalina to Big Sur, this bug persisted.

Taking a second look at the error message, the package in question was actually freeport-async.

Googling around did help. Although I didn't see anyone sharing a bug quite like mine, some on the internet did share how they solved a bug by editing the source code of freeport-async.

What freeport-async does is check available ports on your localhost within a specified range. It has async in its name because it returns a promise.

I didn't actually need it to find an available port on my machine. I wasn't running many servers anyway. So I commented out almost all the code. And asked freePortAsync() to return a determinate number 19000, in consistency with 19xxx ports used by Expo. It worked.

It was certainly a dirty hack. But I still felt quite good about myself.

However, there were some quirks. While I could preview my app in an iOS simulator, I couldn't see it in a web browser.

Then a few bizarre error messages flashed back in my mind. Before this, whenever I created new React projects, although the development server started up fine, I couldn't reach it at localhost:3000. Weird though, 127.0.0.1:3000 would always work.

Looking through my notes, Node.js once also gave an error messages related to localhost, saying:

getaddrinfo ENOTFOUND localhost
Error: getaddrinfo ENOTFOUND localhost
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:71:26)

I was absolutely baffled because I've checked — and at times edited — the hosts file on my Mac a million times. There had always been an entry for localhost pointing to 127.0.0.1.

Until I found this comment by Satya in a quarter of StackExchange for Apple users:

After living with this for a long time, I figured out (by checking from the Sublime editor) that the issue with my /etc/hosts file was that the "Line Endings" on the file were set to "Mac OS". When I changed the line endings to "Unix", I am able to ping localhost in the terminal and stuff's working as expected.

Every time I needed to edit something in a protected directory, out of convenience, I had always used sudo nano <filename>. When saving the file, I'd always choose Mac Format — Why wouldn't I? I'm using a Mac after all.

I opened up hosts file and saved it with Unix-style LF line ending. Restarted the computer. All the bugs mentioned above just disappeared!

Googling keywords “React Native” or “Expo” didn't give me a solution because it was not a problem of React Native or Expo. Besides, who would've expected Mac OS to be tripped up by a config file saved with Mac line ending?