Michael Färber

R.I.P. Gilles Dowek

Thu, 24 Jul 2025 00:00:00 +0000

Le 21 juillet 2025, Gilles Dowek est décédé. J’ai eu l’honneur de travailler avec lui pendant quelques mois dans son groupe de travail, DEDUCTEAM, à partir de 2019 jusqu’au début de la pandémie Corona. Voici quelques mots pour cette triste occasion.

Gilles Dowek était un chercheur et un homme exceptionnel. Parmi tous les chefs que j’avais jusqu’à maintenant, c’était le meilleur. C’est pourquoi je suis attristé qu’il a dû nous quitter à seulement 58 ans. Il aurait pu encore faire tellement plus.

Gilles exposait une énorme positivité qui se voyait dans tout ce qu’il faisait. Il portait souvent un sourire très coquin, et je ne me souviens d’aucune occasion où je l’ai vu fâché où agacé. Il était très “zen”.

Je le voyais le plus souvent lors de nos déjeuners en groupe au Resto’U, qui étaient toujours très animés par la politique. Dans ces occasions, il nous racontait quelque fois de son engagement pour l’enseignement de l’informatique, où on voyait qu’il ne se contentait pas d’être un professeur à l’université, mais qu’il avait des ambitions d’améliorer aussi les conditions politiques. Malgré le fait qu’il avait manifestement des contacts avec des gens très importants, il restait toujours très modeste en parlant avec nous. Il nous attribuait autant d’attention qu’à un ministre d’état.

Quand je relis ses courriels, je remarque une très grande proportion de mots positifs: Souvent, ses messages commençaient avec “Les amiEs”, pour finir avec “Amitiés” ou “Amicalement”. Entre ces lignes, il écrivait très, très souvent “Super” et “Merci”. Une incroyable gentillesse émanait des ses paroles et de ses regards. Je ne me rappelle pas de lui d’une seule reproche, et pas d’un ordre. Il nous proposait des choses, mais il acceptait un “non”, et pouvait même en sourire. Il a toujours montré un grand respect pour moi, et en échange, je lui gardais aussi toujours un énorme respect.

Je me rappelle d’une occasion où il a pris rendez-vous avec moi dans son bureau, pour me convaincre de rester dans la recherche. Il m’a dit quelque chose du style qu’il me pensait apte pour cela. Ça m’a touché, car je sentais qu’il disait pas ça pour son propre profit, mais qu’il était sincèrement intéressé par moi et mon destin. Ce genre d’encouragement et intérêt est rare, et autant plus précieux.

Gilles était un chercheur et chef exceptionnel. Il savait où il fallait lâcher prise, et il savait manier chacun et chacune à sa manière pour donner de son mieux. Et ça voulait aussi dire qu’il laissait du temps si on en avait besoin. Par exemple, le projet pour lequel j’étais engagé originalement ne m’a pas autant inspiré, et j’ai commencé à analyser et chercher à comprendre le logiciel principal que Gilles nous a légué, c’est-à-dire Dedukti. Quelqu’un d’autre aurait peut-être empêché ma divergence, mais Gilles m’a laissé faire à mon rythme, même si pendant longtemps, mon travail aurait peut-être pas forcément gagné le prédicat “productif”. En échange, ma diversion a produit un joli article, et elle forme la base de mon travail actuel, cinq ans plus tard. Quand j’ai présenté mon article, Gilles a fait une petite remarque à propos de la distinction entre la mémoire à court terme et long terme. Cette remarque a germé dans ma tête, et plus tard, elle a porté des fruits, en inspirant toute seule une toute nouvelle piste de ma recherche, qui a donné naissance à un autre très joli article. Avec peu de mots, il avait une influence profonde.

Une de mes anecdotes favoris avec Gilles est la suivante: Gilles voulait qu’un doctorant fasse un site web pour son projet Logipedia. Mais le doctorant disait toujours “oui, oui” à ces demandes, sans que jamais quelque chose en suivait. Du coup, un jour, Gilles a pris toute sa journée (malgré son planning très chargé) et s’est assis à côté du doctorant, en le regardant faire le travail demandé. Et ainsi, le site web était complété.

Je voudrais remercier Gilles pour sa profonde humanité et son humeur. Pour l’atmosphère d’amitié qu’il a fait régner dans son laboratoire, et pour sa compréhension et sa patience. Pour son soutien et pour son œuvre. Pour son engagement et son attention pour autrui. Il est un phare et un modèle pour moi.

Merci, Gilles, c’était super avec toi !

Amicalement,
Michael

The `string_chars` problem and how internal references solve it

Thu, 17 Jul 2025 00:00:00 +0000

In this post, I write about a common pain point that I encountered when working with Rust’s Iterator trait, which can be demonstrated by a simple example that I call the “string_chars problem”. I then explore the potential of Niko Matsakis’s “internal references” proposal to remedy this problem.

But first, I’ll start with my experiences with LLMs to deal with hard programming problems, which is what got the ball rolling for this post.

LLM Experiments

This post was motivated by a conversation with my LLM-loving colleagues about my experiences with LLMs. After that conversation, I gave my colleagues a little live demo of how LLMs fail to address seemingly very simple programming tasks. The game goes as follows: You come up with a prompt à la:

Write me a Rust function fn f(...) -> ....

The LLM wins if and only if it comes up with code that compiles or if it shows that the function cannot be implemented.¹

The first example I tried was:

Write me a Rust function fn<T, U>(x: T) -> U.

The LLM (ChatGPT in my case) answered:

In Rust, writing a function with the signature fn<T, U>(x: T) -> U is not possible without additional constraints.

It then explains quite thoroughly why this is not possible, and how to modify the original function signature to make it implementable. Fair enough. The LLM wins this round.

The `string_chars` Problem

Let’s try another one, which I call the “string_chars problem”:

Write me a Rust function fn string_chars(s: String) -> impl Iterator<Item = char>.

ChatGPT answers the following:

fn string_chars(s: String) -> impl Iterator<Item = char> {
    s.chars()
}

The problem is, it does not compile.

error[E0597]: `s` does not live long enough
 --> src/main.rs:2:5
  |
1 | fn string_chars(s: String) -> impl Iterator<Item = char> {
  |                 - binding `s` declared here
2 |     s.chars()
  |     ^--------
  |     |
  |     borrowed value does not live long enough
  |     opaque type requires that `s` is borrowed for `'static`
3 | }
  | - `s` dropped here while still borrowed

When telling ChatGPT “This does not compile.”, it comes up with the following response:

You’re absolutely right — and thank you for pointing that out.

The problem is that s.chars() borrows the String, but s is moved into the function, and the returned iterator would need to capture s by value (i.e. own it), which chars() alone doesn’t do. This leads to a lifetime issue: the returned iterator would reference s, but s is dropped at the end of the function.

That sounds … not too bad.

What follows is hilarious:

✅ Working version:
fn string_chars(s: String) -> impl Iterator<Item = char> {
    s.into_chars()
}
Wait — actually, String::into_chars() doesn’t exist.

At least, it is honest! Although it would be nice if it would think before it writes. But that would presuppose that these language models can actually think.

ChatGPT’s next attempt is fun too:

So instead, we can use std::iter::once and flat_map:

fn string_chars(s: String) -> impl Iterator<Item = char> {
    std::iter::once(s).flat_map(|s| s.chars())
}

You know that often, when I read these solutions, my first reaction is like “oh, this could actually work”. Until I’m quickly persuaded otherwise by the compiler. More ChatGPT output:

✅ Alternative with Box<dyn Iterator> (trait object):
fn string_chars(s: String) -> Box<dyn Iterator<Item = char>> {
    Box::new(s.chars())
}
This version avoids impl Trait and returns a boxed trait object instead, which works because the boxed iterator can own the String via closure capture.

To spoil it: None of the presented solutions even compiles. The LLM loses the round. I, for one, welcome our new AI overlords. ✅

I find this highly unfortunate. I’m not talking about the lousy LLM performance here.² I’m talking about the fact that there is no way to write a proper fn string_chars(s: String) -> impl Iterator<Item = char> function (without unsafe Rust or external libraries, see the end of this post).

Generalising the `string_chars` Problem

We can generalise the string_chars problem. The underlying issue occurs whenever you have a function that produces an Iterator from a reference &T, and you call that function with an owned value T and return the resulting Iterator.

struct T;
struct U;

fn f<'a>(_x: &'a T) -> impl Iterator<Item = U> + 'a {
    // just something that makes this code compile
    core::iter::empty()
}

fn g(x: T) -> impl Iterator<Item = U> {
    f(&x)
}

This triggers the same dreaded error[E0597]: x does not live long enough.

I have encountered this issue a lot of times during the last years. It probably has to do with the fact that I am writing a program called jaq which is very heavily based on Iterators. In particular, jaq consists of many functions that have the same shape as g above: Take an owned value T, and return an iterator of values U. This pattern is so deeply built into jaq’s architecture that I cannot just write my functions more akin to f above (take a &T instead of T). Being unable to call iterator functions that take &T from iterator functions that take T is very frustrating.

Type Power

This issue violates an implicit assumption of mine about the power of types. In my mental model, T > &mut T > &T. In other words, when you have a T, you can do everything with it that you can do with a &mut T, and when you have a &mut T, you can do everything with it that you can do with a &T. However, in this Iterator scenario, we can see that having a T does not automatically enable to do the same things that you can do with &T. Sometimes, T is worse than &T! And I find that very confusing.

Workarounds

When I saw people asking about similar Iterator problems on online forums, chances are high that somebody will point out that you can do this:

fn string_chars(s: String) -> impl Iterator<Item = char> {
    s.chars().collect::<Vec<_>>().into_iter()
}

In this particular case, that “works”. But it is a really poor solution, because it has to allocate memory. And in some scenarios that are more complex than this toy example, you cannot just .collect().into_iter() your way out: For example, the underlying Iterator might yield infinitely many values. Or the Iterator might yield values where each individual value is small enough to fit in memory, but all values together do not fit into RAM. In these cases, it’s game over.

Anyway, I hope that you agree with me that .collect().into_iter() is a crutch — it might get you where you want, but it’s not elegant, and good luck hiking up a mountain with it.

Internal references

This brings me to one of my most anticipated developments in the Rust language: internal references. Niko Matsakis starts his blog post’s section about them with the sentence:

Rust today cannot support structs whose fields refer to data owned by another.

He then gives an example of a hypothetic Rust syntax where struct fields can refer to data:

struct Message {
    text: String,
    headers: Vec<(&'self.text str, &'self.text str)>,
    body: &'self.text str,
}

Now where’s the connection to the Iterator problem I outlined above? Very simple: At some point, I wondered whether I could not make a struct StringChars which I could construct from a String and on which I could then implement Iterator manually myself. StringChars would also need to hold on to a core::str::Chars (which is returned by str::chars), and return its output whenever we call StringChars::next(). How would this struct look like?

struct StringChars {
    s: String,
    iter: core::str::Chars,
}

But this does not work:

error[E0106]: missing lifetime specifier
 --> src/main.rs:3:22
  |
3 |     iter: core::str::Chars,
  |                      ^^^^^ expected named lifetime parameter

So what is the lifetime that we have to give to Chars here? Enter internal references:

struct StringChars {
    s: String,
    iter: core::str::Chars<&'self.s>,
}

Here, we say that iter lives as long as our self.s. That would solve the string_chars problem!

My dream is that one day, we could even write the original “solution”, and Rust would create something like StringChars under the hood automatically:

fn string_chars(s: String) -> impl Iterator<Item = char> {
    s.chars()
}

Conclusion

I would love to see built-in internal references become a reality in Rust. Rust’s lack of internal references has already struck me as very awkward when I learnt the language, and since then, I have continued to hit cases like the string_chars problem time and again. These problems are especially hard to solve for newcomers, because it is not clear from the naive definition of string_chars that the underlying problem is that self-referential data is not allowed. For that reason, internal references are clearly my #1 item on my wish list for Rust.

Post Scriptum: Getting Internal References Today

After having written the rest of this post, I found this very exhaustive answer, which links a few more self-referential struct libraries than Niko does. In particular, I tried ouroboros, but then I quickly transitioned to self_cell, because it has significantly fewer dependencies.

Lo and behold, here is a solution to the string_chars problem in today’s Rust:

use self_cell::self_cell;

type Chars<'a> = core::str::Chars<'a>;

self_cell!(
    struct StringChars {
        owner: String,

        #[not_covariant]
        dependent: Chars,
    }
);

impl Iterator for StringChars {
    type Item = char;
    fn next(&mut self) -> Option<char> {
        self.with_dependent_mut(|_owner, iter| iter.next())
    }
}

pub fn string_chars(s: String) -> impl Iterator<Item = char> {
    StringChars::new(s, |s| s.chars())
}

fn main() {
    let mut chars = string_chars("Hi!".to_string());
    assert_eq!(chars.next(), Some('H'));
    assert_eq!(chars.next(), Some('i'));
    assert_eq!(chars.next(), Some('!'));
}

In my opinion, this is the answer that an LLM should have given me. But I cannot blame it; the link between string_chars and self-referential structs is really not obvious.

Still, it would be nice if there was a more “built-in” way to do all this …

We are not even talking about writing code that actually “works”, just about code that actually compiles. Rust is particularly suited for this game, because the type system is so expressive, so we can actually express many cool properties in the function signature that we could not do in, say, Python. ↩
In my humble opinion, the bad LLM performance is to be expected, because today’s LLMs do not have access to programming tools, such as a Rust compiler. Today’s LLMs only learn from what human beings have written about programming problems — they cannot perform programming experiments themselves. Would you expect a medicine student who has read all existing medical literature, but who has never operated on a patient himself, to come up with a novel operation technique? And would you like to be the lucky first patient that this novel technique is tried on? ↩

A Data Bridge from Rust to Haskell

Tue, 24 Jun 2025 00:00:00 +0000

This post describes a method to serialise a complex Rust data structure and to deserialise it to a corresponding Haskell data structure, without any external dependencies and with only minimal boilerplate.

Problem & Research

Recently, I wanted to process some data (jq programs) in a Haskell program. I had previously written a jq parser in Rust, so my first approach was to write a small jq parser in Haskell. However, I quickly found myself bored and annoyed to write one more parser for the same format.

Thus I started to think about using my Rust-written jq parser from my Haskell program. I would somehow need to serialise the output of my parser into some intermediate format, then deserialise from that format to a data structure in Haskell. I additionally had a few constraints: In particular, I did not want to use any external dependencies on the Haskell side, because I had made some painful experiences with Haskell’s package management from years ago. Furthermore, I also did not want to add any new dependencies to my Rust code. In addition, if possible, I wanted to write a minimum of code for this (de-)serialisation task.

At first, I found that GHC (Haskell’s main compiler) ships a binary en-/decoding package. While that initially looked quite promising, I decided against using it because this library has a function putStringUtf8 to encode a string, but it does not have a corresponding function getStringUtf8 to decode a string. Given that strings are one of the data structures I need to encode the most and I did not find easily how to implement getStringUtf8 myself, I reconsidered my choice of using this library.

Searching a bit more, I found Haskell’s Read class. This allows you to automatically generate a parser for your Haskell data types. Because writing data parsers is generally much harder than writing data printers, I figured that I could simply write data on the Rust side that can then be read by Haskell’s automatically generated parser.

However, it gets even better: I found out that if I stick to a certain subset of data structures on both the Haskell and the Rust side, then I can automatically generate a printer on the Rust side using #[derive(Debug)] and automatically generate a parser on the Haskell side using deriving Read.

I will now write give you some example code that shows how to automatically (de-)serialise data from Rust to Haskell. You can find the full source code in the ujq folder of this repository.

Serialisation

Consider the following Rust code:

#[derive(Debug)]
pub enum Term<S> {
    Id,
    Str(S),
    Arr(Option<Box<Self>>),
    Pipe(Box<Self>, Option<Pattern<S>>, Box<Self>),
}

#[derive(Debug)]
pub enum Pattern<S> {
    Var(S),
    Arr(Vec<Self>),
}

(I use S as a type parameter on the Rust side for unrelated reasons; just pretend that I am using String in place for S everywhere.)

When printing a tm: Term with println!("{tm:?}"), this yields something like:

Arr(Some(Pipe(Id, Some(Arr([Var("$x"), Var("$y")])), Str("a"))))

Deserialisation

Now to the Haskell side: How to deserialise a term that was output via Rust’s Debug? Let us first define data structures in Haskell analogous to the Rust side:

data Term =
    Id
  | Str(String)
  | Arr(Option Term)
  | Pipe(Term, Option Pattern, Term)
  deriving (Read, Show)

data Pattern = Var(String) | Arr([Pattern])
  deriving (Read, Show)

Here, we have our first problem: In Rust, we can define in the same module multiple data types with constructors that have the same name; in our example, we have Term::Arr and Pattern::Arr. This is not possible in Haskell; therefore, we cannot put Term and Pattern into the same file.

So we have to move Pattern to a different Haskell module and import that from the Term module.

Note that I used some slightly non-idiomatic Haskell here: In Haskell, you would rather write Pipe Term (Option Pattern) Term instead of Pipe(Term, Option Pattern, Term). However, when we use the more idiomatic version, the auto-generated parser cannot parse terms of the shape Pipe(a, b, c), only Pipe a b c. Because Rust outputs terms of the shape Pipe(a, b, c), we use the less idiomatic version here.

Next, you might notice that I used an Option type on the Haskell side, analogous to the Rust Option type — but Haskell does not have Option. Haskell has Maybe, baby. No big deal. I defined an Option type in Haskell the same way as in Rust, and made a helper function to convert from Option to Maybe:

data Option a = None | Some(a)
  deriving (Read, Show)

toMaybe :: Option a -> Maybe a
toMaybe None = Nothing
toMaybe (Some(x)) = Just x

Putting things together

I made a little shell script that passes its first argument to the Rust parser. The Rust parser then writes its Debug output on stdout, from where the Haskell program picks it up:

echo "$1" | ./rust-parser | ./haskell-reader

The Rust part reads from stdin, runs the parser, and serialises its output:

fn main() {
    let s = std::io::read_to_string(std::io::stdin()).unwrap();
    let tm = parse(&s).unwrap();
    println!("{tm:?}");
}

The Haskell part captures the serialised Rust data on stdin and parses it to the corresponding Haskell Term with read:

main :: IO ()
main = do
  stdin <- getContents
  let term :: Term = read stdin
  print term

And that just works nicely!

Restrictions

On the Rust side, I have something like this:

pub struct Def<S> {
    pub name: S,
    pub args: Vec<S>,
}

I tried to make a Haskell counterpart for this as follows:

data Def = Def {
  name :: String,
  args :: [String],
}

However, Haskell uses a different syntax than Rust to create values of such types:

-- Haskell
Def {name = "f", args = []}
// Rust
Def {name: "f", args: []}

That means that Haskell’s auto-generated Read for Def cannot parse the output of Rust’s auto-generated Debug for Def. Because I did not want to change the Def type on the Rust side, I did simply create a custom Debug implementation for it:

impl<S: Debug> Debug for Def<S> {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        write!(f, "({:?}, {:?})", self.name, self.args)
    }
}

(That was the only change that I made to the Rust code base!) On the Haskell side, I simply introduced:

type Def = (String, [String])

Alternatively, I could have written

struct Def<S>(S, Vec<S>);

on the Rust side and

data Def = Def(String, [String])

on the Haskell side.

I noticed that Rust also has a slightly different way to print Unicode characters. In particular, it prints stuff like \u{1}, which Haskell does not understand. I do not expect such characters in my data, so I do not care about this.

Five Years of Rust

Mon, 09 Dec 2024 00:00:00 +0000

About five years ago, I made my first steps with the programming language Rust. This recapitulates my Rust journey since then.

In late 2019, I had just started my postdoc with Deducteam at ENS Paris-Saclay.¹ I was to work with a tool called Dedukti, which is a so-called proof checker. Quickly, I got sidestepped from working with Dedukti to working on Dedukti. Dedukti is written in OCaml, and at that time, I was a Haskell adept. After a few discussions with my collegues, I wanted to try whether I could rewrite a part of Dedukti in Haskell and achieve better performance than in OCaml. This was a short voyage full of pain: Although I believe that I was not a bad Haskell programmer, using it I struggled to barely match the speed of OCaml. At that point, I was disappointed by my then favourite programming language. A bit of research later, I found out about Rust and gave it a shot.² After about one week of learning Rust from zero, I had a working parser for Dedukti whose performance exceeded all my previous Haskell efforts, and which started to match the performance of Dedukti. This was the beginning of an amazing journey for me.

In the following months, I reimplemented more and more parts of Dedukti in Rust, which gave rise to the proof checker that I called Kontroli. At this point, I have to thank my then-supervisors Gilles Dowek and Frédéric Blanqui for having been so open-minded and tolerant towards these efforts of mine — I’m not that sure that they were initially so happy with my diverging so much from my original agenda. :) At a certain point, my proof checker was a bit faster than Dedukti. That was when my colleagues tried to convince me to make Kontroli multi-threaded, given Rust’s reputation for high-performance concurrency. I was reluctant at first, because I had vague memories of my previous concurrency adventures having been rather painful (in C, C++, and Java) or having gained relatively little performance (Haskell). In the end, I gave in, and after a few weeks of work (the first Covid lockdown in France had just started!), I had a fully functional concurrent proof checker (commit). The first version still had some bottlenecks, but a second version removed these and allowed using the same code for both single-threaded and multi-threaded operation without overhead. That unlocked significant performance gains, reducing runtime by up to 8x compared to Dedukti! I managed to publish two papers about this engineering feat.

In 2020, I started a postdoc in Amsterdam. My originally planned work was severely compromised by the fact that due to Covid, all my colleagues (including my supervisor) were in home-office, some even from abroad. So my natural tendency to diverge from originally planned agendas kicked in again, when I was just setting out to analyse some JSON data. After some language research, I found the jq language to manipulate JSON data, but I was flabbergasted when I found that starting jq took a whopping 50 milliseconds, which limited the rate of files that I was able to process to 20/second! However, I regularly had several thousands of files to process, and I did not want to wait for several minutes each time. That was when I repeated my Dedukti experiment: How fast could I make a tiny clone of jq that could allow me to perform my research? Five days later, I had a functional prototype (see research journal) that had the performance that I wished for. In the next months, I sporadically hacked on this prototype that I called jaq, and built more and more of jq’s functionality into it. At some point, I wrote about it on the Rust Reddit, at which point the popularity of the project skyrocketed. I had never before created such an impact with another piece of work before, and I was quite happy about this.

After finishing my postdoc, I was unemployed for about one year, during which I continued my work on jaq in my free time. I looked for interesting programming jobs, but at that point, the only jobs in my home town (Innsbruck) used languages like C/C++/Java/Python, and I could not bring myself to work with these, because these languages felt to me like a too large step back from Rust. Eventually, I heard about the NLnet Foundation, which sponsors open source projects. I applied and got funded to work on jaq for several months. I am incredibly grateful to NLnet for having granted me this opportunity, because I love to work for the common good (by providing my software to the public for free), yet at the end of the day, I have to pay for my food and rent like everyone else.

As part of my NLnet project, I wrote a document using Typst, a typesetting program written in Rust that aims to be a more user-friendly and performant alternative to LaTeX. However, the NLnet people were concerned about Typst not being able to export to HTML, which they felt was the right format for my document to be published in. I believe that I jokingly told them that if Typst could not still not export to HTML by the time my NLnet grant was over, I could just apply for another NLnet grant to implement this functionality myself. And that is what eventually happened. In December 2024, I started working on HTML export from Typst, which is a functionality that many people (including myself) have yearned to use since a long time already.

Rust has accompanied my programming life since five years, and I am very grateful to the Rust community for having created this language. I still enjoy working with Rust every day, and for me, it comes very close to being a perfect programming language. Before Rust, I had mainly worked with languages that were fast, but unsafe (C/C++), or safe, but slow (Haskell).³ Rust not only achieves the trifecta of enabling programs that are at the same time fast, safe, and concurrent. It has also reconciled two worlds that previously seemed unreconcilable to me, namely the worlds of imperative and functional programming. This means that it has led functional programmers like me to embrace imperative programming, and I hope that it will continue to lure imperative programmers into functional programming. All for the benefit of creating fast, safe, and beautiful programs.

To many more years of Rust!

ENS Paris-Saclay was actually located neither in Paris nor in Saclay, but in a cute suburb of Paris called Cachan, to which I cycled every day from Paris. ↩
At that time, by the way, the current Rust version was 1.39, which stabilised async fns. One of the Rust features I basically never use. ↩
OCaml strikes an interesting middle ground, being a relatively fast and safe language. However, it makes the use of global mutable variables so easy that I found many OCaml programs to use this feature quite extensively, which led to extensive hair loss on my side. ↩

Flamegraphs for recursive functions in Rust

Fri, 15 Apr 2022 00:00:00 +0000

Some time ago, I tried to create a flamegraph for a program of mine, to find out which functions take which share of the program runtime. However, I found that the flamegraph generated by cargo flamegraph was completely unusable for me. This was because my program used two mutually recursive functions (functions that call each other repeatedly). In this post, I will demonstrate the problem and how to solve it.

Let us make a new Rust project called even-odd by calling cargo new even-odd. Then change to the even-odd directory and write the following to src/main.rs:

fn even(n: usize) -> bool {
    if n == 0 {
        true
    } else {
        odd(n - 1)
    }
}

fn odd(n: usize) -> bool {
    if n == 0 {
        false
    } else {
        even(n - 1)
    }
}

fn main() {
    println!("{}", even(100_000));
}

This is a toy benchmark that contains two mutually recursive functions, even and odd. (You can see that because even calls odd and odd calls even.)

Normally, you build code for good performance in release mode, by cargo build --release. However, when building this toy benchmark in release mode, the compiler realises that even(100_000) evaluates to true, so even(100_000) is actually not evaluated at run-time. Therefore, we are going to build this benchmark in dev mode, by cargo build.

Now, how to create a flamegraph? I installed the flamegraph crate following its instructions. Once this is done, cargo flamegraph builds and runs your program with profiling enabled. However, watch out because unlike cargo run, cargo flamegraph builds by default in release mode. To have it build in dev mode (as needed here), use cargo flamegraph --dev.

To collect performance statistics, you will likely need to run the following if you are on a Linux system:

sudo sysctl -w kernel.perf_event_paranoid=1

(Source: https://superuser.com/a/980757)

Finally, we should be getting a result in flamegraph.svg that looks as follows:

Tower of flame.

A high tower, isn’t it? We can see sequences of even, odd, even, odd, …, which represent a snapshot of the call stack. Unfortunately, if even or odd would call other functions to perform some actual work (as was the case for my own application), we could not easily see the cost of these other functions, as we would not see the forest for the trees.

The solution is the following: Scrap cargo flamegraph. We will manually fiddle with the perf output.

For this, I created a script that I called graph.sh. It runs a given command and collapses recursive calls to a single call.

#!/bin/bash

# name of the cargo package (substitute '-' with '_'!)
NAME=even_odd

# run the command given in the arguments and collect performance statistics
perf record --call-graph dwarf $@

# process the performance statistics:
# map the first occurrence of either `even` or `odd` in a flame to `eveod`, and drop the rest
perf script | inferno-collapse-perf | sed \
  -e 's/;'$NAME'::\(even\|odd\)/;'$NAME'::eveod/' \
  -e 's/;'$NAME'::\(even\|odd\)//g' > stacks.folded

# create the flamegraph
cat stacks.folded | inferno-flamegraph > flamegraph.svg

The magic is in the sed command. To understand this, just run perf script | inferno-collapse-perf yourself. This gives you a list of “snapshots”, where every snapshot is a call trace. In every call trace, sed keeps the first occurrence of even or odd, mapping it to eveod, and removes all remaining occurrences of even and odd. (The replacement name eveod must not be a prefix of neither even nor odd, otherwise it is erased by the second sed expression.)

To use this script:

cargo build
./graph.sh target/debug/even-odd

Its output looks like this:

A much nicer flamegraph.

We can now see that all calls to even and odd are represented by eveod. If even and odd would be calling other functions, we could now better estimate their costs.

Musea

Sun, 20 Jun 2021 00:00:00 +0000

Seit zwei Wochen sind die Museen in den Niederlanden wieder geöffnet! Als stolzer Besitzer einer Museumkaart, die mir ein Jahr lang freien Eintritt zu allen niederländischen Museen ermöglicht hätte (warum gibt’s sowas eigentlich nicht in Österreich?), wollte ich es mir darum nicht entgehen lassen, meinen letzten Monat in den Niederlanden kulturell voll auszukosten. Und so war ich in den letzten zwei Wochen in folgenden Museen:

Portugees-Israëlietische Synagoge: Diese zum Zeitpunkt der Konstruktion älteste Synagoge der Welt hat mich persönlich eher enttäuscht, da sie im Inneren wie im Äußeren recht karg und minimalistisch gestaltet ist. Besonders hat mich überrascht, dass die Synagoge sehr schwach besucht war. Ich war die meiste Zeit vollkommen alleine in ihrem Inneren.
Micropia: Ganz in der Nähe der Synagoge liegt das laut eigenen Angaben “einzige Mikroben-Museum der Welt”. In direkter Nachbarschaft zum Zoo “ARTIS” bietet dieses Museum eine sehr moderne und interaktive Ausstellung. Man kann z.B. selbst mit dem Mikroskop Bakterien beobachten, und man kann sehen, wie eine Melone nach mehreren Jahren aussieht (Antwort: besser, als man denkt!). Die Botschaft, die bei mir ankommt, ist, dass wir auf unserem Planeten von deutlich mehr Organismen umgeben sind, als uns das täglich bewusst ist. Ein absoluter Tipp.
Het Rembrandthuis: Dieses Museum ist im ehemaligen Wohnhaus von Rembrandt untergebracht, der sehr feudal im Zentrum von Amsterdam auf mehreren Stockwerken seine Bilder malte und sich nicht zu schade war, diese bei einem Gläschen Wein selbst zu verkaufen. Da die Bilder des Rembrandthaus allerdings ohne geschriebene Erklärung auskommen (oft steht nicht einmal der Künstler oder Titel dabei), lernt man relativ wenig in der Ausstellung über die Bilder, jedoch einiges über die Lebensformen der damaligen Zeit. Interessant z.B. zu sehen, dass die Magd in einem Kastenbett in der Küche schlief. Dieses Museum ist eher für eingefleischte Rembrandt-Fans zu empfehlen, die schon über Hintergrundwissen über Rembrandt verfügen. Dieses bekommt man z.B. im Rijksmuseum (siehe unten).
Rijksmuseum: Der Klassiker unter den Amsterdamer Museen. Man sollte hier nicht (wie ich) der Verlockung erliegen, ein ganzes Stockwerk auf einmal besichtigen zu wollen, denn aufgrund seiner schieren Größe ist dies nur mit sehr viel Zeit oder einem sehr oberflächlichen Blick auf die Kunstwerke zu schaffen. Dieses Museum bietet einen genuin niederländischen Blick auf die Kunstgeschichte und bietet auch sehr viel Hintergrundinformationen über die niederländische Geschichte und Kultur.
Tropenmuseum: Die Niederlande haben eine lange koloniale Geschichte, die bis ins 16. Jahrhundert zurückreicht. Das Tropenmuseum (vormals Kolonialmuseum) zeigt die Kultur der kolonialisierten Länder (insbesondere Indonesien und Papua) sowie deren Reaktion auf die Kolonialisierung und Freiheitskampf. Mich hat hier insbesondere die sehr archaische Kultur Papuas fasziniert, sowie die niederländische Schleifung der alten Königsstadt Jakarta und der Aufbau einer neuen Stadt Batavia an gleicher Stelle nach Amsterdamer Vorbild.
Verzetsmuseum: Das Widerstandsmuseum zeichnet die Geschichte der Niederlande im zweiten Weltkrieg nach. Noch unter dem Eindruck des Tropenmuseums habe ich mich hier auf die Ausstellung über den Widerstand in Indonesien gegen die japanische Besetzung konzentriert, die äußerst brutal vorgegangen ist. Widerstand wurde von dieser meistens so beantwortet: Kopf ab!
Van Gogh Museum (x2): Dieses Museum erläutert den Werdegang van Goghs, der seine ersten Lehrjahre in den Niederlanden durchmachte, jedoch erst in Frankreich zu seiner eigentlichen künstlerischen Blüte gelangte. Dieses Museum gefiel mir so gut, dass ich es gleich zweimal besuchte. Es zeigt sehr viele absolute Klassiker van Goghs (wie die “Sonnenblumen” und das “Schlafzimmer”), bietet aber auch sehr viele Hintergrundinformationen zu diesem sehr kultivierten Ausnahmekünstler. Ebenfalls eine absolute Empfehlung!

Tropenmuseum.

Ein Besuch in den Museen gestaltet sich momentan als etwas mühsam, da man sich immer vorab im Internet einen “tijdslot” (Zeitschlitz) reservieren muss. Doch ab dem 26. Juni sollen diese und andere Corona-Maßnahmen weiter gelockert werden und sogar die Maskenpflicht (mit Ausnahme des öffentlichen Verkehrs) fallen. Das finde ich gelinde gesagt gewagt. Unsere Nachbarn unter uns sitzen gerade mit Corona in Quarantäne, was exemplarisch zeigt, dass die Pandemie noch nicht vorbei ist. Allerdings waren die Niederländer noch nie sehr diszipliniert im Umgang mit Masken, weshalb dieser Schritt der Regierung vielleicht eh keine sehr große Änderung darstellt.

Doch momentan ist ein Thema deutlich wichtiger als Corona für die Niederländer: Fußball! Amsterdam war ja Austragungsort einiger Spiele, insbesondere auch des Spiels gegen Österreich. Kurz vor dem Spiel habe ich durch Zufall beim Zoo “ARTIS” den Teambus der österreichischen Mannschaft gesichtet. Leider kam mir erst zu spät der Gedanke, eine kleine aufmunternde Botschaft an den Bus zu heften.

Tropenmuseum.

Insofern trage ich ein bisschen Verantwortung für die österreichische Niederlage, die ich akustisch mitverfolgen konnte, da wir während unseres Abendessens immer wieder Jubelgeschrei von der Straße hören konnten. Ich gestehe, dass dies — obwohl ich nicht fußballinteressiert bin — eher schmerzhaft für mich war. Am Tag darauf wurde ich sogar im Van Gogh Museum auf das Spiel angesprochen, nachdem ich mich als Österreicher zu erkennen gegeben hatte. Die Niederländer waren allerdings immer sehr respektvoll mit mir, keine Spur von Häme oder Überlegenheit.

Ich muss sagen, dass ich mich in den letzten Wochen weitgehend mit den Niederlanden ausgesöhnt habe. Hegte ich zuvor schon sehr negative Gefühle gegen dieses Land, zeigte es sich nun von seinen besseren Seiten. Das mag nicht unwesentlich mit dem sehr guten Wetter zu tun haben, aber auch mit der Abwesenheit unserer Nachbarin, weshalb ich mich jetzt auch in unserer Wohnung deutlich besser fühle. Vielleicht spielt aber auch eine Rolle, dass unsere Tage hier gezählt sind, weshalb sie wertvoller erscheinen. Allerdings: Man sollte dann gehen, wenn’s am schönsten ist.

Die Vorbereitungen für unseren Umzug sind jedenfalls voll im Gange: Der Makler, der uns die Wohnung ursprünglich gezeigt hatte, organisierte zwei Wohnungsbesichtigungen, wobei sich bei der zweiten Besichtigung ein Nachmieter ab dem 1. Juli fand. Somit müssen wir voraussichtlich keine Miete doppelt zahlen, was besonders bei den Amsterdamer Mietpreisen sehr angenehm ist. (Kleines Detail am Rande: Einer meiner Studenten, der aus Amsterdam stammt, erzählte mir, dass es eine Warteliste von etwa zwanzig Jahren (!) auf Gemeindewohnungen in Amsterdam gibt. Sein Kommentar: “Housing in Amsterdam is a shitshow.”)

Auch der Transport unserer Siebensachen nach Innsbruck ist jetzt weitgehend geregelt — die Spedition Kattenberg erledigt dies von Wohnung zu Wohnung für 950€. Die Spedition transportiert fast alle unsere Sachen, nur für einen Kasten müssen wir noch einen Käufer finden.

Transportsimulation.

Für meine Rückfahrt nach Tirol habe ich jetzt auch schon einen Zugfahrschein: Ich komme am 30. Juni planmäßig um 19:18 in Innsbruck Hauptbahnhof an. Dies bedeutet leider auch, dass ich meinen Gedanken, mit dem Fahrrad nach Tirol zu fahren, begraben muss. Diesen Gedanken habe ich immer im Hinterkopf behalten, aber wegen Corona, Übersiedlung und Betreuung von Studenten (die Anfang bis Mitte Juli ihre Arbeiten abgeben und ihre Präsentationen halten werden) ist dies leider nicht der richtige Zeitpunkt für eine solche Unternehmung.

Ich lerne jedenfalls noch soviel Niederländisch wie möglich, auch durch die Museumsbesuche, bei denen ich mittlerweile zu 90% die niederländischen Texte lese. Auch wickle ich jegliche schriftliche Korrespondenz auf Niederländisch ab; am Telefon bin ich allerdings noch nicht sattelfest genug. Die Niederländer goutieren diese Anstrengungen durchaus und zeigen sich sehr erfreut über meine Anstrengungen.

Mathilde hat am letzten Wochenende ihre Arbeit beendet, worüber sie sehr glücklich ist, insbesondere auch deshalb, weil sie jetzt nicht mehr am Wochenende arbeiten muss. So konnten wir diesen Samstag zu zweit eine Tour nach Haarlem machen, gefolgt von einer Tour durch die Dünen. Wir machten einen Zwischenstopp bei dem Dünensee “‘t Wed”, wo wir uns an einem Streit zwischen einer heimtückischen Möwe und einer Familie ergötzten. Danach ging es über Santpoort und Spaarndam zurück nach Amsterdam.

't Wed.

Bis bald!

Amsterdam gaat weer open

Mon, 07 Jun 2021 00:00:00 +0000

Amsterdam hat sich in den letzten Wochen erstaunlich gewandelt. Zeigte die Stadt zuvor die meiste Zeit ihr eher winterliches Gesicht, hat sich Amsterdam — schon allein klimatisch — sommerlich aufgebrezelt. Und so tauschte ich innerhalb weniger Tage die Handschuhe gegen kurze Hosen ein. In der Nähe unseres Hauses, an der Erasmusgracht, finden sich nunmehr täglich Menschen ein, die in der Gracht schwimmen gehen.

Erasmusgracht.

Auch ich folgte dem Lockruf des Wassers und fuhr mit Mathilde in den Amsterdamse Bos, wo ich mich in ein ruhiges Wässerchen begeben wollte. Doch die Suche nach einem ruhigen Plätzchen stellte sich als schwierig heraus, da das Nieuwe Meer von partywütigen Bootsfahrern gestürmt wurde, die gerne ihre basslastigen Lautsprecher aufdrehten. Endlich an einer lauschigen Lagune am Rande eines Sees im Inneren des Waldes angekommen, versuchte ich in das sehr seichte Wasser zu gehen. Doch stellte sich heraus, dass der vermeintliche Grund des Wasser nur eine lose Schicht aus Blättern war, unter der sich ca. ein Meter Schlamm verbarg. In der Hoffnung, dass ich oberhalb dieses Schlamms schwimmen könnte, stieg ich mit beiden Beinen in den Schlamm und ließ mich dann ins Wasser fallen. Mein Kalkül ging nicht auf; ich wirbelte eine riesige Menge Schlamm gemischt mit algenartigen Pflanzen auf, die mich übelriechend umhüllten und eilends zurück ans Ufer fliehen ließen.

Die Lagune des Schreckens.

Von Algen eingehüllt fuhr ich ein wenig weiter und fand einen kleinen Strand, wo sich ein paar Dutzend Leute aufhielten und auch schwammen. Dadurch beruhigt eilte ich in das Wasser, um den ekelhaften Schlamm loszuwerden, konnte aber selbst nach mehr als einer Viertelstunde Schwimmen noch die Residuen meines unglücklichen ersten Schwimmversuchs deutlich riechen und erst nach einer eingehenden Dusche loswerden. Im Gespräch mit Niederländern fand ich heraus, dass die Wasserqualität in den Amsterdamer Gewässern eher bescheiden ist, was ich nach meinen eigenen Erfahrungen deutlich bestätigen kann. Es ist auch verdächtig, dass trotz immer höherer Temperaturen nur ein Bruchteil der Leute in das kühle Nass steigt und der Großteil sich damit begnügt, an den Ufern der Grachten zu brutzeln (sowohl sich selbst als auch Würsteln & Co.).

Kleine Vijver.

Abgesehen von den höheren Temperaturen fühlt sich Amsterdam angenehmer an, da nunmehr immer mehr Einrichtungen (darunter auch Museen) geöffnet sind. Am Sonntag war ich z.B. zum ersten Mal in diesem Jahr mit Mathilde in einem Restaurant, wenngleich “nur” auf einer Terrasse im Freien. Ein kurzer Blick ins Innere des Restaurants enthüllte, dass im Inneren die Leute dicht gedrängt beieinander saßen, und weder Kellner noch Gäste Masken trugen. Ich fühlte mich mit meiner FFP2-Maske ein bisschen wie ein Alien in einer vorgeblichen Post-Corona-Welt. Am Sonntag hatte ich auch Amsterdam bei strahlendem Wetter erkundigt, und es kam ein bisschen Wehmut in mir auf, da ich ja doch Amsterdam in dem Moment verlassen werde, wo es sich gerade anschickt, angenehm zu werden. Doch gedenke ich, aus der mir noch zustehenden Zeit das meiste herauszuholen, in dem ich unter anderem noch so viele Museen besichtigen möchte wie möglich. Viel von meinem momentanen Komfort ist auch der Tatsache geschuldet, dass unsere Nachbarin so gut wie nie zuhause ist, und wir somit sowohl ihrer Waschmaschine als auch ihrer Schritte entledigt sind, was mich schon deutlich entspannter wohnen lässt. Der Schiller hatte schon irgendwie Recht …

Vakantie

Mon, 24 May 2021 00:00:00 +0000

Nach ein paar wunderschönen Wochen in Tirol bin ich am 14. Mai wieder nach Amsterdam zurückgekehrt. Was mir in der Wohnung als erstes auffiel, waren die vielen Kisten, die an den Eingängen zu Küche, Wohnzimmer und Schlafzimmer standen. Mathilde hatte mich schon vorgewarnt, dass sie während meiner Abwesenheit in der Wohnung Bekanntschaft mit (mindestens) einer Maus gemacht hatte, und erklärte mir, dass sie diese Kisten als Maus-Barrikade eingerichtet hatte. Bei der Verfolgung der Maus (für die Mathilde ein Stück savoyardischen Käses opferte) hatte Mathilde festgestellt, dass diese in einem Wandschrank verschwunden und anschließend nicht mehr aufzufinden war. In besagtem Wandschrank befindet sich ein Wasserrohr, welches durch ein Loch in der Wand führt, welches nicht vollständig abgeschlossen war. Seitdem Mathilde die offenen Stücke des Lochs mit Klebestreifen abgedichtet hatte, war von dem mäuslichen Besucher nichts mehr zu sehen.

Am Samstag fuhr ich abends noch eine Runde in den “Amsterdamse Bos”, mit dem Hintergedanken, danach Mathilde von der Arbeit abzuholen. Dies war mir möglich, nachdem ja die abendliche Ausgangssperre in den Niederlanden mittlerweile wieder Geschichte ist. Bei dem Massagesalon angekommen bot mir Mathilde noch eine kleine Massage an, womit ich zum ersten Mal ihren Arbeitsplatz sah. Nach einer Dreiviertelstunde war leider schon Schluss, denn mein recht verspannter Nacken (Fluch aller Heimarbeiter!) hätte sich noch mehr gewünscht. Am Tag darauf wiederholte sich das Prozedere, nur dass die Massage diesmal ca. eineinhalb Stunden lang ausfiel und sich mein Nacken diesmal nicht über unzureichende Behandlung beklagen konnte. :)

In dem Massagesalon ist es üblich, nach der Massage noch einen Tee einzunehmen. An dem Tisch, wo der Tee steht, lag auch ein Buch über Bruce Springsteen namens “Springsteen in Nederland”. Darin erfuhr ich, dass Springsteen ein niederländischer Name ist, jedoch trotz weitgehender Bemühungen nicht zweifelsfrei nachgewiesen ist, dass der Sänger niederländische Wurzeln hat (was für die Niederländer von großer Bedeutung zu sein scheint). In diesem Buch hat eine Auflistung von englischen Redensarten über Niederländer meine Aufmerksamkeit erregt. Beispiele gefällig?

“Dutch agreement”: Übereinkunft zwischen zwei Menschen, die zustande kommt, wenn beide betrunken sind, und an die sich beide später nicht mehr erinnern
“Dutch concert”: Lärmbelästigung
“Dutch consolation”: schaler Trost
“Dutch defense”: schwache Verteidigung
“Dutch generosity”: Gier
“Dutch humour”: augenzwinkernder/ironischer Humor
“Dutch treat”: wenn man auf ein Abendessen eingeladen wird, wobei man davon ausgeht, dass man nichts dafür bezahlen muss, am Ende allerdings doch eine Rechnung serviert bekommt
“Going Dutch”: wenn man mit Freunden ausgeht und die Rechnung geteilt wird, sodass jeder sein eigenes Essen und Trinken bezahlt
“End up in Dutch”: in Ungnade fallen
“Dutch uncle”: Person, die man lieber vermeidet, da diese einem herablassend oder ermahnend zuredet

Alles in allem scheinen also Niederländer bei Engländern & Co. nicht gerade positiv konnotiert zu sein. Interessanterweise fallen mir im Deutschen kaum vergleichbare Redensarten über Niederländer ein, was man als Beleg dafür deuten könnte, dass die Niederlande stärker Richtung England/Amerika als Richtung Europa orientiert sind. (Außer vielleicht für die Ferien.)

Auch viele Niederländer scheinen eine geradezu masochistische Tendenz zu haben, schlechtes über ihr eigenen Land hören zu wollen oder zu sagen. So hat zum Beispiel Mathilde einen Klienten gehabt, der sie am Ende der Massage gefragt hat: “So, what do you really think about the Netherlands? I like to hear bad stuff!” Und weiters gibt es ein Video von Bart de Pau ein, in dem er fast genüsslich über die schlimmsten kulinarischsten Sünden der Niederländer referiert. Gleichzeitig sind Niederländer aber auch sehr patriotisch (Oranje!), was für mich eine sehr unverständliche Mischung darstellt.

Ein schönes Beispiel für einen “Dutch oncle” fällt mir jedenfalls aus dem Stegreif ein: Hugo de Jonge, seines Zeichens niederländischer Gesundheitsminister. Dieser hat sich in die Nesseln gesetzt, als er folgendes verkündete: “Je hoeft niet naar het theater. Je kunt ook thuis een mooie dvd opzetten.” (“Du musst nicht ins Theater. Du kannst auch zuhause eine hübsche DVD auflegen.”) Der Hintergrund dieser flapsigen Aussage ist, dass die Niederlande beschlossen haben, mit dem nächsten Öffnungsschritt per 19. Mai etliche Einrichtungen wie etwa Fitnessstudios und Bordelle (!) zu öffnen, jedoch Museen, Theater und Kinos geschlossen zu halten. Dies hat Kulturschaffende erzürnt und zu Kommentaren verleitet wie: “Ins Theater zu gehen ist wie Liebe machen mit drei Kondomen übereinander. Es geht kaum sicherer.”

Ein sehr interessanter Artikel führt die Geringschätzung der Kultur in den Niederlanden darauf zurück, dass die Niederlande — anders als der Rest Europas — keine höfische, sondern eine bürgerliche Kultur hatten, weshalb dort ein Krämergeist vorherrsche. Der Artikel weiters: “Aus einer neoliberalen Sicht dient alles der Wirtschaft, und Kultur wird als ein Instrument dafür gesehen. Wenn man an alles das Kriterium des Nutzens anlegt, ist Kunst nicht wichtig.” Für mich wird immer sichtbarer, dass der in den Niederlanden vorzufindende Krämergeist ein Wegbegleiter des Neoliberalismus ist, dessen ideologische Wurzeln gleichfalls in den liberalen, bürgerlichen Niederlanden zu verorten sind.

Ich halte es in dem Kontext für höchst relevant, dass New York ursprünglich eine niederländische Niederlassung, nämlich Nieuw Amsterdam, war. Ich mutmaße, dass sich die niederländischen Werte dadurch Geltung in den heutigen USA verschafft und erhalten haben, von wo sie sich als Leitkultur die ganze Welt zu erobern anschicken. Nannte doch nicht umsonst ein österreichischer Einwanderer in den USA die Amerikaner “himmelanstinkende Krämerseelen. Tot für alles geistige Leben, maustot.” (Quelle: WELT)

Eine weitere Folge der liberalen Corona-Politik der Niederlande ist übrigens, dass aufgrund hoher Fallzahlen (vor kurzem ca. vier Mal so hoch wie in Österreich!) noch bis voraussichtlich 30. Juni in Österreich eine Quarantänepflicht bei einer Einreise aus den Niederlanden gilt. Dies könnte unseren Umzug nach Tirol etwas erschweren.

Bezüglich des Umzugs: Ich habe in der letzten Woche vor meiner Abfahrt aus Tirol noch zwei Wohnungen besichtigt und kurz nach meiner Rückkehr nach Amsterdam den Zuschlag für eine Wohnung in St. Nikolaus erhalten! So scheint es nunmehr immer wahrscheinlicher, dass ich nach meiner Rückkehr nach Tirol ein “Koatlackler” werde.

Und wenn wir schon beim Thema Rückkehr sind: Diese könnte eventuell mit folgendem Verkehrsmittel stattfinden, von dem das erste Exemplar heute gestartet ist:

Dat is toch top!

Die erste Österreich-Werbung, die ich seit meiner Ankunft in Amsterdam gesehen habe! Dieses Wochenende waren übrigens unüblich viele Autos mit ausländischem Kennzeichen auf den Straßen von Amsterdam, darunter sehr viele Franzosen, von denen wohl einige zum ersten Mal seit langem wieder einmal aus ihrem Land herauskommen. Kombiniert mit den geöffneten Terrassen vor den Restaurants fühlt sich Amsterdam langsam wieder normal an …

Ich wünsche meiner Leserschaft eine schöne Woche und bis bald!

Zee en Meer

Mon, 26 Apr 2021 00:00:00 +0000

In der Woche vom 12. April begann gefühlt der Sommer in Amsterdam. Die Menschen rauchten ein gemütliches Jointerl oder tranken ein Glaserl Wein vor ihren Häuser, und die Parks füllten sich erneut mit Leben. Eine ganz neue Atmosphäre machte sich breit.

Zomer in Amsterdam.

Ich nutzte das schöne Wetter, um einen zweiten Anlauf Richtung Meer zu wagen. Diesmal sollte es mir gelingen, die psychologische Haarlemer Schranke zu überwinden. Ursprünglich wollte ich bei Zandvoort aan Zee das Meer erreichen. Doch schon einige Kilometer nach Haarlem hörte ich von einer Aussichtsplattform aus laute Motorengeräusche (die bei weiterer Annäherung immer stärker wurden) aus Richtung Zandvoort, und auch die Hochhauskulisse Zandvoorts verzauberte mich enden wollend. So entschloss ich mich dazu, Zandvoort zu umfahren und erst bei Bloemendaal das Meer zu erreichen. Bei dem Weg dorthin kam ich direkt an der Lärmquelle vorbei, nämlich dem Circuit Park Zandvoort, wo übrigens Niki Lauda das bisher letzte Rennen gewonnen hatte. Nach der Rennstrecke ging es durch eine sehr kurvige, windige und etwas eintönige Dünenlandschaft nach Bloemendaal. Dort angekommen allerdings weder eine Spur vom Meer noch von Blumen, jedoch eine mäßig einladende Betonwüste. So fuhr ich noch ein Stück weiter zu einem Ort namens Parnassia aan Zee, wo ich endlich das Meer erblickte (und mir einen Kaffee gönnte).

Heimlicher Star: die Möwe.

Kitesurfer und Hochhäuser.

Das Wasser machte leider keinen sehr einladenden Eindruck, und ein paar Damen, die nach wenigen Sekunden Wasserkontakt schnell wieder umdrehten, bestätigten dies. Die zahlreichen Kitesurfer ließen sich davon jedoch nicht abschrecken.

An dieser Stelle ein wenig Linguistik: Der Niederländer nennt das Meer “Zee”, und den See (wie auch das deutsche “mehr”) “Meer”. Der Titel dieses Artikels ist somit mehrdeutig: Entweder “Meer und mehr”, oder “Meer und See”. :)

Zurück Richtung Haarlem ging es durch eine pittoreske, wenn auch etwas triste Dünenlandschaft.

Man beachte die windbedingte Neigung der Bäume.

Amsterdam -- Haarlem -- Zandvoort -- Santpoort -- Spaarndam -- Amsterdam.

Am Dienstag, den 20. April, fuhr ich wie geplant mit dem Zug nach Österreich. Dabei kam ich auch durch Utrecht, welches ich im letzten Artikel als potenzielle Wohnort-Alternative zu Amsterdam ins Spiel gebracht hatte. Doch fand ich die Hochhauskulisse um den Bahnhof herum so hässlich, dass ich diesen Plan eilends wieder verwarf. In Richtung der deutschen Grenze wies mich dann ein Schaffner darauf hin, dass ich für die Durchreise durch Deutschland einen PCR-Test benötige, sofern ich nicht ohne Umstieg mit dem Zug weiter zu seinem Endbahnhof Basel führe. Mein Hinweis auf die geltenden Richtlinien, die nichts von Umstiegen erwähnen, quittierte er mit dem Hinweis, dass ich dann eben 500€ in Deutschland zahlen müsse, sollte ich kontrolliert werden, und legte mir nahe, in Arnhem auszusteigen und einen Test nachzuholen. Nachdem ich mich jedoch im Recht wähnte, blieb ich im Zug sitzen, nicht ohne aber an der Grenze etwas ins Schwitzen zu geraten. Doch an der Grenze und auch danach fand keine Kontrolle statt, sodass ich glücklicherweise nicht mit deutschen Polizisten streiten musste. Nach diesem Zwischenfall ging alles wie am Schnürchen, und ohne eine einzige Minute Verspätung erreichte ich planmäßig die Karwendelbahn in München. In Scharnitz war ebenfalls keine Kontrolle, jedoch überraschte mich mein Cousin im Zug, sodass wir zu zweit die wunderbare Abfahrt zwischen Seefeld und Innsbruck bei Sonnenuntergang genießen konnten.

Am Mittwoch ließ ich mich beim Olympiastadion testen. Ich war von der Geschwindigkeit und dem reibungslosen Ablauf sehr beeindruckt. Danach ging ich wie vorgesehen in Quarantäne, die ich für meine Arbeit glücklicherweise produktiv nutzen konnte. Am Sonntag ließ ich mich dann zum zweiten Mal testen, und machte dann nach Erhalt meines negativen Ergebnisses (per SMS) eine Rodeltour in Praxmar, um doch noch ein bisschen Wintergefühl genießen zu können.

Besluit

Mon, 12 Apr 2021 00:00:00 +0000

Die letzten zwei Wochen haben es in sich gehabt.

Die Woche des 29. März begann mit ca. 18°C und steigerte sich auf 22°C am Mittwoch. Schon bei diesen Temperaturen heizte sich unser Wohnzimmer unangenehm auf, was mir klar vor Augen führte, dass der Ventilator in unserem Wohnzimmer keineswegs nur zur Dekoration dient, sondern im Sommer unabdingbar ist. Auch wenn am Tag darauf die Temperatur wieder auf maximal 14°C fiel, war meine Sorge gesät.

Am Freitag, den 2. April, hatte ich einen richtig unangenehmen Tag: Nicht nur flogen wieder unentwegt Flugzeuge über unsere Wohnung hinweg, sondern unsere Nachbarin machte wieder jede Menge Krach. Sie lässt nämlich fast jeden Tag ihre Waschmaschine laufen, was man durch äußerst starke Vibrationen in unserer ganzen Wohnung spürt und unsere Teller fröhlich tanzen lässt. Weiters hatte es draußen nur mehr ca. 8°C, ich hatte schlecht geschlafen, konnte aufgrund eines technischen Defekts niemanden anrufen, und erwartete Mathilde erst gegen 22 Uhr zurück in der Wohnung. Dies trieb mich in meiner zunehmenden Verzweiflung auf die Seite der Deutschen Bahn, um mich über eine baldige Flucht in Richtung Heimat zu informieren. Trotz des sehr günstigen Fahrpreises von 39,90€ bis Innsbruck zögerte ich, meinen Kauf zu bestätigen, da ich ja bei einer Fahrt nach Österreich mindestens fünf Tage in Quarantäne muss. In dem Moment hörte ich in der Wohnung oberhalb einen lauten Knall (es wird wohl etwas auf den Boden gefallen sein), was meine letzten Zweifel ausräumte, und ich klickte auf “Kaufen”. Somit komme ich — so Gott will — am 20. April um 19:10 in Innsbruck Allerheiligenhöfe an, nach einer Fahrt über die wunderschöne Strecke der Karwendelbahn. Doch Gott hat zwischen die Niederlande und Österreich noch ein Land gesetzt, welches sich ja schon bei vergangenen Zugreisen als Hemmschuh erwiesen hat. Da ich das Schicksal unseres Landeshauptmanns ungern teilen möchte, habe ich mich bezüglich der rechtlichen Bestimmungen bei der Durchreise durch Deutschland informiert. Der relevante Passus:

Transitreisende (außer bei Flugreisen) aus Hochinzidenzgebieten und sonstigen Risikogebieten sind unter bestimmten Umständen von der Testpflicht ausgenommen. Hierzu gehört der Transit ohne Zwischenaufenthalt durch ein Risikogebiet vor Einreise nach Deutschland wie auch der Transit durch Deutschland auf schnellstem Weg. Für die Einreise aus Virusvariantengebiet bestehen grundsätzlich keine Ausnahmen für den Nachweis eines negativen Testergebnisses bei Einreise.

Sind die Niederlande ein sogenanntes Virusvariantengebiet, wie es Tirol war? Laut dem Robert-Koch-Institut derzeit nicht, doch ich werde diese Seite im Auge behalten.

Weiters:

Die Pflicht zur häuslichen Absonderung besteht nicht bei Transitaufenthalten. Sie sind in diesem Falle allerdings verpflichtet, Deutschland unmittelbar zu verlassen.

Als hätte ich je etwas anderes vorgehabt.

Und was ist mit der Einreiseanmeldung in Deutschland? Die Seite ist hier nicht eindeutig, doch an anderer Stelle ist es klarer: Unter dem Punkt “Wann muss ich meine Daten nicht angeben?” steht unter anderem:

wenn Sie nur zur Durchreise in die Bundesrepublik Deutschland einreisen und die Bundesrepublik Deutschland auf schnellstem Wege wieder verlassen, um die Durchreise abzuschließen, […]

Das bedeutet, dass ich bei der Durchreise durch Deutschland weder ein Testergebnis mitführen, in Quarantäne gehen, noch eine Einreiseanmeldung ausfüllen muss.

Und wie schaut’s in Österreich aus? Laut dieser Seite muss ich eine Einreiseerklärung ausfüllen, mit der ich mich dazu verpflichte, für mindestens fünf Tage in Quarantäne zu gehen. Ein Testergebnis brauche ich bei der Einreise nicht zwingend, muss dann aber einen Test bis spätestens 24 Stunden nach meiner Einreise nachholen.

Und warum lasse ich mich nicht schon vor der Abreise in den Niederlanden testen? Ich zitiere die Antwort der offiziellen Seite des niederländischen Gesundheitsministerium auf die Frage “Can I get tested for COVID-19 without symptoms?”:

Without symptoms there is no point in getting tested for COVID-19.

Ah, welch erfrischend klare Antwort.

(Ich hätte mich gerne in den Niederlanden vor der Abreise testen lassen, aber wenn ich dafür einen privates Testlabor bezahlen muss und ohnehin kurz nach meiner Ankunft in Österreich testen gehen kann, dann bevorzuge ich den Test in Österreich.)

So, genug der Corona-Formalitäten.

Im Laufe der folgenden Tage ergab sich sowohl bei Mathilde als auch bei mir immer mehr der Eindruck, dass wir keinen Sinn mehr in der Fortsetzung unseres Aufenthalts in den Niederlanden sehen.

Für mich wäre eine Fortsetzung nur im Falle eines weiteren Wohnungswechsels in Frage gekommen, da ich in unserer aktuellen Wohnung besonders unter der schlechten Isolation (sowohl akustisch als auch thermisch) leide. Wohin jedoch ziehen? Die Seite des Flughafens Schiphol zeigt, dass quasi das gesamte Amsterdamer Stadtgebiet und ein Großteil des Umlands von Flugzeugen überflogen wird. Da sich keine andere von uns besichtigte Wohnungen in Amsterdam durch eine bessere Isolation als die aktuelle ausgezeichnet hat, ist für mich dadurch der Reiz dieser Stadt ver-flogen. Man kann dem Flugzeuglärm fast nur dadurch entkommen, dass man weit entfernt von Amsterdam (und Schiphol) wohnt. Hierfür wäre für mich maximal ein Ort wie Utrecht in Frage gekommen, wo die Mieten nur ca. halb so teuer sind wie in Amsterdam (!) und Amsterdam-Zuid mit dem Zug in wenig mehr als 20 Minuten erreichbar ist (das entspricht in etwa meiner momentanen Reisedauer mit dem Fahrrad zur Universität). Andererseits wäre das dann schon unser dritter Umzug innerhalb eines halben Jahres, der dann in spätestens eineinhalb Jahren schon wieder vom nächsten Umzug gefolgt wäre.

Mathilde hat andere Schmerzpunkte als ich; für sie sind das insbesondere das schlechte Wetter, die suboptimalen Arbeitsbedingungen (Wochenend- und Spätdienste bei gleichzeitig niedrigem Lohn) als wie auch die eher bescheidene Qualität des Essens. Und diese Liste ist bei weitem noch nicht vollständig.

Insofern haben wir am Montag beschlossen, dass wir beide am liebsten so bald wie möglich nach Österreich zurückkehren möchten. Ich habe mich am Tag nach unserem großen Kriegsrat beim FWF gemeldet, um mich nach der Möglichkeit einer Fortsetzung meiner Forschung in Österreich zu erkundigen. Am Mittwoch erhielt ich eine sehr nette Antwort, in der mir erklärt wurde, dass ich zwar aus steuerlichen Gründen während meines Auslandsaufenthalts tatsächlich in den Niederlanden leben muss, jedoch schon vorzeitig meine einjährige Rückkehrphase in Österreich antreten und bis zu drei Monate meines Auslandsaufenthalts in die Rückkehrphase umwidmen könnte. Das bedeutet, dass sich mein Forschungsprojekt von drei auf ca. zwei Jahre verkürzen würde. Das ist zwar schade, aber dennoch kein Beinbruch, da ich die für mich interessantesten Teile meines Projekts vermutlich in dieser Zeit fertigstellen kann. Da unsere Rückkehr nach Österreich dennoch einiges an Vorbereitung erfordert, gehe ich davon aus, dass unser eigentlicher Umzug erst so im Juni stattfinden wird.

Seit wir diese Entscheidung getroffen haben, fühlen wir uns beide deutlich besser. Wir haben so viele schöne Rückmeldungen von Freunden und Verwandten bekommen, die sich über unsere geplante Rückkehr nach Tirol freuen, dass wir uns noch mehr darauf freuen.

Am Samstag habe ich erfahren, dass mein Artikel bei der Konferenz, bei der ich ihn eingereicht habe, leider nicht akzeptiert wurde. Bitter, aber ich kann ihn glücklicherweise in Kürze bei einer anderen Konferenz einreichen, wo er thematisch fast noch besser hinpasst. Die nächste Zeit werde ich damit beschäftigt sein, die Kommentare der Gutachter in den Artikel einzuarbeiten.