so

hi everyone um so this is a

re-recording of my talk that i wanted to

give for bobconf

we had a couple of technical issues and

so i decided to

do a re-recording so we can actually

have the

talk as it was intended so yeah this is

darks because get one uh admittedly

that's a little bit click-baity but

uh it's meant to be a bit

tongue-in-cheek so bear with me there

so yeah um first of all who am i

uh i'm raichu um i've been in the

haskell community for around

10 years now uh been writing software

for programming for 30 years um

lots of c plus lots of java but 10 years

ago i found this

programming language called haskell

which i enjoy quite a lot

and uh been using it for lots of stuff

since then um

i'm the author of various uh open source

projects

um some of you you might probably know

there is this

project called haskell vim which is a uh

plugin for for vim um

the syntax highlighting and indentation

and stuff like that and

uh for some reason it has become quite

popular and

uh yeah people seem to be enjoying it um

i'm speaking regularly at conferences so

uh

if you google write you on youtube you

will find a couple of talks

that i've done over the years and um

i'm also co-founder of a hackspace

in betafield which is called acme labs

so hex bases are these

loose um clubhouses if you want to like

where

people meet and uh do projects and stuff

art and beauty software projects

whatever comes to mind

and i'm also the co-founder and cto of

anti in bielefeld

we are uh we are software consultants we

are writing um

software for companies that

want to have certain problems solved and

we

uh we deliver that well at least

that's the intention um maybe you've

heard of us

we've also did the uh the advent of

haskell

2020. uh we picked up that work and

it uh i think it was quite popular and a

lot of people enjoyed that

so yeah it produced a couple of

interesting blog posts so

you can still read those up at the

haskell.com

so yeah um

i said the talk is a little bit

clickbaity so i want to

talk about what this talk is not so this

talk is not like get

bad dark is good i don't want to

convince you to

switch everything to darks and

abandon git that's not the idea i just

want to present an alternative

to what is basically the mainstream at

the moment

because i think darks is a very

interesting

very interesting version control system

because it does

things absolutely in a different way

like it's not just a different ui

for the same concept it does things

conceptually

very different um this talk is also not

a transition guide

uh i can't just take a workflow and then

transform that

into like a git workflow and then

transform that into darks

workflows grow organically this talk

will only give you hints at what darks

can do

and maybe that fits your workflow maybe

it doesn't

so you will have to find ways to

make that work for you if you're

interested in that

so okay let's get started um well

not really first we got to talk a little

bit about the dark's image sorry

um when you have heard about darks there

are a couple of things that

uh that are quite common

like conceptions of the system some

people consider it to be dead

i can assure you it's not just recently

we had a major release

2.16 and we're now at version 2.16.3

um so it's very active it's still being

developed by very very

clever people and yeah it's a life and

kicking

another thing that i hear quite a lot is

that people complain that it's slow

and i don't think that statement doesn't

necessarily make sense on its own

because when you say something is slow

you

have to compare it to something and when

you compare it to git

it's certainly slow git is pretty much

built around the idea that it has to be

optimized

um for every in every nook and cranny

there is optimizations and stuff like

that

so uh to me personally

it really isn't that big of a deal if an

operation just takes

500 milliseconds versus 20 milliseconds

i mean that might be an issue for you

but

with most of the projects that i'm

working on

this is not the issue like the version

control system is not the bottleneck

um the bottleneck is how you use it and

what kind of workflows it

it enables me to do and to me that's

that's way more

that's way more important than like

having

shaving off like three seconds from my

push

um another thing that i hear quite a lot

is like the exponential merge problem

and people talk about that a lot on on

forums and communication platforms and

that is something that has been an issue

with

earlier versions of darks where has been

quite prominent but

um the darks people really

worked out this issue quite a lot so the

issue is that

um when you're merging things you can

run into exponential runtime which is

certainly not something that you would

desire and

uh there are darks people have put a lot

of

work into finding all those edge cases

and

uh fixing them and making the algorithm

better and and the performance

way better and personally i've been

using darts for

years and i never encountered that

problem

um there might be still i mean there's

certainly still places where these these

edge conditions can happen

but um they are

exceptionally rare and that brings me

back to the the idea that

that darks is dead um they are working

on a new

patch theory that eliminates all those

i mean the goal is to eliminate all

those edge cases and

make it more performant and yeah grow

the system so that's that's very

interesting ongoing work at the moment

and i'm going to link you to the paper

that

lies the foundation for that so

this is my favorite everyone knows how

to use git

um yeah what does that mean

um whenever i hear that i i think of

that

and and please don't get me wrong um you

can do the same things

with darts and any other version control

system

but to me the notion you know how to use

something

is pretty much like when you say in a

programming language i know the syntax

of a programming language

what's more important is that you can

produce something meaningful

with that programming language and to me

it's the same thing with version control

yes you can use the version control you

can you can create patches you can push

stuff

but to me the most important thing is um

how to build meaningful patches

especially like in a working context and

i know that's

that's a hard hard thing if you're doing

a prototype and stuff like that and and

i

i admit that i'm sometimes guilty of

doing just

that um especially in a prototype

situation where we're not

100 sure what the end result is going to

be

so yeah to me the idea is that a version

control system has to

really give you something back when you

are

crafting patches in a meaningful way you

have to be able to use them

as as good as possible and dars pretty

much does that and i hope i can

illustrate that later in the demo for

you

so now yeah let's get now now we're

really getting started

so what's the different difference

anyway um

from the from the outside looking in it

might look like

darks is just another version control

system with a slightly different ui and

underneath everything works just like

completely the same

and this is basically the point where

you start to differentiate between a

snapshot based version control something

like git or mercurial

and um a patch-based version control and

this this notion

might be a little bit weird because it

focuses around patches what does that

mean

um i will show you in the demo but first

of all let's let's look at a

situation where we have four

characters here we have we have alice we

have bob

with charlie and eve and alice and bob

they both have

patches a and charlie has been

developing

patch b which is a new feature or

whatever

documentation choose whatever you want

and eve has also been working on a patch

on a patch c

so as it turns out alice and charlie are

working closely together

they are in a team together but at the

moment they're

not in the same office they have to work

remotely

there are different situations where

that might occur like a global pandemic

but yeah so as it turns out those two

are communicating on a regular basis

so um alice knows about charlie's patch

and

she's eager to try it and apply it to

her repository so what she does is she

basically pulls this patch

a couple of minutes later she hears

about eve's patch and

because she's not working on the same

team they're they're not communicating

frequently but

now she hears about it and she's she

thinks oh that's that's actually

something that i want to pull in as well

because

the work that i'm currently doing would

very much benefit from that and now she

pulls that in

um on the other side of the city or

planet uh bob suddenly

uh realizes that eve who he's working

closely together with

has written patch c and he's like oh

great i've been waiting for that patch

for a long time and pulls that in now he

has

pulled that patch and you can now see

alice has

abc and you can maybe sense that

something interesting is going on here

and he has uh bypass patches a and c

um and a couple of minutes later he

hears about charlie's patch

and thinks oh i got to pull that in as

well so now you pull that

in and now you can see that um alice's

repository has

the order the order of patches in which

she pulled those in she has a b and c

and uh bob has a c

and b so

how do their repositories look like now

so with git

um we would have something like this

some kind of

this history so we start at a common

starting point

um alice pulls in charlie's feature she

pulls an eavs feature

and then she merges and what you can see

here is that

these commits these last commits where

the head of

the gift repo is those differ

because with charlie's and eve's patches

they diverged

from that common starting point and now

we have to bring those back together

and these merge commits are created by

the people who have

pulled in the patches it's not like a

fast forward we have to merge something

and now what's happened happening is

that

basically when you are pulling in

patches in a different order

things get very different so it's like

let's say you are there and we you see a

banana and you see an

apple and you take the apple and you

take the banana and you would certainly

end up with a different result if you

would take the banana first and the

apple

so this is something that happens in

version control quite a lot

but um now i want to show you how docs

essentially does the same deals with the

same situation here

so yeah it's demo time hopefully this is

going to work out

so um i'm going to start with a clean

slate here

there's there's nothing there and i'm

going to

make a repository alice and go to alice

repository and i'm going to show you how

darts works here i'm on my remote

machine at the moment

so yeah i've initialized initialize that

repository

you can see this underscore docs folder

is

where darks is doing all the bookkeeping

and now we're going to to uh write a

little

little file and i want to apologize for

the color scheme here

let's do something like that so this is

the file

and we're going to add that to the repo

and

this file is now being tracked and we

want to record

um our initial patch

initial record yeah and now you can see

the docs workflow is like super

interactive yes

what changes do we want to record yes we

have added a file

and we've added the content so darks is

basically prompting us of what we want

to do which is

like super helpful if you want to do

more complex operations

so if you want to take a look at the

repository now we can see that

we have recorded a patch so now let's

just

create all those

all those repositories that we have had

before we've created

bob we create charlie and we

create so all these repositories are now

in the same state

so let's go to um let's go to to

charlie first and uh

build charlie's patch here and which

only basically does is

something like super simple it's not a

keyboard i know so it's a little bit

weird

oh we just add a to the top of the file

and now

we can ask darts what's new and it says

okay at

line one we are going to add character a

so let's record that

yes yes this is charlie

and let's do the same thing with eve

so what eve is doing she's essentially

just going to add b

to the end of the file

yes we're going to add that and this is

so let's go back to alice and reproduce

the workflow that we just had

so

alice is going to pull from charlie

first

so yeah and now we can look at the file

excuse me you can say we can see the

patch has been applied

so do the same thing to e

and we can see those two files have been

merged

so yeah if we look at the history we can

now see

um we've pulled from charlie first then

we pull from eve and what's important

here

is those hashes those those hashes are

essentially the identity

of of what's going on here

so of the identity of the patch to be

more precise so let's go to bob

and pull we do that the other way in a

brown the first thing is we do we pull

from eve because

that's who charlie's been working with

and we pull that

pull that patch and let's take a look at

that

so let's let's let's let's look at those

things side by side let's go into um

alice's repository and the darks log

here

and here you can see so this is this is

what

charlie is seeing uh excuse me about

what bob is seeing

and you can see that even though

so this um just to be precise here

what's happening here is a cherry pick

dart is basically constantly doing

cherry picks and merging

and even though i've cherry picked this

patch

from um from charlie's repository from

excuse me from if's repository

um they actually have the same

the same identity the same hash even

though

they have been pulled in different

orders that have been cherry picked in

different orders so what darks

does is that it doesn't change a patch

identity when it does cherry picking

which is like immensely neat i think

so let's do the same thing with charlie

yes yes and as you can see

it's the same thing you can even do

something like we can get to go from

that repository and

um

dear test test repository

and it just to demonstrate the cherry

picking property here if we

pull from let's say alice she's got all

the patches

um yes i want to take the initial record

do i want to take charlie's

no but i want to take use

let's look at that let's first look at

the file

oh come on yeah and now you can see

even though i've cherry picked the b

just the b

patch and left the a patch behind um

i can still end up with result and

this thing this patch this has still the

same identity

so how can we see that to

repositories have the same state

that's that's the important part we can

look at show repo

and here is this thing which is called

the weak hash and the weak hash

has is computed about all the set of the

set of all patches that are

inside of that repository and if we do

the same thing to bob

you can see those weak hashes

they line up they have they have the

same state

um yeah this is this is this is how the

workflow is different here

so something else which i find kind of

kind of nice

is that um darts can essentially produce

graphics output and

i'm usually using different tools there

but here you can see what's actually

happening like these two

these two patches they don't even though

they

even in a situation where you're in the

same repository and recording those two

patches yourself

darts can figure out that they do not

actually depend on each other

so this the patch that charlie wrote

which essentially just added a to the

file it doesn't

it the only thing that it depends on is

that the initial record is there

it's the same thing with these um

change that just added something else to

the file

so now we can just pick everything

um pick and choose and this becomes even

more interesting if we have way more

patches with

way more features in the repository so

we can pick and choose

all the different things that we want

and we can look at

how they interact with each other and of

course we can also state

dependencies directly like explicitly

say i want to depend on that patch

but i'm not going to to to show that

here

so yeah dogs basically just

treats a repositories a set of patches

and i mean set in a mathematical sense

like

the order of the patches of the elements

that doesn't matter if i have a set b

a and a b it's the same set the order

isn't important so let's talk a little

bit

darks does that let's talk about patch

theory

um so we haskellers we all like our

theory

a lot and uh yeah patch theory

[Music]

just just let me get this straight you

don't need to know the theory to

actually enjoy

uh or be able to work with darts it's

the same thing you don't have to

know category theory to to to know

uh haskell uh basically if you would go

to a category theorist and explain them

from a haskell perspective what a monad

is they would say it's not a monad

you are this is just a very special case

that you're talking about so

um even the theory that we're using in

in

haskell is not exactly like the the real

deal

um and there are very passionate

discussions so i just want to make sure

that you know that even though the

theory is like

maybe intellectually stimulating it's

not like mandatory

so if we're talking about patch theory

let's talk about what the patch is

so a patch basically patch a takes a

repository from some state o

to state a that's what it does so like

adding a file or writing content to a

file that's pretty simple

um if we have two patches and

patch a takes a repository from o to a

and patch b takes it from a to b

we can compose them where hasslers that

that's what we like we compose things

all the time

and uh so does patch theory so we can

like

sequence those patches up

we also want to be able to invert the

patch so we want to

take changes back so if we added a line

we want to get rid of that line

so for every patch there should be an

inverse

so if we have a patch a that goes from

mode to a

o inverted should go from a to o

so we can go back there

um and we should be able to commute

patches so this is a little bit more

tricky and apologize for the notation

but this is important to understand how

docs is basically doing what i just

showed you

so if i f patch a and b and they do not

depend on each other so what does that

mean if

let's say patch a adds a file and patch

b edits the content of that file

of course we can't swap around those

operations that doesn't work

you can't edit the content of a file if

it hasn't been added before

but let's say we're talking about the

situation that we just had before like

we have a file and

patch a adds something to the top of the

file and patch b adds something to the

bottom of the file so line one or maybe

something like maybe line five that

that's where patch b operates

so essentially we could swap those

operations around

and so what these uh subscripts mean is

that it's not essentially this

the patches are not fundamentally the

same they're a little bit different like

say this patch adds

something to line one and this adds

something to line six

if we swap those around um for

for patch b everything shifts up a line

so now this adds

to line five and this still adds to line

one

even though the operations are basically

equivalent

so that's what this is what i mean by

that notation a is basically equivalent

to a1 and b is equivalent to it to be

one

they do the same thing they don't have

they don't

essentially do the same operations like

adding this one this one adds to line

six and this one adds to line 5 even

though they are doing

they are representing the same change

and what's important is that

the context that we end up in like b and

a1

they are still the same they are

identical even though

we switch them around so

how does a merge work then so a merge is

basically

let's take those two patches and bring

them together so how will we do that

we can't just concatenate c to b

we can't just put that on there because

it goes from a to c

and uh we are now in a repository that

has in state b

so with all the rules that we have with

all the the

uh mechanisms that we have we can't now

do a merge

we can say okay first we invert b we're

back in state a

then we can apply c so now we still have

the information of b in there even

though it has been reverted but the

information is still there

we can commute b and c

and then we end up with c1 and b1

and then what we can do we can we can

just throw away

c1 excuse me b1

and then we have a merge we ended up

with the state that we wanted pulled in

all those patches and voila

so this is a nice thing we can now

reason algebraically

about patches which i find i think is

really exciting to me

and another thing that's super exciting

to me is this

merging symmetric um so it doesn't

matter in which order

i'm pulling in those patches so the

the good thing about this is so we first

started using darks

in our hackspace and hackspaces are like

very loose

groups of hackers working together and

you don't necessarily

all of them are like on a on a single

central repository like everyone picks

and pulls and from

picks pushes to everyone else and

um in this situation it's like super

useful if you don't

have the have to maintain the same order

we can work together we have a very

loose workflow there

and we can just put pull out things

together

in the way we want to and uh like

neglect patches and

uh take the ones that we

seem fit for our current situation

that's pretty neat

i i enjoy that quite a lot

so what applications does that have how

do we apply that

and to me um i have a whaling compositor

project which is like

20 000 lines of c code so it's a

reasonably large project

and what i do have free repositories

and um what i essentially do is i i use

this this kind of workflow this this

model or

what darts enables me to do immense

i do i work that i use that quite a lot

um so i have a current repository where

i pull

all the patches in every all the work

happens there and i have

if i have a feature a new feature that

is

is uh not really breaking any

of the workflows or that doesn't

introduce any breaking changes

i pull that into the stable into

sustainable repository and you can see

i highlighted all the number the part of

the version numbers in red

that basically are part of the number

that i'm going to increase with that

release

and whenever there's a new feature that

doesn't break functionality i can

pull that over to stable and whenever i

just have a bug fix that doesn't

introduce any new features

i can pull it over to release and this

is essentially the workflow that we're

using at my company

um it it has proven to be very solid

and i was able to do some very

very exciting to me very very fluent and

fun release engineering like way more

uh i enjoy that way more than i did with

git but that that's a personal

preference

so yeah that is something that that we

enjoy quite a lot

so another thing is that passvale is an

open source project that we are going to

to open source

within the next few days and it's

essentially like a password manager

something like a password store um

password store is using git underneath

and we

thought well the the model of dars is

essentially

super neat if you have a very

distributed password manager so

lots of people working on lots of

different passwords

and you constantly have to merge all

those states and since darts is like

very sophisticated with merging we

thought that would be like a very

interesting

foundation for a uh for a password

manager

and we also have model things like trust

and and all sorts of things so

if you know a password and i give a

password to someone else we can use

pass veil to to use to basically use

uh use password to transfer that

password so we don't have to

use insecure channels like post-its or

pass post it on a chat or

use email or something like that so we

can use the password manager

to transfer our passwords to other

people and work together with them

so this is also something that is proved

to be quite beneficial especially in a

very distributed situations

in which we are at the moment so yeah

um tooling so if you are using git

tooling is great of course there's a lot

of tooling a lot of people use it a lot

of people write

really great tools and um so we are kind

of like

stuck in the situation where i have to

build a lot of stuff ourselves um

which is fun but it's also work and

yeah this this is something that we've

been doing for the last few months

so what i did i i built something that's

called docsgutter

which is a um a plugin for neovim

it's it's written in lua so it's a

plugin for neofilm that essentially does

the things

get gutter tests so it shows us changes

we can

look at the changes that uh we can look

at

different hungs in a file we can jump to

hungs we can

um yeah we can we can essentially like

grab through

our uh project and figure out where are

the changes

and uh what has been changed so this

helps me a lot with uh

when i'm i'm working on a rather large

code base and want to craft all my

patches together

like this goes in that patch and this

goes in there so this is like

very helpful and another thing that i

have is a darts fish prompt

so if you are using the fish or the

friendly indirect

shell that's a prompt that is very

useful

so you can see okay this repository has

changed there

have been added files uh untracked files

and stuff like that so everything you

know from

from from git prompt and something else

that we've been working on is called

dark slab

which is our um we are using that

internally at the moment but we didn't

open source it

but we're planning to we're going to

open source it it's

a um hosting platform essentially that

we're using to

to uh manage our repositories and at the

moment

it's like completely command line based

um which some of you might actually

enjoy and enjoy it quite a lot

everything you need is just darks and

ssh and uh

it works on all those machines and to us

it's great we don't you

need a web interface we can manage all

all our privileges and all our

rights management that is all done on

the command line and that's that's

actually rather exciting and we are

looking forward to open source that to

you

so yeah um that

pretty much brings us to the end um so i

have a couple of resources that you

might find interesting if you really

want to learn darks i have written

a little book a darks book um

because i didn't like the documentation

that was out there and i

thought yeah writing a book would be a

good idea it's basically

uh hosted our at our hackspace because

i wrote it for the hackspace initially

we're using it there and i thought

if we are going to use it there has to

be decent documentation

and it's very simple it's like baby's

first version control system it's not

like

super sophisticated stuff you can start

right off the bat if you've never used

the version control system before

um that works um you can start with the

book

and here is the uh the the

paper that i've been talking about so

this is like supposedly uh

the foundation for the new patch theory

that people have been working on and

there's an experimental

um you can experiment that with the the

latest uh major release of darks

um docs version three is a

an option but it's it's still

experimental so please don't use that

for

for critical code yeah that's about it

if you want to get a hold of me i'm on

twitter write you and you can drop me an

email i'd write you at anti-ide

um so yeah hope you enjoyed that

if you have any questions just drop me

an email or hit me up on chat

yeah thanks bye