DEV Community: Mathijs Vogelzang

Stellar Quest Out of Control: how I shot 100 asteroids with fewer than 300 bytes of WebAssembly

Mathijs Vogelzang — Tue, 07 Mar 2023 14:34:23 +0000

Stellar (the organization behind the Stellar Lumen cryptocurrency) organizes programming competitions, called "Stellar Quests". From February 15th to March 1st 2023, the competition revolved around a game called “Asteroids”, where you control a spaceship that moves through galaxies containing fuel pods and asteroids. To win, you need to shoot 100 asteroids without running out of fuel. The full instructions of this game are available on the official website.

This stellar quest had three categories: Fast (first submitted solution), Cheap (most efficient solution), and Out of Control (smallest solution). Read how I found a solution of fewer than 300 bytes of WebAssembly (WASM) code on my blog

Streamline your git workflow with HighFlux: the automated git client

Mathijs Vogelzang — Thu, 15 Dec 2022 16:23:13 +0000

Do you ever forget to commit a crucial file and end up with a broken build? Or your latest work is on your desktop, and you can't continue working on your laptop because you forgot to push? These are common challenges for developers, and we want to fix those with HighFlux.

Read the full article about HighFlux here!

Rust, Tauri, and React: Our Technology choices for a desktop app in 2022

Mathijs Vogelzang — Tue, 06 Dec 2022 15:47:58 +0000

We built HighFlux, a transformative git client this year. Given the desired functionality (synchronize code to the cloud while a developer is writing it), we needed to build an app that runs on the developer’s machine. We come from a background in mobile apps (mainly Android) and web apps, so this was an exciting journey. In this post, I want to share our decisions and what we learned.

Read the full post on our blog!

What makes git so hard to use?

Mathijs Vogelzang — Wed, 16 Nov 2022 21:44:33 +0000

Git is a beautiful work of engineering. It's blazingly fast even on
massive repositories, and it efficiently manages vast numbers of
branches.

These qualities have made git the dominant source control system, even
though it's hard for humans to use.

So what's wrong with git?

Git commands are too many, too low-level and hard to understand.

The git program is a collection of 157 commands:

The sheer number of commands is a problem. Even though it's pretty easy
to master the most common 10 commands for day-to-day coding, you often
run into commands you've never seen before. So git makes you feel like
you're always a beginner!

Also, git commands are low-level operations, so they don't map exactly
to things you want to do.

You need multiple commands to execute common actions (like "put my code
on GitHub" and "make my coworker's code available in my editor").

Finally, some of the commands do quite different things depending on
their parameters (e.g., git reset and git checkout), making them
hard to understand.

Git has been trying to create less confusing commands (like splitting
git checkout into git switch and git restore), but this
creates even more commands to learn!

Git tracks 4 versions of files, instead of just "my" version and "the team's" version.

When I'm working on a file, I mostly think about "my" version (what I'm
working on in my editor) and "the team's" version (what the file looks
like on GitHub).

Unfortunately, git has two more versions that I need to keep in mind:
the one in the "index" (or "staging area") and the one in the HEAD
commit in my local repository.

Because of the low-level commands and the 4 different versions, there's
no single git command that tells git to just take a file I saved in my
editor and update GitHub. Instead, I have to do the following:

# disk -> index/staging area
git add README.md
# staging area -> local branch
git commit
# local branch -> remote repository (e.g., GitHub)
git push origin branch

(The first two commands can be reduced to one with git commit -a,
but beware: that will only add changed files and skip any new files you
created while coding.)

Clearly, the 4-version internal git model complicates most common tasks.

Git doesn't let us safely experiment

Most of us learn new tools by experimenting with them, but git is not
set up for experimentation. It lacks "undo", "--dryrun", and safeguards
against you deleting your own code.

Undo would allow you to try some commands and backtrack if they don't lead to the right result.
A dry run parameter would show you a summary of what a command does without making actual changes. If git had that, you could confidently explore commands and preview the effects before applying them.
Finally, a safeguard against deleting code could prompt you with an extra warning before executing commands like git reset –hard or git push –force origin¹. If all commands that might cause you to permanently lose your data had a safeguard, you could experiment more.

Because these three features are missing, you can't casually experiment
with git commands unless you want to risk losing code you spent hours
working on.

In summary,** git forces you to convert commands that make sense to you
into commands that make sense to git, and it punishes you for any
mistake you make**.

The way forward: new tools will improve the git user experience.

Despite the user experience issues, git will probably not be replaced by
a new source control system. Instead, new tools on top of git can make
it easier to use by converting commands that make sense to humans into
commands that make sense to git. They will offer us fewer, more
meaningful commands, automatically manage the 4-version model of git and
make experimentation easy and safe.

Several tools are already out there:

Gitless ²
Sturdy
legit
jj
Sapling: just opensourced yesterday by Meta
HighFlux: our product, currently in beta

We're focused on improving the git user experience. We'd love to hear
your thoughts:

discuss with us on Discord or follow us on Twitter.

Mathijs is one of the co-founders of HighFlux.io

HighFlux is a CLI and GUI that incorporates these ideas and is currently in beta.

Download now

With an additional parameter to skip the safeguard for automated workflows. ↩
We highly recommend reading the research article by the gitless author: "What's wrong with Git? A conceptual design analysis": https://spderosso.github.io/onward13.pdf ↩

Git power tool: patch

Mathijs Vogelzang — Tue, 15 Nov 2022 11:23:10 +0000

Git has many tools that you don't normally encounter in day-to-day use.

One very powerful one I've started using recently is the "patch" flag.

Say you're working on a branch, and you discover you need something you've already implemented on a different branch. Not the whole change, just a tiny bit (in case you want the whole change, git cherry-pick or git merge are more appropriate).

Instead of manual switching and code-copying, you can use git checkout --patch (or git checkout -p for short).

It works like this:
I'm on branch featureA and want to copy things from branch featureB.

I execute:

$ git checkout -p featureB

(If you know which particular file or directory you want to patch, you can also add that as the last argument, like git checkout -p featureB src/my_page.tsx)

I now get walked to all parts of the change (called hunks) and get asked if I want to apply them or not:

Very convenient!

3 things you have to get used to when learning Rust

Mathijs Vogelzang — Thu, 10 Nov 2022 10:18:11 +0000

I've been using Rust for over half a year now. It's an amazing technology. Nevertheless, there are some things that keep tripping me up. The following are the three things that come to mind:

If statements have no parentheses
```
if language=="Rust" {
  println!("Don't use parentheses!");
}
```
As I frequently switch back and forth still with TypeScript and
Kotlin, I keep having to get used to not typing parentheses for the expression of if statements. And then, when I've been doing
Rust long enough, I have to get used to adding them again when
switching back to TS/Kotlin 😫.
async code still needs careful attention
A big benefit of Rust is that it has the speed of non-garbage collected languages like C/C++ but still has the same memory safety as Java/Python/Go and others. Concurrent programming is also safe; the compiler makes it nearly impossible to create a race condition.
If you start writing async code, this safety is also not fully there. We ran into issues where an accidentally long-running task was scheduled like
tokio::spawn(async || sync_function_that_sometimes_runs_long()), and when a couple too many of these tasks got executed, they blocked all tokio functionality from running at all.
The fix is to run these tasks with tokio::spawn_blocking, but you have to think of that yourself; the compiler doesn't check this for you.
Your target/ dir needs to be occasionally cleaned up
Rust fills the target dir with intermediate results, and this directory grows very big quickly. (Multiple GBs for a trivial project, and after more time working on a project, it can easily become 20GB).
My VSCode sometimes stops monitoring files in my workspace because the target dir is so big. (This can be fixed by adding target to the files.watcherExclude setting, see this documentation page for more information).
Even with VSCode ignoring target, it's still a good idea to clean occasionally. Otherwise, you might run out of disk space if you have more than a handful of Rust projects!

What do you think are the biggest gotchas with Rust?

HighFlux Friday

Mathijs Vogelzang — Fri, 04 Nov 2022 14:31:29 +0000

It's Friday.. best time to try out HighFlux, the smart & automated git client!

https://www.highflux.io/

Git has 157 commands

Mathijs Vogelzang — Wed, 02 Nov 2022 22:18:51 +0000

Git has no fewer than 157 built-in commands. No wonder it's considered hard to learn.

I've been using Git for > 10 years and there are total surprises for me here.

Did you know that git instaweb opens a bare-bones repo viewer in your browser?