1. I will give a brief intro to BQN and talk about its pros and cos

2. I will show a few Julia vs BQN code problems side by syde

3. I will argue that there's areas for Julians to draw inspiration from BQN

4. I will give a few resources at the end for you to dive deeper.

As usual, if you want to support my writings and open source work, please consider sponsoring me on GitHub. I'm reaaaaally close to 50 monthly sponsors, and it makes a huuuuge difference in how much time/worries/resources I have for working on stuff like this.

Alright, on with the blogpost.

Why is BQN is cool

1. It has fast multidimensional arrays

2. They love unicode

3. It has a REPL!

4. It's super at code golfing 🏌

5. It's self hosted

6. They use JuliaMono! 💝

7. They're building a JIT!

Name: funny bacon puns. Also "APL" .+ 1 == "BQM", but people noticed too late before the "bacon" puns began. BQN vs APL:

Getting started

• BQN keyoard

• Tutorial

• Note: If you are going to try to use your terminal with the CQBN REPL (the fastest implementation), note that you will want to do rlwrap -r BQN to fire it up.

• The nvim-bqn interface is the best local option I've found.

• Remember to change your terminal font to JuliaMono, otherwiseyour code will be even more unreadable (at first!).

Range:

• 15 reshape range 10 # cycles!

• transpose 3_3

Scripting

online REPL or download BQN repo and open with browser BQN/docs/try.html from their github repo.

Everything in green is a function Everything in yellow is a 1 modifier Everything in purple/pink is a 2 modifier

Defining Hi function

REPL Duel

• Problems: palindromes, count different words, Remove HTML Tags

Tutorial

Julia vs BQN problems:

Here's a few "classic" problems in both Julia and BQN

1. Find the Hamming/edit distance between 2 strings:

julia> dist(s1, s2) = count(((x,y),) -> x != y, zip(s1, s2))
dist (generic function with 1 method)julia> dist("ACCAGGG", "ACTATGG")
2julia> dist(s1, s2) = sum(map(!=, s1, s2)) # kudos to Michael Abbot for the broadcasting tip
dist (generic function with 1 method)julia> dist(s1, s2) = mapreduce(!=, +, s1, s2) # kudos to J. Ling for this one

And in BQN:

s1 ← "XXXXGGG"
s2 ← "ACTAGGG"
Sol ← +´≠
s1 Sol s2 # 4

This is a neat 3 char solution that Asher will no doubt be very proud of.

2. Increasing Array

You should take 3 minutes to go read the problem statement.

I like that after seeing the problem (you should go and click the link), I didn't think about a C++ but a BQN solution. Here's my attempt:

a ← 3‿2‿5‿1‿7
+´a-˜⌈`a
Sol ← {+´𝕩-˜⌈`𝕩}
Sol ← +´∘(⌈`-⊢) # Asher's solution
Sol a

which in Julia I would write like

julia> x = [3 2 5 1 7];
julia> sol(x) = accumulate(max, x) - x |> sum;
julia> sol(x);

Which took be a bit because scanl is called accumulate in Julia. Not too shabby. (Extra kudos if you can get a non-allocating version working)

3. Maximum parenthesis depth

4. Remove HTML Tags

Problem spec:

Given the string "<div>Hello <b>CppNorth!</b></div>", remove the HTML tags (underne

The following snippets are thanks to dzaima on the BQN Discord:

)t:10000000 {𝕩/˜¬(≠`∨⊢)(𝕩='>')∨𝕩='<'} "<div>Hello <b>CppNorth!</b></div>"
179.01ns

On a make o3n-singeli build (built for SIMD speedups):

)t:10000000 ¬∘(≠`∨⊢)∘(=⟜'>'∨=⟜'<')⊸/ "<div>Hello <b>CppNorth!</b></div>"
165.19ns

On a 100x longer input it rips at about 0.24ns/character (without a block):

≠a←∾100⥊<"<div>Hello <b>CppNorth!</b></div>"
3300
   )t:1000000 ¬∘(≠`∨⊢)∘(=⟜'>'∨=⟜'<')⊸/ a
782.1ns

5. "LURD" robot

What Julians can learn from BQN

1. Broadcasting semantics, Each ([¨](https://mlochbaum.github.io/BQN/doc/map.html)), and Taking Arrays Seriously™.

2. Data parallelism techniques.

3. Bit vector optimizations.

4. Flattening data recursive structures for performance.

5. Array-ify all the things.

6. Algorithmic thinking

Notes and words of caution

The syntax and symbols of BQN is a big "love it or hate it" part of the deal. I won't try to convince you to like it, but I have found it much easier to take a silly, mnemonic based approach to what each symbol does: * ≡"abc" will give you the "depth" of something, because it looks like a little ladder that you descend * ⌈ is taking the "highest" value (and is thus the max), ⌊ is taking the "lowest" * +´ will be dragging all the stuff to the right of the tick towards the +, so it's a reduction * +` If you use the tick the other way, you will be dragging the +towards the stuff on the right, so it's a scan, from left to right. These are just the examples that come to mind, but I've found (completely subjectively) for BQN's symbology to be a bit friendlier/more consistent than APL's. Be mindful that the ‿ character to denote lists is not the same as that of arrays. The docs say that newbies usually start out with these for easy manipulation examples and gradually move on to explicit array notation with the fancy brackets:

3 1⊸+⊸× 5
20
    3‿1⊸+⊸× 5
⟨ 40 30 ⟩

As stated in the page, general array notation is a thorny problem in APL, and it took Julia about 10 years to finally nail down the tools and syntax to land it in Base..

• Reading BQN/APL is likely where the learning difficulty curve hits hardest when starting out - this docs page was very useful to grok that ˜ is a 1-modifier (as all symbols that "float higher up") and ∘ (like all symbols with unbroken circles) are 2-modifiers. Concretely, having a context free grammar removes ambiguity

• When I'm struggling to find out how to write my solutions to problems like the Increasing Array, this is my workflow:

  1. Start with thinking "I should propagate the max function" like ⌈`a. I'll press Shift+Enter on the online BQN REPL and build up the solution

  2. "I should now try to subtract it from the original array" and write a-⌈`a

  3. "Ah, right - I need to add a flip thingy" and evaluate a-˜⌈`a

  4. "Sweet, just have to reduce with a sum now" +´a-˜⌈`a

  5. "Ok, to make it tacit I had to use those ⊣ ⊢ thingies." (I go and review the modifiers diagrams docs)

  6. (After much plugging away at the REPL) ... "Dammit, I forgot I can use the Explain button!"

  7. (Fiddle around some more) "OK, I think I got it" and write

Sol ← +´∘(⌈`-⊢)

• The next big step up in BQN skills is identifying function trains, which took me a bit of spelunking about in the manual before finding it. For example, going from the first line to the second in this snippet 👇🏻

"whatsin" {(𝕨∊𝕩)/𝕨} "intersect"
"whatsin" (∊/⊣) "intersect"

proficiently will really up your game in code-golfing powers, should you be interested in that. This APL Wiki page and the Trainspotting links and videos at the end are also useful resources.

Useful idioms

At some point, any seasoned array programmer develops a good collection of known code snippets. Here's a few to save you some headaches:

• Reading lines from a file can be done via:

lines ← •FLines "day01-a-test.txt"
nums ← •BQN¨ lines

The •BQN¨ isn't optimal, but it's good enough to get going with AdventOfCode problems.

• Benchmarking! (I am a Julia REPL stan after all.) If you're in the REPL, you can use )t:X

)t:1000 3+3
14.666 ns

This will run your code X times and tell you how long it took on average. Elsewhere, •_timed can be bound to the left argument How does one get a finer performance report though? Dzaima kindly posted:

perf report of that, with some comments - most of the time is in replicate (which is implemented with pdep & pext, i.e. SWAR; 8 bytes per iteration), followed by the ≠-scan, which is more SWAR, but it processes 64 items per iteration so it's fast

To get that, you do

sudo perf record rlwrap ./BQN

type in your script and then

sudo perf report

• TODO Generating random arrays:

If we need to repeat a string 100 times, we can use:

100⥊"<div>Hello <b>CppNorth!</b></div>"

That will give you the above string repeated 100 times.

Interesting resources

For those that truly want to stare into the abyss and have it stare right back at them, there's some ~university level courses that are written in APL/BQN/J.

• Code Report/Connor Hoekstra's Youtube channel - where he goes over some of the history and theory of combinator logic via code examples in Scala, Haskell and APL.

• Here's Kenneth Iverson's Notation and Thinking paper.

• Physics in APL2

• Calculus in J

What's next?

...Well, I think I want to learn a bit from the people that took parallelism and performance seriously in ML aka, "What if Haskell wasn't slow and they wanted to dunk on MATLAB"?

Don't forget...

miguelito:

If you want to see more blogposts, sponsor me on GitHub

and I will be documenting my work with this ongoing blogpost in reverse chronological order.

If you want to see more posts like this, consider chucking a buck or two on my GitHub sponsors, or, you know, hire me as a grad student.

23/02/2024

Only added stubs for where ISD::[US]CMP will go in the LegalizerDAG.cpp. Some code is better than no code!

22/02/2024

Back from exams. I let my mentors know I wouldn't be around for a few and would come back later.

Omg Nori taught me how to use vim marks (even within VSCode). ma will set a mark a and 'a lets you jump back to it. If you set an uppercase one, it's GLOBAL and you can jump between files!

19/02/2024

Got feedback for the proposal. Seems people like not reading ChatGPT scripts, whodathunkit. Aggregated suggestions and sent it off. Should update if I get more updates.

Also, rebased the next step of the PR, which is merging into the SelectionDAG

Alright, pushed some code that probably fails on everything but can't get more brainpower on learning the casting RTTI APIs today.

18/02/2024

IT GOT MERGED!

I wrote up the draft proposal, and sent it for feedback from the mentors.

Tomorrow I'll try to get started on the next steps of the proposal and send a dummy PR to get to the good stuff.

17/02/2024

Actually just rested yesterday. 'Twas good. Today I'll do some light reading.

• isa<>, cast<>, dyn_cast<> templates

  • isa<> returns true/false if it's an instance of the specified class

  • cast<> is a "checked cast"

  • dyn_cast<> usually used in if (auto *AI = dyn_cast<AllocationInst>(Val)) {

• StringRef and Twine - Value class and StringMap must be generic over null chars, can't take a const char*

• Error handling: abort early, use assert(cond && "you done goofed");

enum { Foo, Bar, Baz } X = foo();switch (X) {
  case Foo: /* Handle Foo */; break;
  case Bar: /* Handle Bar */; break;
  default:
    llvm_unreachable("X should be Foo or Bar here");
}

• use LLVM_DEBUG and friends

LLVM_DEBUG(dbgs() << "I am here!\n");

and then

$ opt < a.bc > /dev/null -mypass
<no output>
$ opt < a.bc > /dev/null -mypass -debug
I am here!

• Use the Statistic class!

• stopped at picking the right data structure.

16/02/2024

Start: read LLVM Programmer's Manual, then start with some local changes to the SelectionDAG.

15/02/2024

Derp, I kept getting "undefined intrinsics" errors when running FileCheck like

> ../../../build/bin/opt -S -passes=verify 2>&1 intrinsic-cmp.ll | FileCheck intrinsic-cmp.ll

... because I had to rebuild LLVM and have the new opt pick it up. Once that happened, even the new llvm-lit passed :D

I also had to remove the CHECK-LABEL, still not sure why. Lemme read that for a bit.

Also, I should update mold - it failed with an unknown --long-plt option.

Here's my LLVM build instruction:

> cmake -S . -B build -G Ninja -DLLVM_TARGETS_TO_BUILD=X86 -DBUILD_SHARED_LIBS=ON -DCMAKE_BUILD_TYPE=Debug -DLLVM_OPTIMIZED_TABLEGEN=ON -DLLVM_USE_NEWPM=ON -DLLVM_USE_SPLIT_DWARF=ON -DLLVM_PARALLEL_LINKER_JOBS=10 -DLLVM_PARALLEL_COMPILE_JOBS=10
> mold -run ninja -C .

Windows builders take freakin' forever to run.

• Coding Standards

  • prefer llvm::DenseMap over std::unordered_map and similar. No std IO plz.

  • comments - write what does is trying to do and why, not how

  • spaces not tabs

  • prefer C++ style casts like auto DestVecLen = cast<VectorType>(DestTy)->getElementCount(); for getting the Vector length

  • beware auto copies:

// Typically there's no reason to copy.
for (const auto &Val : Container) observe(Val);
for (auto &Val : Container) Val.change();// Remove the reference if you really want a new copy.
for (auto Val : Container) { Val.change(); saveSomewhere(Val); }// Copy pointers, but make it clear that they're pointers.
for (const auto *Ptr : Container) observe(*Ptr);
for (auto *Ptr : Container) Ptr->change();

* use early returns, specially in loops:

// not this
for (Instruction &I : BB) {
  if (auto *BO = dyn_cast<BinaryOperator>(&I)) {
    Value *LHS = BO->getOperand(0);
    Value *RHS = BO->getOperand(1);
    if (LHS != RHS) {
      ...
    }
  }
}
// prefer this
for (Instruction &I : BB) {
  auto *BO = dyn_cast<BinaryOperator>(&I);
  if (!BO) continue;  Value *LHS = BO->getOperand(0);
  Value *RHS = BO->getOperand(1);
  if (LHS == RHS) continue;  ...
}

* other good tips for no *else* after a *return* * turn predicate loops into functions * assert liberally! you may find other people's bugs! assert(Ty->isPointerType() && "Can't allocate a non-pointer type!"); * consider llvm::unreachable("invalid radix for integer literal") * never using namespace std * don't evaluate end() every time through a loop!

// not this
BasicBlock *BB = ...
for (auto I = BB->begin(); I != BB->end(); ++I)
  ... use I ...// prefer this
BasicBlock *BB = ...
for (auto I = BB->begin(), E = BB->end(); I != E; ++I)
  ... use I ...

* lol #include <iostream> is forbidden, as well as std::endl * prefer preincrement (++x) * anonymous namespaces allow more aggressive optimizations! make them small and only use them for class declarations * omit braces on short if's -_- * read "Effective C++" by Scott Meyers or "Large Scale C++ Software Design" by John Lakos. later.

BIG ALERT! We're passing all tests and Nikita says "LGTM!" Huzzahhh!

I finished reading the Coding Standards and will now read the LLVM Programmer's Manual.

Afternoon: only 1 reviewer missing approval!

14/02/2024

It's close to finishingggggggggg

Nikita mentioned the CodingStandards, I'll give that a read in a bit.

In FileCheck unit tests, it's just 2 spaces, not tabs or 4 spaces.

Dhruv recommends using git clang-format or Format Modified Lines in VSCode.

I only have to make FileCheck pass now and Nikita says it should be good!

13/02/2024

OK, I just saw that both Nikita Popov and Dhruv Chawla are listed as mentors for the project. Should try and reach out before the application period begins.

Nikita commented that there's two good places to look into (which I should do meanwhile):

• The Selection DAG part of the manual

• The good first issues on the github tracker, which probably are good to look into.

Notes on the SelectionDAG

• GlobalISel and SelectionDAG both translated LLVM code to target specific machine instructions.

• In theory Intrinsics.td should handle it all but some parts need custo C++ code.

• SDAGs represent Machine Value Types and DataFlow types. Dataflow types provide ordering.

• Legal vs illegal DAG: only use supported ops on supported types

• SDAG phases: build, optimize, legalizeTypes, optimize, legalize, select instructions, scheduling * common to use -debug-only=isel/-dump and -filter-print-funcs=<function-name>

  • several flags can print SDAG after each pass

• OK, effective sign extension elimination seems to be highly non-trivial optimizations

• Oohhhh TableGen representing stuff as a DAG lets you build the SelectionDAG on top of it!

After a few hours of noodling with PR reviews, it's clear I gotta jump on a next one/help PR review some other people. Maybe it's not great to go full mercenary on every good-first-issue and try and help others along the way.

ParticleSwarmOptimization was kind enough in the LLVM/beginners Discord chat to point out that I should have a full build of LLVM and then run llvm-lit from there on a unit test. Sure enough, that let me do gh pr checkout 84903 and then LIT llvm/test/CodeGen/AArch64/hadd-combine.ll to check that a unit test properly ran. Now I can help verify my own and other people's PRs! yay!

That seems like enough for today, I'll hunt for some good issues tomorrow.

12/02/2024

Did a bunch of very quick fixes and got some neat feedback.

11/02/2024

Ohhhhhh neat! Got some really fast feedback this time around on stray newlines and a couple fixes on the PR. Things are moving faster and faster! I think I'm only missing adding some FileCheck tests for the invariants under the Verifier.cpp stuff that isn't handled by Intrinsics.td but that sounds about it!

FileCheck reading I'll do for a bit.

Note: If you are going to check multiple things in a single file, use a CHECK-LABEL to avoid spurious matches.

Sometimes, a CHECK-NEXT is useful as the last unit test.

Learned the LLVMIR verbose call syntax goes (gotta include types in call site).

That should do it for today, see y'all tomorrow.

10/02/2024

Plan for today: Read the IR Verifier, add code to it if needed, then work on adding to SDAG node.

IR Verifier code: It's under llvm/IR/Verifier.h and llvm/IR/Verifier.cpp.

Ok, read the code for a bit. What I'm interested in in Verifier.cpp is the huge switch statement towards the end of the file where the verification of intrinsics happens.

Oh neat, learned a lot of places that probably need modification via searching case Intrinsic:: in the llvm folder.

Neat! VectorUtils.cpp looks like where we add SIMD :D

There is also a SelectionDAGBuilder.cpp that seems like I should update stuff there.

Ah, seems the SDAG needs the ID node to be added to the ISDOpcodes first, like ISD::SCMP and such.

Intrinsic Function: start with llvm. prefix. Must always be external functions. If any are added, must be documented in LangRef. Have naming convention on type name return.

In TargetLowering.h:

/// This class defines information used to lower LLVM code to legal SelectionDAG
/// operators that the target instruction selector can accept natively.
///
/// This class also defines callbacks that targets must implement to lower
/// target-specific constructs to SelectionDAG operators.
class TargetLowering : public TargetLoweringBase {

Updated the PR to not include a dirty file from the ValueTracking.cpp unit tests.

Sweet, rebased the spaceship-intrinsic branch changes into a new one.

Now I can go for

lib/CodeGen/SelectionDAG/SelectionDAG.cpp:Add code to print the node to getOperationName. If your new node can be
evaluated at compile time when given constant arguments (such as an add of a constant with another constant), find the getNode method that takes the appropriate number of arguments, and add a case for your node to the switch statement that performs constant folding for nodes that take the same number of arguments as your new node.

Which gives on Line 6629 of SelectionDAG.cpp

SDValue SelectionDAG::getNode(unsigned Opcode, const SDLoc &DL, EVT VT,
                              SDValue N1, SDValue N2, const SDNodeFlags Flags) {

where I can add an case ISD::UCMP/case ISD::SCMP.

Oh wow, having VSCode let me just hover over a type and give me info is amazing.

Alright, did some good work today I think.

Got some feedback on typo fixes from other people and some concrete directions from Nikita:

def int_scmp : DefaultAttrsIntrinsic<
    [llvm_anyint_ty], [llvm_anyint_ty, LLVMMatchType<1>],
    [IntrNoMem, IntrSpeculatable, IntrWillReturn]>;

for the Intrinsics.td so that we can have a "result type overload over a fixed type" and then

and then add a check in Verifier.cpp that a) the return type and the first argument type have the same number of elements (if they are vectors) and b) the return scalar type has width at least 2.

So I've pushed a commit already to have the Intrinsics.td that way and I will now add a case to the Verifier.cpp in the void Verifier::visitIntrinsicCall(Intrinsic::ID ID, CallBase &Call) { to add

(Many hours later) Put in a good first effort into the Verifier.cpp cases for Intrinsic::scmp/ucmp. It's probably a bit boneheaded but I've been getting really good and fast feedback on the PRs, so I feel encouraged to keep the hot streak going.

09/02/2024

Lost the renaming battle to standard practices. Can't complain. Updated the PR to reflect that.

Now, reading the DCE pass code.

Ok, Andrzej Warzyński did an incredibly useful tutorial for llvm-tutor.

I'll try writing the Transformation pass, since it's closes to what I need.

Notes: * LLVM_DEBUG is super useful.

#include "llvm/ADT/Statistic.h"
#include "llvm/Support/Debug.h"#define DEBUG_TYPE "mba-add"
STATISIC(SubstCount, "The # of substituted instructions"

and then you can do:

LLVM_DEBUG(dbgs() << *BinOp << " -> " << *NewInst << "\n";
    // or , with Statistic and `-stat` on the `opt` CLI and debug build
    ++SubstCount;

• Analysis inherits from AnalysisInfoMixin

• Very common pattern:

for (auto &Func : M) {
    for (auto &BB : Func) {
        for (auto &Ins : BB) {
            ...

• You call PreservedAnalysis.abandon() when you wanna bail on a logic.

• FileCheck is a pattern matching tool that comes with LLVM. Can check emitted assembly output for test correctness.

• Rely on CMake's find_package and add sanity-checks to your scripts!

• LLDB is your friend

lldb -- $LLVM_DIR/bin/opt -load-pass-plugin lib/libMyPass.so -passes=my-pass -S dummy.ll
(lldb) b MyPass::run
(lldb) r

Finally: started a branch called scmp-and-ucmp and I'll start trying out changes there whilst people make up their minds.

8/02/2024

Jyn strikes again and sometimes you can just do make after cmake because some stuff is optional.

Otherwise, install:

sudo apt install libzstd-dev libcurl4-openssl-dev libedit-dev

to get rolling.

Once you do

# Run the pass
$LLVM_DIR/bin/opt -load-pass-plugin ./libHelloWorld.{so|dylib} -passes=hello-world -disable-output input_for_hello.ll
# Expected output
(llvm-tutor) Hello from: foo
(llvm-tutor)   number of arguments: 1
(llvm-tutor) Hello from: bar
(llvm-tutor)   number of arguments: 2
(llvm-tutor) Hello from: fez
(llvm-tutor)   number of arguments: 3
(llvm-tutor) Hello from: main
(llvm-tutor)   number of arguments: 2

using -disable-output means no bitcode gets produced.

Passes come in 3 flavors, mostly: Analysis, Transformations and CFG manipulations.

Note that clang adds the optnone function attribute if 1) no opt level is specified or -O0 is specified.

Ah, forgot to run the cmake .. -> mold -run make -j and had some passes missing. Derp.

Minutes lost to cmake bullshit: 60.

Oh sweet! I just learned that I can write an injection pass that will give me a new binary and it will print out cool analysis info.

Also, if I get an instrumented binary I can just use lli to interpret the .ll file directly.

You can also build a static binary that will run that analysis for you!

Ran a bunch of passes with opt and friends. Transformation passes will normally inherit from PassInfoMixin.

Analysis Passes will inherit from AnalysisInfoMixin.

Ok, cool I an outdated example in llvm-tutor in the examples and sent a PR for it.

Tomorrow I shall dive into those optimization passes at the end and hopefully run some good lit tests.

7/02/2024

Alright, did some good catchup on the semester and pushed the PR forward a bit.

I also had an awesome "uniwtting tourist" genius moment by pointing out the return type could be different than what Nikita had thought of.

Today I setup my environment with

wget -O - https://apt.llvm.org/llvm-snapshot.gpg.key | sudo apt-key add -
sudo apt-add-repository "deb http://apt.llvm.org/jammy/ llvm-toolchain-jammy-17 main"
sudo apt-get update
sudo apt-get install -y llvm-17 llvm-17-dev llvm-17-tools clang-17

so now I can run opt shenanigans without awkward path invocations.

2/02/2024

I'm waiting for others to chime in on my latest fix so I will be reading on how to add unit tests.

Cool, that took like 25 minutes and I pushed a commit into the unit test generation framework.

Took me a bit but tried adding using llvm-lit and couldn't get the Examples folder to run, so I posted a question in the #beginners channel about it.

1/02/2024

Sweet! I was able to address Nikita's refactoring comments without too much hassle.

I guess the next task is to add it to the Verifier.

-> I read the llvm/lib/IR/Verifier.cpp header and grep'd for smin. Seems I can add a

Intrinsics::vector_reduce_sthreecmp:
Intrinsics::vector_reduce_uthreecmp:

on line 5378 and get away with this. I don't see other places where it's defined.

I think I've hit my potential here. I will go do some tutorials.

29/02/2024

"hazlo cobarde"

Add the 3 way comparison instruction <=> to LLVM.

I like this GSoC in particular because

• I will learn a wide swath of LLVM

• I'll be working with a lot of optimization passes

• I'll get to bring cool perf to C++/Rust and Julia

• I was dared by the other, more talented Miguel to actually help improve LLVM

Task 1: Add to LangRef

Add a new intrinsic - Langref, then Intrinsics.td, then maybe the pass verifier.

I've already put up a sample PR and got redirected on what looks like the proper working path for this endeavour.

Oh neat, I've finished. Only took about 1 hour with careful copy pasting. I'm probably blundering the return type being iM bits, but someone will correct me.

Now, I need to add an entry of the intrinsic into TableGen.

Task 2: Add to Intrinsics.td

Whelp, I guess I gotta learn tablegen and then this Intrinsics.td file.

Ok, I found a non-intimidating TableGen overview.

Gotta find the optimization wizardry in there after reading for a few minutes.

Alright, took more than a bit of an hour but I got pushed something for this task.

Pinged Nikita to get some adults to look at my horrible TableGen incantation.

See ya tomorrow.

Saludos 👋

Hola! Me llamo Raz y este es mi granito de arena para quienes quieren empezar con el software libre (o encontrar fuentes de ingreso en este mundo). Puedes ser mi sponsor en GitHub para que escriba más cosas como esta y contribuya al software libre de Julia/Rust y sus traducciones en español.

GitHub Sponsors

with apologies to Holge and Randy and David and Logan and Hector and...

Summary:

You can get money via donations and your GitHub profile. This can take a few hours to setup and be a good side revenue, or an emergency lifeboat. Depending on where you live, your marketing skills, larger community environment and a slew of other factors, this may or may not work for you. This post is an exercise in Your Mileage May Vary from someone who spawned the game of life in Easy Mode (white cis english speaking STEM focused able male), so take what you can and dismiss what doesn't apply.

Make no mistake: living from GitHub sponsorship means charity with extra steps, and with a multinational corporation (ultimately, Microsoft, Github's owner) as your uncaring and all powerful boss. Assume they will use power to control your "wage" to align with their interests and diversify your risks accordingly.

If you live in the Global South and this program can apply for you, please consider getting started NOW. If you live in the Global North, consider sponsoring devs in the Global South with monthly payments - foreign exchange rate makes them life changing. If you are giddy for how to get started, my recommendations for a setup are farther down in this post.

Who what when where why

GitHub sponsors is a program you can sign up for (free) on github.com and receive donations from other people for (mostly) working on open source stuff. If you were already doing open source stuff, you can setup a profile and people can choose to give you one-time or monthly donations (more on that later) at tiers you are free to specify - from 1USD a month to full 666USD Bezos level patronage.

Github sponsors is attractive in comparison to other platforms because, at time of writing, they do not charge a percentage on your sponsorships.

Patreon charges (at time of writing), 5%+, and other (main stream) platforms are not far off.

This is an attractive proposition, but you should investigate before you launch yourself into the "content creator" lifestyle.

1. GitHub has yet, to my knowledge, bound itself legally into always respecting this financial agreement. It could start changing it's terms tomorrow, lest you obey some orders from corporate, as was the case recently with Twitch streamer's revenue sharing overnight change with ...Amazon. That news was the most recent one off the top of my head, but every subscription/donation based platform can, has, and will unilaterally change your ~~wage split~~donations how they see fit.

2. This doesn't apply to every country. At time of writing, 68 regions can qualify for sponsorships of which, sadly, I only count 4 African countries, for a "global" program that has been running for almost 3 years now. Mexico initially wasn't on the beta list (for which there was promo where GitHub would match donations, to my chagrin), but I joined the waitlist and received my email after a while. Note that Iran, Venezuela, Russia and CubaN

• who i am

  • how i got started, my presence

  • marketing

• who i am not

  • orgs, umbrella, collectives

So. I think I've had what I would call a "moderately" successful run with my GitHub sponsors. A lot of people have asked me about tips and tricks, and I'm not the one for

• what sponsors is

how it works

• how to setup your profile

• countries, bans, availability

• taxes

• Dos

• public presence: famous code, repos, books, talks, online presence (pandemic podcasts, community building)*

• big disclaimers, aka the don'ts:

• don't assume you won't pay taxes.

• uni might clash - grad students/scholarships may not work. dont knmow if amazon wish lists or payments in kind can be setup

• make this yourplan A, at least forever.

When I tell people I study physics, more frequently than not I've had to help avoid a panic attack or two. There's always that 2nd grade teacher, the trauma, the gnashing of teeth; I don't really fault people for having gone through the pedagogic wringer and suffered the tyranny of schooling. This is the story I tell math-phobic to let them know I think they're right.

As usual, by sponsoring me on GitHub, I can continue my open source campaign. Plus, you get a monthly summary of all my writing shenanigans at the end of the month.

Art class

Let's imagine an you are in an ideal art classroom for beginners in secondary school. The recess bell rings and the kids are streaming in to their seats. In front of every kid there's a full decked-out art kit: brushes, paints, canvas and the works. Being their first art assignment, the kids will fill out one of those paint-by-number Monalisa's – there's chunks of the painting numbered 1 and they should all be green, all the 2 sections should be red, and so forth.

The brushes begun to dip, swirl, then dance across the canvases and the kids are jubilant. You've been completing the green->1 chunks when a hand strikes your fingers holding the brush.

Sorry kid we're in art class, and, in here, when you paint green stuff, you must do it always by holding the brush with these two fingers at a time, and you must stroke from left to right

Apoplectic, you ask "Why?"

Because I said so, and these are the rules for art.

...

You muster what courage you can and soldier on with the greens. Remember your parents' edict: failing this art class will mean detention, do overs during summer break, getting grounded - not a fun way to spend vacations. The teacher isn't too worried about explaining why these rules of art must be so, but questioning aesthetics isn't really proactive in the present situation.

Halfway through the reds, a swift hand strikes down your brush again:

In art class, when you paint the reds, you must use these other two fingers, and always stroke from the top to the bottom.

"How was I supposed to know that?"

Doesn't matter. Shape up or you'll fail this quiz.

...and you figure this will continue for each other color. The lesson is clear - disobey and be punished for failing these rules obtained from god-knows-where, so it's best to try and suss them out piecemeal from the teacher and avoid their wrath.

But every torment must end, and though there's been wailing and gnashing of teeth, your Mona Lisa is finished.

The teacher comes by, pops up your piece into the sunlight and delivers the coup de grace:

Ah! Look at this beauty - isn't art just beautiful?

My claim is twofold: any child that walks out of such an "art" class saying they like art is in need of a dire intervention and/or therapy, and that (modulo metaphoric license), that is basically how we teach "math" in most schooling systems I know (or rather arithmetic).

We show little empathy with kids about why they're learning a particular system, punish them based on our predetermined system of axioms without explaining why we chose such a system over many others, and people just learn to game the system enough to evade punishment (we're only talking about harsh impacts to your future economic prospects here!).

Why are we learning about these numbers and not others?

Because they build up to calculus and we've "decided" as a society that that goal is what will make you most productive.

How do we know these are the only kinds of numbers that have these rules?

There might be many! But you better learn these or else!

Why not choose different rules for our numbers? Why not have different axioms for our geometry?

We'll have none of that nonsense here you lil' insubordinate rascal...

Do we really need to optimize those missile trajectories?

Alright, that's enough thinking about where the tools we teach end up being applied.

...and so on.

Yes: some form of rote practice is needed to gain basic mathematical acumen - but nowhere near the level of attention that it deserves. Spelling drills are necessary to manipulate language, yet spelling bee championships do not poets make; neither should we conflate arithmetic worksheets and piles of homework with exercises in mathematical thinking.

Worst of all, I think is that people don't even have the vocabulary to know the worlds they aren't seeing. This is in contrast to musical experience - even if you never hit a solid note on your recorder, you can still appreciate songs and dance beyond your classroom disappointment. But how would you explain to someone that Daft Punk, Dolly Parton and Beethoven can coexist in the same universe of musical enjoyment if their (let's imagine for sake of argument) only musical exposure in life were the beeping of an alarm clock?

You'd get a lot more people traumatized about art and music class, and if I was a musician in that world, I'd also field a lot of people dumping their childhood traumas on me because I was "into music".

A rainy setup

You are running a science experiment where you must measure the amount of rainwater that falls in a given day. The scientific-est thing your advisor has recommend is to setup a RainWater-O-Tron 9000 that collects data every day on how much water fell into a tube that sticks on top of it and reports it back the total at the end of the day. Once the thing is plugged, your machine graciously spits into your data pipeline tool a table that looks something like this:

So far, nothing out of the ordinary. Another humble data gathering expedition to appease the fickle gods of science and grants. The machine kindly records the centimeters of rain collected and its operating status - seems sensible.

You reset the machine and leave for Easter break and leave the robot running for a week, ready to come back and do some proper Science TM once you get the data back.

Ominously, you find the report to say this:

Clearly something has gone wrong, on days 4-6, but if you think about it carefully for a second, the Status of each data point gives you some insight into where your data collection could have gone wrong.

• Days 1-3 went (likely) as expected

• Day 4 the RainWater-O-Tron recorded it was functional, but you didn't receive the data. You thus know the data for Day 4 is missing.

• Day 5 the machine wasn't even functional, and thus no data was collected, which means you have nothing as a data entry.

• Day 6 the machine did record data, but it got garbled somehow, and the result you got is Not a Number/NaN.

• Day 7 it seems the machine resumed normal operations.

This is the big distinction in how much you know about your data, and the "failure modes" of how it was mis/collected: you get an idea for how to approach its shortcomings based on what you recorded.

• for the missing data, perhaps the machine ran out of memory from the moment it made the water measurement accurately, but didn't transmit it, or the cable got bitten by some rats and thus you couldn't receive it

• the nothing data means that perhaps there was a power outage, and your entire apparatus was offline

• NaN means the internal functioning of the machine got compromised, or something in your calculations is wildly wrong

Of course, these are just narratives for illustrative purposes, but hopefully it can help solidify the distinctions and how these can help you think to solve your problem. Does that mean you must always use these sentinel values in your code or data collection? Not necessarily, but that's for you to decide if these are the right tools.

'Til next time.

Órdenes de magnitud

Cuando uno quiere saber cuánto pesa una elefante, no te preocupas (mucho) por cuánto pesan las moscas que se le paran en la cabeza. Por supuesto que su peso no es 0, pero no contribuyen tanto como para preocuparse. Esta intuición cotidiana se puede formalizar si uno estudia matemáticas, y se les llama "términos de menor órden", y en algún momento del despeje algebraico uno se toma la licencia de tacharlos y seguir campante con el análisis del fenómeno de interés.

En este sentido, es muy útil el poder tener una intuición de los órdenes de magnitud en una cierta discusión antes de aventarse por la borda en favor o en contra de alguna causa. En México, por ejemplo, si alguien quiere tener una discusión seria sobre el ambientalismo, es útil tener en mente los números que más importan (el peso del elefante pues), como el hecho que 100 compañías son responsables del 71% de todos los gases invernadero.

Teniendo en mente ese elefante, no es que uno no debería evitar el consumo de plásticos deshechables gratuitamente, pero hay que darse cuenta que uno está evitando la discusión principal de cómo lidiar con los términos de mayor orden. En el peor de los casos, sobra la santurronería y se desgarran las vestiduras los políticos para castigar a la gente por seguir usando popotes.

A éste fenómeno donde el problema estructural se trata de resolver con recursos de responsabilidad individual le llamo popotismo, en honor a la campaña masiva que se dió súbitamente en México para prohibir el uso de popotes de plástico a nivel individual, y creo que no vale la pena seguir esa línea de argumentación.

Sí, recicla, disminuye tu consumo, eso es bueno y vale la pena, etc; pero a veces la solución es cambiar el sistema y no encontentarse que uno pone un granito de arena en donde ya extrajeron la playa.

El juego es otro.

I've been more serious about learning Rust recently, after dragging on with passive learning for a while. My first real programming language was Julia, and I know other Julians interested in Rust. I've written this article for those people in mind, because Rust and Julia are good performance sparring partners, but Rust has a different mindset and tradeoffs that are worth considering.

I hope you enjoy it.

TLDR:

"It is important to draw wisdom from many different places. If you take it from only one place, it becomes rigid and stale."

–Uncle Iroh

Why Rust? 🤷

There are 3 talks that sold me on Rust being worth learning, the first is by Carol Nichols and the second is a lecture by Ryan Eberhardt and Armin Nanavari. The first talks about how about ~70% of all bugs from the big tech corporations are from memory safety and that trains used to not have emergency brakes. The second explains how systems programming codebases already impose the invariants of resource ownership on the coders - but that reasoning can be horribly error prone, tedious, and automated.

That's the point of technology! To not have to worry about the previous generations problems because we figured out a way to offload that thinking to a machine.

The third talk that really sold me on Rust was Alex Gaynor's. It's bad enough that a bank or a school web site could crash because of memory bugs, but once you take into account the fact that not even the best programmers in the world (sorted by salaries, roughly) can ship safe code, you start to despair a little. Then you hear about the incredibly battle-tested libraries like sudo and, as the moral argument goes, you are likely going to put vulnerable people in harm's way if you keep shipping a broken tool. I buy the urgency of that argument more and more when journalists or human rights advocates get targeted by state actors due to a trivial (but buried) C mistake.

So that's the spiel for jumping on the Rust train when I argue with myself in the shower. What's the Rust's philosophy?

Informal introductions - tales of two languages 📚

I will now give 2 hand-wavy historical rehashings of the origins of both languages.

You might know Julia's origin story - there were a gajillion DSLs for scientific computing, BLAS is a mess but implements polymorphism through namespacing for performance needs, and other libraries re-implemented a poor man's version of multiple dispatch because of the performance constraints. If you add a clever JIT to multiple dispatch capabilities, you can get ~C performance with ease if types can be inferred, and fortunately you can build a general programming language around that paradigm and those trade offs. Eventually, they baptized the language to honor the one true queen of algorithms.

Rust comes from a different place: Some years ago in Mozilla, Graydon Hoare and the team got fed up with systems programming and the C/C++ tool chain. They were working on a language that allowed for programmers to be productive in low-level systems, harness concurrency performance without the foot-bazookas, and avoid errors during run time. At first they had different systems for handling the previous problems, until the team pieced together that an ownership system, with a borrow checker at compile time, could kill 2 birds with one stone. Eventually, they named the language after the fungus.

Recap: Julians were sick of unreusable code, niche DSLs and hacky polymorphism. With multiple dispatch as the central design feature they solved those problems. Rustaceans were sick of the C/C++ minefields and trying to keep all the invariants of large, error-prone codebases in their head. The idea of ownership and a borrow checker to know those errors at compile time and be data-race free is what's got them to where they are now.

There's obviously important details missing on both stories - you can get it from proper historians if you like, this is a brief and informal introduction. I will however, mention the other big Rustian idea of affine types when I talk about how they get a version of generic code we've come to know and love in Julia land. Spoiler alert: you can get generic code if you pay the price of a Julia runtime, and that's not something Rustaceans want. If you want generics at compile time, you have to "prove" to the compiler that your types are constrained to some extent, and you relay that information by tacking on affine types to your code.

That's enough of an intro, here's the table of contents.

Handy learning materials 🍎🐛

If for some reason you've already decided that learning Rust is a worthy endeavour, here's my list of resources to learn. I think they are a good resource to follow in approximate order, but use whatever works, and if it doesn't, skip it.

• The Rust book: Click the link to get started with installation and IDE setup. It pays to read it at least once cover to cover and not fret about coming back to the thorny bits.

• VSCode Error Lens and Rustanalyzer: The quicker the feedback loop you get from the compiler, the sooner you can spot mistakes and keep going. These aren't mandatory but it's the easiest way to make the feedback loop faster.

• Tour of Rust: Also has good examples.

• cheat.rs: A cheat sheet for all the new syntax, priceless.

• Rust by example: Always good for a quick MWE.

• Rust docs: Their version of the Julia manual. Make sure to click the [+] to see how the code drops down. I still spend time looking at the iterators page.

• Courses and exercises:

  • Exercism: If you want to get into some guided learning, Exercisms is great, but focuses too much on strings at the beginning for my liking. Make sure to look at the community solutions when you're done.

  • Advent of Code 2020 by Amos: This was my first "get your hands dirty" with Rust experience. Other articles by Amos are great and friendly too, but this series was useful for figuring out a Rustian workflow and design thinking.

  • Ryan Eberhardt Stanford course: University course that gets you up and running with systems programming constraints and problem solving. I'm not its target audience but it was great for understanding Rust's domain.

  • Jeff Zarnett programming for performance course repo, with a full youtube playlist: Another good course for stepping in directly into high performance computing - not done with it yet, but the professor is friendly and enthusiastic.

  • Rustlings: I found some exercises too hard the first time I picked up the Rust book. Your Mileage May Vary but I did them solo and suffered. I would recommend pairing up with a buddy before attempting all of it.

• Too many linked lists: Another great walkthrough once you feel more comfortable reading and writing Rust.

• Jon Gjengset's streams: Jon Gjengset is a well-known Rust community member and has amazing quality streams - if you want to see a proficient Rustacean code, this is a good place to start.

  • sorting algos stream: More friendly to beginners if you know your sorts.

  • multicore and atomics: Gets into the weeds about all the pain that Rust can save you when you're implementing low-level tricky concurrency.

Alright, so you're set up to go on a learning journey. What's Rust look like anyway when compared to Julia?

What does generic Rustian code look like? 🔍

We love composability and multiple dispatch, so let's look at a short example of how to get the good ol' Julia bang-for-buck, with a 1D point:

import Base: +
struct Point{T<:Real}
    val::T
end+(x::Point{T}, y::Point{T}) where T<:Real = Point{T}(x.val + y.val)
a = Point{Int32}(1)
b = Point{Int32}(2)
a + b # works
c = Point{Float32}(1.0)
d = Point{Float32}(2.0)
c + d # Also works!

So, in Julia land, how do I get generic code?

I make sure to not use any explicit types and let the dispatch system do the rest. You use functions like zero(...), eltype(...). With the dispatches, I add them to the appropriate subtype with where T<:Foo. If I define the appropriate methods, the others get composed atop of them , so I don't need to define += once I've defined +. Duck type all the way - when something errors at runtime because I forgot a case (like the fact there's no type promotion rules above) I just write a function per call I missed and keep hacking on.

Setup a simple type hierarchy, define some functions on your types without using them explicitly, profit from not rewriting all the code, plug and chug as you run into errors or perf hits, look at docstrings in the REPL to help you out. Happy life.

Let's look at the rust example:

use std::ops::Add;#[derive(Clone, Copy, Debug, PartialEq)]
struct Point<T> {
    val: T
}impl<T: Add<Output = T>> Add for Point<T> {
    type Output = Self;    fn add(self, b: Self) -> Self::Output {
        Self { val: self.val + b.val }
    }
}fn main() {
    let a = Point::<i32>{val: 1};
    let b = Point::<i32>{val: 2};    let c = Point::<f32>{val: 1.0};    println!("{:?}", a + b);
    println!("{:?}", c == c);
}

In Rust Land, how do I get a similar generic code?

I worked on like half of this code and then had to look it up. You can run it in the Rust Playground here. Avid readers will notice the following:

1. Damn, that's a lot of boilerplate. 😣

2. To get generics, you need a struct for your type, an impl<T> $TRAIT for Point<T> block where the add function is defined, and type annotations like Self::Output, Add<Output = T>.

3. There's a sort of "name spacing" with the turbo fish operator: ::<this one!>. We don't get functions that can share names but differ in behaviour. Bummer. (We get this in Julia with some nicer outer constructors, but I think it takes from the thrust of the argument.)

4. The println! function is different - it's a macro, and it runs at parse time, also like Julia's macros. The chars inside the {:?} signal that we want debug printing, that we got above with the #[derive(Debug)]. Rust doesn't know how to print new structs if you don't define it, which, as Framespoints out, is one of the problems solved by multiple dispatch .

5. Oh, those #[things(above_the_struct)] are also macros. I still don't know how they're different, but they seem to affect how the compiler interacts with the crate too. Since some traits (like the ones for copying or printing) are so boilerplate heavy and predictable, you can get some behaviour for "free" if you add the right #[derive(...)] stuff in the declaration. That's how the c == c works actually, it's due to the PartialEq.

The main workflow feels like this:

Slap a <T> in front of your struct and the fields you want it to be generic over. Look up the functions needed for each trait in the documentation. Setup a brief test case. Doesn't compile? See what rustc says and try and tack it on some traits; maybe you missed an affine type with impl<T: Foo> or the Self::Output - the compiler guides you through patching up your code. If you're asking for some generic behaviour, the compiler will complain and you'll have to add another trait implementation so that it is damn sure you're allowed to continue.

I also chose a particularly easy example: there's no associated data (like a string) in my Point<T>, so I don't need to prove to the compiler that my data doesn't outlive its uses - those are lifetimes, and they can get hairy, fast, but you'll run into them eventually. I also don't know how easily you could handle multiple generic types and the compile time penalties associated with them.

There's more syntax up front compared to Julia, and not just because we're writing library code here. Pythonistas can pick up Julia within a few hours and be productive. Rust has a lot more surface area to cover in learning the language: references, traits, impls, enums, lifetimes, pattern matching with match, macros, cargo flags for configuration, ownership and borrowing, Send and Sync...

Whodathunkit, Garbage Collectors let you worry about other things for a small runtime price. They might not be right for every use case but they're a solid investment.

Rustian projects of interest 🥇

There's a steep wall to climb when starting out with Rust - however, they've nailed the user experience for learning tough stuff. I think it was Esteban Kuber who said something along the lines of "We weren't missing a sufficiently smart compiler, but a more empathetic one".

Alright, so what's the view from the top look like? Like Julia, Rust is an incumbent in a crowded space, so how has it punched above it's weight against the established candidates?

Here's a list of all the projects that I've found particularly of note to Julians.

• rayon is the original reason I got interested in Rust. Check their hello world - the promise is that if you are using iterators, you can swap (mostly) iter() for par_iter() and at compile time you can know if your code will run in parallel. That's just about the friendliest user interface to parallelism besides Threads.@threads, and with some additional guarantees - a small update loop is easy to keep the invariants in your head, but it really pays when the Rust compiler catches a concurrency bug that spanned multiple files, modules and data structures. Cool tech note: Rayon uses the same idea for work stealing thread scheduler that Julia's parallel task run time system uses (inspired by Cilk, get it? 'Cuz Rayon is a fake silk? Ha...).

• tokio deserves a mention as well for its capabilities for asynchronous programming, but I am not familiar enough with it to comment on it. Rust people get excited about it though!

NB: It is non-trivial to compose rayon and tokio codes.

• egg and related projects like herbie: A wicked fast egraph matching engine - a great competitor and inspiration for the Symbolics.jl ecosystem.

• MMtk and GCs: Garbage Collectors are a family of algorithms that share behaviour, and different strategies can be built atop of tweakable parameters. The promise for building a configurable, performant and battle-tested back-end for Garbage Collectors is alive with this project by Steve Blackburn and gang. If you haven't heard of Immix or Floorplan, enjoy the rabbithole. If you're new to GCs, this is a good starting point for seasoned Julians.

• Rust CLI: Rust people feel comfortable working in the terminal, and they've taken that user experience Very Seriously and have a top notch performance and user experience for their command line CLIs. Here's a few of my favorites - you only need to cargo install foo and they should be properly installed on your system.

  • rg: SIMDified grep replacement tool (for some use cases). Includes colors!

  • bat: cat clone with tons more built-in syntax highlighting.

  • dust: visualize disk space used by folders.

  • typeracer: fun typing game.

  • taskwarrior-tui: Todo tracker.

  • zoxide: directory autojumper. I don't really do cd ../.. climbing around anymore I just do z foo a couple of times and that usually guesses right.

  • zellij: Terminal multiplexer with friendly UX. Young and promising.

• coz: Invaluable tool for causal profiling. Emery Berger's presentation alone is worth knowing about this project. I reeeeeally want to nerdsnipe someone to port this to Julia.

• sled's approach to benchmarking and databases is top-notch. Also worthy of note is the same author's rio crate, which is a Rust interface for the io_uring linux kernel module, which can significantly speed up asynchronous programming. There's some WIP PRs for landing this for libuv, Julia's thread runtime backend, and that effort is close to wrapping up.

• Scientific Computing in Rust: A must to dive straight into linear algebra.

• Taking ML to production with Rust: A sister article to the one above.

• Rust FFT: They beat FFTW in some cases with this one, so it seems worthwhile to take a look 👀 .

• Green function evaluation kernels: Newer package, but I'd like to see how special functions pan out in Rust land.

• Polars: A highly tuned dataframes implementation for some use cases. They've topped the charts in some of the H20ai benchmarks, so they've definitely got technical chops. (They beat DataFrames.jl because of a sparsification trick which is a bit non-trivial to implement, but there's not necessarily an impediment to matching their speed.)

• Loom: a model checker for atomic primitives, sister project to tokio. I think Julia is a more natural fit for this approach given the ease of operator overloading and it will be great to try something similar once Jameson's atomics PR lands.

• Stateright: distributed systems model checker with a graphic user interface.

• Creusot: Add some macros to your Rust code, and have it formally verified by Why3.

• proptest: Configure strategies for exploring type instantiations to fuzz your tests, shrink the cases, and automatically track regressions. Impressive stuff!

• Gleam and Lumen: Gleam is a Rust backend for an Erlang based language and Lumen is a Rewritten-in-Rust implementation of the ErlangVM, BEAM. Erlang is a concurrency monster, and their actor based model is scalable as hell for certain workloads. I'm glad to see Julia start to step into that domain with Actors.jl. This seems to be the right way to abstract for fault tolerance workloads.

There's oodles more. Check out crates.io or lib.rs if you want to explore more (this is their community based JuliaHub equivalent).

I'll make a special note of evcxr, a Rust REPL. For now, I don't think it's profitable to use Rust with a REPL-like workflow. I'm too used to that in Julia, and that works well there, but I think there's a risk of digging yourself into a "Everything must be a REPL" mentality and cutting yourself off from learning opportunities. In Rust land, I don't mind doing as the Rustaceans do and learning to do things around a command line, navigating compiler errors and configuring flags and features for certain behaviours or deployment options. Since that's the package that I wanted to learn when I bought into Rust, I don't mind adapting into that mindset. I still wish them all the best and hope they can make the best possible Rust REPL - I'd love to be wrong on this down the road.

Optimization walkthroughs 🏃

If you want to dive deep into nitty gritty performance fundamentals, these are the best guides I found for explaining the tradeoffs, gotchas, mental model, and engineering for those tasty, tasty flops.

1. COST paper: Maybe doesn't fit here but this is one of my favorite papers and everyone should read it.

2. Comparing parallel Rust and C++

3. Cheap tricks

4. The Rust performance Book

5. How to write Fast Rust code

6. Fastware Workshope

Papercuts and sharp edges ✂

So Rust is "worth learning", but these are roadblocks that I faced and would warn others about to save them some grief.

• You can learn another hobby waiting for Rust projects to compile. The price for compile-time guarantees/being the designated driver in the codebase is offloading more work to the compiler. They're working on leveraging concurrency for speeding up the pipeline, and it's gotten better. Let's just say they also suffer from TTFP 😉 .

• Learn to run your code with cargo run --release and other tricks. This is the equivalent to running your Julia code with globals (or -O0 flags), and it's an easy gotcha. This will not change in Rust.

• Rust people keep saying they have no Garbage Collector, *when they have a Region Based Garbage Collector**. It's all fun and games until they have to implement those linked lists...

(NB: After posting in HackerNews, Steve Klabnik has pointed out that the term region based is technical jargon in Programming Language Theory Literature as seen in section 2 of this paper on Cyclone's memory model.) (NB2: kibwen on HN pointed out that the term garbage collection implies dynamic memory management, whereas Rust's ownership system allows for lifetimes to be determined statically. In that sense, I'm wrong except for when users opt-in to using Rcs and the like. Glad to be corrected!)

• Don't add crates manually! Install cargo-add, use it to manage crate dependencies. That and some other tricks are great from doing the AdventOfCode2020 from the article above.

• For numerics, install ndarray and num_traits. Linear Algebra and numerics where not a primary focus of Rust when starting out as they where with Julia.

• Benchmarking with @btime is painless, criterion is your best Rustian bet.

• Setup your rust-analyzer and error lens plugins on VSCode or IDE asap, you'll thank me later. Rust-land expects you to be in constant dialogue with the compiler, and making that iteration cycle as ergonomic as possible will yield dividends in the long run. What we don't get from accessing help docs in the REPL, Rust people keep a terminal tab handy where they run cargo watch -c and get continuous feedback from the compiler.

• You CAN'T index into a String in Rust with ints! Instead use slices like &str[1..] == str[2:end] or iterators like str.chars(), if I may riff on Rust and Julia syntax in the equality just there.

• Reading from stdin is a pain as a newcomer. I wanted to try out some competitive coding exercises and reading from stdin was waaaay too rough for me at first. Eventually I cobbled this template up link here so that you don't struggle if you want to try a couple of CodeForces problems.

• Not having a generic rand is just painful. So painful. This is my easiest workaround so far for generating a vector of n random entries:

let n = 100;
use rand::distributions::Standard;
use rand::prelude::*;
thread_rng().sample_iter(&Standard).take(n).collect()

(Oh, and rand isn't part of the stdlib so that's another papercut).

• There is no @code_native and friends in Rust - your best bet is to use the Rust Playground and click on the ... to have it emit the total assembly. This only works for the top 100 most popular crates though. You can cargo run --release -- --emit=llvm-ir/asm and then fish the results out of target/, but that's unwieldy - why does no one have a CLI for this yet?

NB: u/Schnatsel has kindly pointed me towards cargo-asm. The interface is not as nice as @code_XXX, but I think I'm satisfied with this. Thanks a ton!

• Another multiple dispatch gripe: having to implement Display traits for new structs feels like pulling teeth, and this initial type signature seems inscrutable as a beginner:

use std::fmt;struct Point {
    x: i32,
    y: i32,
}impl fmt::Display for Point {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        write!(f, "({}, {})", self.x, self.y)
    }
}

• Rust does NOT look like math and that hurts my little physicist heart. Look at this story of a hydrodynamics simulator code vs anything in the DiffEq verse that is user facing or from ApproxFun.jl, or Turing.jl, or ... anything else. Even the linear algebra from ndarray is painful to understand unless you are comfortable in Rust, and all the i as usize conversions are a huge eye sore.

• Many of your functions will be faster if you annotate them with #[inline].

Things I wish I'd known earlier 👓

These could have helped me settle down into a more productive workflow sooner. Get a buddy that knows Rust to see you code to figure most of these out.

1. If you can, avoid the examples with Strings and &str. Yes, they're a great motivation for systems people for all the gnarly use-after free and double-free and memory-leak examples - stick with numerical algorithms first, to get the gist of ownership, try and do some exercisms with iterators and Strings will be much easier to get after that. I don't think it's worth worrying about at first unless your target is systems.

2. The preferred way of "whipping up an example in the REPL"/getting a MWE is to cargo new foo, mucking about and then cargo run --release or using the Rust Playground.

3. If you're using an expansive test suite, cargo test --test-threads 8 and cargo test --quiet are helpful flags.

4. For loops are not idiomatic in Rust - writing Fortran-ey code instead of iterators will lead to pain and slower loops. Spending time reading the examples in the iterator docs and the community solutions in the exercisms will help a lot.

5. Just clone everything when you are starting out to get around most borrow checker shenanigans - worry about allocations later, Rust is usually fast enough.

6. In the following function, the types of v and w are a slice of Int32s, which are different from Vec<32>. Read the Scientific Computing link above to see a nice table of the differences. An array like [f32; 4] includes the size as part of the type, a slice like [f32] does not. Diving into linear algebra means being familiar with many to_array(), to_slice(), from_array(), and from_slice() cases.

fn dot(v: &[i32], w: &[i32]) -> i32 {...}

6. Including docs and tests in the same file as your implementation is idiomatic - even the IDEs support clicking on the #[test] line and having that run. Julia has a nice workflow for test driven development out-of-the-box - Rust gives you some of those guarantees by... conversing with the compiler.

7. Rust has something similar to the concept of type piracy: they're called the orphan rules, as explained by this Michael Gattozzi post:

Recently at work I managed to hit the Orphan Rules implementing some things for an internal crate. Orphan Rules you say? These are ancient rules passed down from the before times (pre 1.0) that have to do with trait coherence. Mainly, if you and I both implement a trait from another crate on the same type in another crate and we compile the code, which implementation do we use?

8. Rust is not as centralized with online communication as Julia is around Slack/Zulip/Discourse. Their version of #appreciation channels is to go on twitter and tell @ekuber what a joy the compilers errors are. There's tons of people on their Discord, and everywhere.

Appreciation of Rust things 🦀

These are things the Rust people have nailed down.

1. Ferris the crab is too cute.

2. Rust people take uwu-ification very, VERY seriously. The uwu project uses SIMD to uwu-ify strings for great artistic value. Julia and Rust both draw me because they make me feel more powerful when I code with them than I think I should be.

3. Governance: The Rust foundation and strong community conduct codes. Given the blow ups that have happened with open source communities recently from short-sighted governance or hate reactionaries tanking projects, this is a welcome sight that will probably pay off for decades to come.

4. Compiler error messages are second to none. Definitely check out clippy too and follow the hints. cargo fmt will also format all your crate so that Rust code is almost always a unified reading experience.

5. Awesome mentors. This is a project maintained Jane Lusby and other volunteers. I've gotten world-class mentorship from kind, patient and friendly Rust folks. Shoutout to Jubilee for her great wisdom and patience and the rest of the stdsimd gang.

6. They also poke the LLVM crowd to improve the compilation times, which is great.

7. They're doc deployment system is unified, polished, and friendly. Inline docs and tests are also great.

8. cargo is a joy compared to Make hell. Pkg is somewhat inspired by it, so that rocks.

What Rust can bring to Julia ⚒

1. A model of governance. The Rust community is at least 10x the size of Julia, and it's unclear that adding more hats to the same TruckFactorCritical people would help. That said, it'd be better to have those conversations sooner rather than later, and building bridges with Rust people seems wise in the long term. I don't think that Rust is the closest model to look up to given the other projects under the NumFocus umbrella that we can learn from, but I don't see what is lost from learning from them.

2. Less vulnerable software in the world is a good thing. Oxidization is great! Sometimes. I don't think any Julia internals will oxidize in the short term, but it would be an interesting experiment to say the least.

3. Error handling: Multiple dispatch may prove advantageous in this domain, and it hasn't been as much of a priority as it has in Rust. Perhaps that merits some careful rethinking for future Julia versions.

4. Awesome Julia mentors, I think we need this.

Acknowledgments 🙌🏻

• Thanks to Jubilee for feedback on this post and the following corrections:

  • Rust does not necessarily have an RC GC but a region based GC. You can opt into the RC GC with Arc and Rc types.

  • Technically Rust doesn't have linear types but affine types.

  • Tokio's story is not as simple as I had made it out to be so I cut some comments

• Alex Weech helpfully suggested refactoring the original Julia Point code to be more similar to the Rust example.

• Daniel Menéndez helpfully suggested adding crates.io or lib.rs

• Thanks to oliver I also read about this post by Chris Lattner, author of LLVM, on the dangers of undefined behaviour, to really scare you out of thinking you know what C is doing under the hood.

• Zamalek1 on HN also provided useful feedback on precise academese: Rust is definitely a memory managed language, but that's been hoisted to compile time.

• Thanks to u/Schnatsel for pointing me to a broken url here and to cargo-asm.

• Thanks to ministatsdev for the string iterator nit.

Hello, World! 👋 I'm Dispatch

My name's Dispatch, your friendly neighbourhood walkie-talkie, and I'm here to talk to you all about Julia - a cool programming language and why I think they made the right calls when they built it.

Reading time: 20 minutes

Summary:

This post is about Julia and multiple dispatch as its foundation. Julia is not

• the first language to implement multiple dispatch (see the lecture link below)

• the only language to use multiple dispatch (Dylan does use it, also available as a lib in Python and others)

but it definitely feels like the first to stick the landing. My claim is this: Julia is unique in implementing multiple dispatch as a fundamental design feature and building a language around it. Don't take it too seriously; it's more an invitation to learn than anything else. If you like this topic, check out "The Unreasonable effectiveness of Multiple Dispatch" JuliaCon by Stefan Karpinski, and this article on "The Expression problem" which inspired that talk. If I was being uncharitable, this post is the watered-down, kawaii-ified version of that talk with some Lisp memorabilia sprinkled on top. Your mileage may vary.

The audience of this post are programmers who like Python/C++/80s MIT Lisp courses who have heard of Julia but don't get what new things it brings to the table. If you want to dive deeper into emergent Julia features, check out Frame's 2 part posts.

Sure, there's a fancy subtyping algorithm that Jeff Bezanson (Julia co-creator) pulled out of Turing-knows-where and that Swift re-adapted with some unholy term rewriting shenanigans, but that's not the "new contribution" I mean - careful design iteration around multiple dispatch with measured trade-offs is.

The rest of this post are code snippets in different programming languages and how they look like next to a Julian re-implementation.

To talk about all these things, we'll be hearing from our newest battery-powered friend, Dispatch.

Dispatch:

Hey peeps, that's me!

... interspersed with a comments of our not-yet-super-proficient-but-keeps-working-at-it-student, miguelito:

miguelito:

¡Hola Dispatch! Nice to meet you!

Off we go! 🚀

What is dispatch?

To begin our journey, we should define some terms. Per Merriam-Webster, to dispatch means:

to send off or away with promptness or speed

to dispatch a letter

dispatch an ambulance to the scene

Dispatch:

And if you have a dispatcher, which is what I do, then you call what you need at the right time. There's no need for extra fussing about! Sometimes you need to call a cab, sometimes its a delivery driver, sometimes its a helicopter. Just dispatch on what you need.

miguelito:

Ok, call what you nee– Aaaaaah, now I get why you're a walkie-talkie. Clever! I'll have to tell my friend Cool Bear about this one...

At any rate - dispatch sounds simple I guess... but all these programmers from the Object Oriented Land keep asking me about where I stand in inheritance vs composition, and my takeaway was that there's a lot of terms I thought knew what they meant, but I have to re-learn for all this programming stuff. I guess I'm just not that into Rectangle vs Square debates...

Dispatch:

Yup, there's a lot of fancy words. It can be hard to describe where you are standing to other people because the Kingdoms of Nouns monopolized the programming language map-making business decades ago.

Now it sucks to get directions anywhere.

But it's cool - just take a deep breath, and, like a well oiled StepMaster, we'll do this one step at a time.

On namespaces as well, those debates are just not going to be as big a problem in Julia Land - we're not too far from them in the theory, but the language doesn't actively prevent you from doing what you already know. In fact, if you know addition, you already have a natural notion of what multiple dispatch is about.

miguelito:

What? No way.

Dispatch:

Of course! What's more natural than addition? You just haven't used the name multiple dispatch for it, which is fine. Bear with me for some simple arithmetic: Can you describe the procedure you know for adding integers? Say you want to add 123 + 890. (This is a good moment to install and open julia from julialang.org if you haven't already done so.)

miguelito:

Sure, you line up the digits, add the columns right to left, carry the ones...

julia> 123 + 890
1013

Dispatch:

Yup. What about trying to add 1//2 + 1//3. Those "fractions" are what we call Rationals in Julia. What procedure do you follow then?

miguelito:

Oh right, the famous regla de tres - find the common denominator, cancel, add up apples to apples...

julia> 1//2 + 1//3
5//6

Dispatch:

Swell. And .25 + 5.2? You're still "adding" things right?

miguelito:

Yup, like adding natural numbers - line 'em up, carry the one.

julia> .25 + 5.5
5.75

Dispatch:

Excelente, ignore the decimals for now. Did you ever face matrices? Can you try to add 2x2 matrix of 1s and a 2x2 matrix of 3s?

miguelito:

Yup - I think we defined it as element to element. So you end up with a 2x2 matrix of 4s.

julia> [1 1; 1 1] + [3 3; 3 3]
2×2 Matrix{Int64}:
 4  4
 4  4

Dispatch:

Alright - thanks for following along. Now here's the tickler question - Who does the + belong to?

miguelito:

...qué.

Dispatch:

Exactly. If you know you're adding 2 Natural numbers, you just use, (or when coding, call) the right procedure. If you + 2 decimal numbers, you call the right thing. It's the addition you've always known! There's this notion of what + should do in different cases, and we wrap them all up under the same + umbrella - even though addition of matrices, decimals and natural numbers mean different procedures. You can check all the ones that come out of the box if you try this:

julia> methods(+)
# 195 methods for generic function "+":
[1] +(x::T, y::T) where T<:Union{Int128, Int16, Int32, Int64, Int8, UInt128, UInt16, UInt32, UInt64, UInt8} in Base at int.jl:87
[2] +(c::Union{UInt16, UInt32, UInt64, UInt8}, x::BigInt) in Base.GMP at gmp.jl:528
[3] +(c::Union{Int16, Int32, Int64, Int8}, x::BigInt) in Base.GMP at gmp.jl:534
...

miguelito:

Oh! But you stated that + "belongs" to someone, so what does + have to do with property?

Dispatch:

Nothing - that's the point! At least not in Julia. It doesn't make sense to say that the + belongs to the 1 or the 2 in the statement 1 + 2, and that's where the headaches come from: when you bind identity to objects, you're gonna have a bad time, as 80s lisp hackers and philosophers alike have struggled with that question for a long, long time – it's just devilishly hard to reason about identity when objects change. Avoid worrying about that if you can. Just worry about calling the right procedure in the right case. In other words, "just dispatch and carry on."

Single dispatch

This post promised comparing different languages. Now that we've discussed what we mean by dispatching, let's see how it's implemented. Astute readers have picked up that dispatching already exists in other languages, albeit in limited form: single dispatch.

I'm going to do some serious hand-waving here, so strap in: in Python and C++, and other object oriented languages, you have the barebones version of dispatch. If a function takes an argument f(a) you can only dispatch on the type of the first argument.

Specifically, we want the function f to behave differently when the types of a are different. Recall our previous examples for addition: if a is an Int, we want it to do one thing - if it's an Float64, another thing.

Whipping up a Python REPL:

>>> class Foo:
...     x = 1
...
>>> class Bar:
...     x = 1
...
>>> def f(a: Foo):
...     print("Just Foo")
...
>>> a = Foo()
>>> b = Bar()
>>> f(a)
Just Foo
>>> def f(b: Bar):
...     print("Just Bar")
...
>>> f(b)
"Just Bar"
>>> f(a)
"Just Bar"

💥WHOOPS!💥 - something went wrong, we should have gotten a "Just Foo" in that last line!

Multiple Dispatch

In the previous section, we wanted f to have two different behaviours depending on the types (and call it polymorphic operator overloading, if we want to bait some Dunning-Krugers on the god-forsaken orange-site). But we won't worry about fancy terms - we just want to our programming language tools to able to behave like the + we know from primary school.

miguelito:

OK - I'll take a crack at this. I've read and reread the Julia Manual page for Methods, and I think I have a better idea of this now. Here's what my Julia code looks like:

abstract type Things end # We'll come back to this line
struct Foo <: Things end
struct Bar <: Things end
f(::Things) = "Just a Thing"
f(x::Foo) = "Just Foo"
f(x::Bar) = "Just Bar"
x = Foo()
y = Bar()
f(x)
f(y)

And it works! I like thinking about this as a table, just like what we talked about with +: I just check what types the arguments I'm applying + to are, and apply to proper procedure. Adding integers means line them up and carry the digits. Fractions, common denominators, etc. For f, if I apply it to an Foo, the procedure is to return the string "Just Foo". If I apply f to an object Bar, it returns the string "Just Bar.". Dispatch and carry on, ach so...

Dispatch:

Great! You're on your way to learn the Zen of Julia!. It usually looks like

1. Setup an abstract type like Things.

2. Make some structs that are subtypes of Things with <:

3. Define functions f that act on specific subtypes of Things - aka dispatching.

4. Create your structs/objects with constructors like x = Foo() and then call f(x) to handle different behaviors.

That's it!

Small nitpick - You actually can dispatch in Python, but it requires a bit of boilerplate, but that's a secondary concern. Since it wasn't a foundational design of the language, people didn't build a vocabulary or an ecosystem around it. In the words of Turing award winner Barbara Liskov,

The quality of software depends primarily on the programming methodology in use. [...] A methodology can be easy or difficult to apply in a given language, depending on how well the language constructs match the structures that the methodology deems desirable. [...] – Barbara Liskov, Abstractions Mechanisms in CLU (1977)

(Shoutout to Quinn Wilton and her great Gleam presentation were I took this quote from). Basically, not all tools can fit nicely into a particular niche, and insisting otherwise is a recipe for frustration, but I guess some companies just have billions in cash for R+D to burn. It's not only honest, but necessary, to know the limitations of your own tools.

miguelito:

Huh - sounds like Julia got really... lucky (?) in that it didn't need to be the first to run up against these problems? That knowledge accrues over decades by loads of smart people by trying, failing, and figuring things out.

Dispatch:

🎉 Correct! 🎉 Julia has benefitted immensely from the efforts of others. We gain nothing from being smug about recent successes - there's still lots of problems to solve and it's in our best interests that we nurture a diverse community of people that we can cross-pollinate ideas with. Maybe someone implements multiple dispatch with some different tradeoffs in Python (like the Plum library!), or type class resolution in Lean or whatever they're building with F* that shows us a new way of thinking. We lose nothing by encouraging people to experiment, far and wide.

miguelito:

Hold up, you had mentioned that Julia's not the first to get multiple dispatch. Why didn't it pick up in the other languages?

Dispatch:

Hmmm, hard to say, I think we'd need to reach out to a legit PL historian for that. However, looking at some of the other key components that coalesce together helps suss some of it out:

1. Common Lisp had an easy opt-in multiple dispatch system, but it was slow. People didn't buy in because it cost performance. There's a social factor to this - if your paradigm takes more effort to use, it's less likely to be grow.

2. Performance was not an afterthought. Look at the graveyard of attempts to speed up Python, all mutually incompatible. The Julia devs designed the abstractions to match LLVM semantics to optimize for performance. At some point, you have to ask if you're standing in the right place to begin with, like the London cabby:

Excuse me, what's the best way to get to Manchester?

Ah, Manchester? I wouldn't start from here...

I don't think Python for performance has failed, but wouldn't start with a language that takes 28 bytes to store an integer:

Python 3.9.3 (default, Apr  8 2021, 23:35:02)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from sys import getsizeof
>>> getsizeof(1)
28

whereas

julia> sizeof(1) # This is in bytes, so an Int on my system is 64 bits
8

3. Speaking of LLVM - JIT compilers are a recent invention, and if LLVM didn't have an open source implementation, who knows if Julia would have picked up. Caching the computation really helps to overcome the bureaucratic overhead of the dispatching system, and it's not at all trivial to see those two things and put them together. But don't take my word for it, hear them say why it wasn't practical then:

4. That video tells precisely the pain-point that Stefan talked about for functional languages in his talk: In Functional Land, it's easy to add new procedures to old types, but unwieldy to add new types to old functions.

Concretely, the code that stumps object oriented PLs is

f(x::Foo) = "Just Foo"
f(x::Bar) = "Just Bar"

and the one that stumps functional language oriented PLs without multiple dispatch is

struct Qux <: Things end
t = Qux()
f(t)

miguelito:

Alright so what I'm really getting here is

1. I should really, really just go watch Stefan's talk.

2. A big "the Romans had a steam engine but didn't industrialize because they didn't have carbon deposits" vibe from all the convergence of PL ideas and techniques.

There's a time and a place I guess.

Dispatch:

Yeesh.

Remember the starting claim for this discussion? It felt so long ago... but the gist was that for all the bells and whistles that Julia has, they needed time and effort to figure out some hard problems that other people had come up against (and whose expertise they drew from!). Julia is the place to park a decision until it gets done right, with oodles of discussions from experts back and forth. That's not a linear process, but I can't complain, we're still increasing the SmileFactor of all the things that feel like they should work, and do. Like the REPL.

Until next time. Toodles. 👋

If you want to see more posts like this, consider chucking a buck or two on my GitHub sponsors, or, you know, hire me as a grad student.

Note:

I created Dispatch by copy/pasting the icon from flaticon.com under the terms of their Flaticon License. It is free for personal and commercial purpose with attribution. I changed the colors to match the Julia dot logo colors. If you plan to use it for commercial purposes, please donate a non-trivial part of your profits from the Dispatch merch to Doctors without Borders.

Thanks a lot to the Julia community for helping with this post, but especially to Thiebaut Lienart and the Franklin.jl team, Stefan Karpinski for his talk and Frames for her blog posts diving into these similar materials.