DEV Community: Florian Lackner

Things I learned picking up a new language as an adult

Florian Lackner — Tue, 21 Oct 2025 12:33:57 +0000

Since I came to France six months ago, I have made a lot of progress with the French language. What started as nearly incomprehensible stuttering are now full phrases with rich vocabulary and even one little joke here and there. I've made picking up French my personal project, and it brings a lot of joy in my life. Understanding people in more and more contexts is enriching and helps with the struggles every expat experiences being far from home.

I recently stumbled across a talk by Chris Lonsdale from nearly ten years ago, where he talks about his experience learning languages. I highly recommend watching it if you haven't already. It resonated so well with me that it inspired me to write this blog post. He claims anybody can be fluent in a new language in six months. It sounds crazy, but having tried that myself, I believe he is right.

In his presentation, Chris claims that there are five basic principles you can apply and seven simple actions you can perform to boost your language skills massively. I will repeat them here and add my own comments.

The five basic principles

1. Focus on language content that is relevant to you.

I agree with him here. I still have unpleasant memories of high school times were we were forced to study rather obscure books in French, which included weird vocabulary and uninteresting stories. It was hell. It is so much harder to remember irrelevant information than interesting information that it becomes quickly frustrating.

2. Use your new language as a tool to communicate.

I guess the key take-away here is to use a language. If you want to convey some meaning, at least in Europe, you can always fall back to English. This is even possible in France, contrary to popular belief.

But you shouldn't use this escape hatch. Using a language takes practice you'll never get if you're not training. All beginnings will be hard, but ultimately you will progress, and that's what counts. Every little piece of information you communicate is a major win and should be treated as such. Feeling insecure about your level in a language is only going to hold you back.

I did a thought experiment one day to deal with this insecurity: I put myself into the other person's position and imagined a situation where I was talking to a person barely able to speak German (my native language). No matter how badly the person speaks, I would never consider their effort anything less than exactly that: a nice effort. In my opinion, it's remarkable if foreigners know your language, be it only so little. I think that the vast majority of people think of it that way. So why was I even embarrassed in the first place?

3. When you first understand the message, you will unconsciously acquire the language.

NEVER LEARN GRAMMAR. EVER.

In serious terms, you should always focus on the message. The rest follows naturally. Learning grammar is the exact opposite. You focus on the language's syntax by trying to learn and apply logical rules. That's how a computer might try to approach learning a language, but for humans, this is a dead-end.

In fact, have you ever noticed how native speakers of any language do not know grammar rules while applying them correctly 100% of the time? The most extreme example is children. They have never heard of grammar but speak as error-free as their parents. When asking them why they use this or that grammatical construction, they cannot give a better answer than: "Because that's how it is."

I believe that our brain is naturally "optimized" to find and internalize these rules subconsciously. This way, we can apply them with lightning speed and astonishing correctness without even thinking about them.

4. Language learning is physiological training.

This might be new to many. Chris tells the story of a Taiwanese woman who excelled in English in school but utterly failed to understand English spoken by native speakers once confronted with it. The idea is that our ears, i.e., our brains, need to learn to hear foreign sounds.

My favorite example of this is the four types of "tch" sounds in the Bosnian-Croatian-Montenegrin-Serbian language. There are two pairs: č / ć and dž / đ. You can find more information (including hearing samples) here. It is nearly impossible to hear the differences for me, how about you?

The same argument also applies to speaking. It takes muscles to do, and different languages use different movements of these muscles. We can train these movements like athletes do in sports. I witnessed a massive improvement in my ability to say certain French words after a couple of months. Initially, it felt like my tongue was somehow tied to a knot when attempting them. This feeling vanishes more and more every day. And if I think about it in retrospect, it really is similar to the clumsy feeling when picking up a new sport. Or when taking first dance lessons.

5. Psycho-physiological state matters.

This is a no-brainer on the one hand, but on the other hand, it's easy to forget about. If your brain is busy with other things, you won't learn. Especially important is staying relaxed when you don't understand something. It's normal, and being angry about it is as pointless as it is hindering your learning efforts.

The seven actions

1. Listen a lot.

Obvious and still often overlooked. You can basically soak your mind in a language. I think it's not necessary to listen actively all the time. A radio in the background also helps. Your brain will get used to the language this way.

2. Focus on getting the meaning first.

I wholeheartedly agree. Sometimes, I catch myself obsessing over single words and their meaning. While thinking about it, I lose context and I stop understanding most of what is said.

Another aspect is body language. It is actually different in most countries and conveys so much meaning. This is especially visible in Italy, the capital of expressive body language, in my opinion, but it applies everywhere.

And one last thing: We can use things we already know. For example, French shares a lot of its vocabulary with English. I use this a lot to guess the meaning of new words in French, and it works way better than it should.

3. Start mixing.

The call to action here is to be creative. Try new combinations of words, try to invent new expressions, etc. Babies, my great role models in language learning, talk like this.

In my experience, the outcome conveys its meaning while also sounding funny to natives. So, you've basically cracked a joke in a foreign language; congratulations. In essence, whatever works is fine and should be used.

4. Focus on the core.

Chris presents some statistics here. He claims that:

1000 words cover 85% of what you say on a daily basis.

3000 words cover 95% of what you say on a daily basis.

If it is true, this is way less than I thought. Three thousand words does not sound impossible; quite the contrary. And if you can say 95% of what you want to say in your daily life one could argue that you speak the language.

A sub-advice he gives is to focus on your "toolbox" of words. This means phrases like "What is this?" ("Qu'est-ce que c'est ?" in French, believe it or not), "What does this mean?", etc. This gives an excellent foundation and enables you to communicate and learn much quicker because you don't need to leave the language to ask these questions — Big recommendation from me as well.

5. Get yourself a language parent.

Chris uses the word parent to hint that babies learn languages this way. One could also say a mentor. A mentor should be a person that is genuinely interested in you as a person and somebody who helps you to communicate. The goal is a safe environment where you can speak comfortably. He claims this concept is successful as it is used by billions of parents all over the world, and all of their kids are able to speak in the end — A convincing argument for me.

I totally agree with this one. I had several mentors throughout my French adventure, and it is the biggest boost for language learning, in my opinion. One of my mentors was a good French friend with whom I started speaking only in French from the day I moved there.

It was hard initially, but he did not get tired of helping me out when I was looking for words, and my proficiency in French increased noticeably every week. There are many ways to find these mentors: friends, online dating, sports clubs, work colleagues; you name it.

6. Copy the face.

This supposedly makes it easier to copy the native accent. I tried this once in high school to fake a British accent, and it really worked. I have yet to do more experiments, but it's an interesting idea I will pursue further.

7. Directly connect to mental images.

Don't translate from one language into another in your head. Connect the idea, the image, the feeling directly to the word in the new language, like it is connected to the word in your native language.

This is great advice and also one of the many mistakes made by schools over and over. Vocabulary lists are one negative example. They incentivize translating in your head, among other problems they have.

In my experience, it is a habit to translate in the head. The same is true for actively doing the exact opposite. I'm trying to make it a habit to connect the words directly to the ideas they represent, and I'm seeing two benefits:

The respective words started popping into my mind whenever I saw something or thought about an abstract idea.
I started to have a feeling about when which word is appropriate. Many words have very similar meanings, like walking and marching in English. Still, there is a difference; sometimes, you can't use one where you can use the other. I'm sure there is always an explanation / a rule for these cases, but that doesn't help when you're in the middle of saying a sentence. The feeling is instantaneous and almost always right, so go for it.

Conclusion

Chris' talk was eye-opening for me. It put into words better than I ever could many vague feelings I had about language learning in these past couple of months. Of all the tips he gave, I like the one with the mentor best. It has helped me a lot with French while also being very nice from a social perspective. If you take one of the ideas presented here home, make it this one.

Why do we need async/await in JavaScript?

Florian Lackner — Tue, 21 Oct 2025 12:32:19 +0000

First posted here.

Async/await is a major source of confusion in JavaScript. People tend just to add and remove the async and await keywords until the code works (or seems to work). In this article, I want to explain what async/await actually means by developing the concept from vanilla, synchronous JavaScript to asynchronous JavaScript with the async/await syntax sugar. It is my personal take on the subject. I hope some will find it interesting.

Disclaimer: I use Node.js as an example of a JavaScript runtime in this article. However, what's discussed also applies to other runtimes like web browser JS engines. All these environments follow similar architectures.

What problem does it solve?

Suppose you have a function that does some I/O.

function handleRequest() {
  try {
    const data = doDatabaseQuery();
    const fileName = doElasticsearchQuery(data);
    const result = readMyFile(fileName);
    return result;
  } catch (err) {
    return handleError(err);
  }
}

Here we assume that the query functions and the readMyFile function will block the JavaScript code while they perform their I/O. Eventually, it will be done, and we can continue where we left off. They will signal an error by throwing. We handle it with a try/catch block.

Doing database queries or other I/O like network requests or filesystem operations takes a very long time™ compared to running your JavaScript code. This is fine in this example if we look at a single request/response. But web servers usually handle thousands of requests. And then this model breaks. To understand why we have to look at how Node.js runs your JS code.

Node.js has a single-threaded event loop

Node.js runs all your JS code in a single thread. The exact reasoning behind this design choice is fascinating but out of scope for this article. In my opinion, the two most compelling arguments in favor of Node's architecture are:

The other option would be to use concurrent threads. This comes with many complexity hazards like synchronization, deadlocks, etc. In this sense, Node's model is simpler.
It turns out that I/O heavy applications like web servers tend to wait a lot. And by that, I mean a lot. They do nothing else, basically. The heavy lifting usually happens outside the web server, in a database, in elastic search, you name it. The web server just requests the data, waits for it, and glues it together to send it back to the client. So having several threads will not make your code more performant because its performance is not CPU-bound.

However, while JS code runs sequentially, we can still work on many requests simultaneously. For example, you can start your washing machine, dishwasher, and microwave one after another and then wait for them to finish their respective tasks. You can do the same with requests to your database, elastic search, etc.

The big question is: How can we wait without blocking?

Callbacks

So code running in Node is not supposed to stop executing to wait for something external to be done. But we often need to do something after say, a network request was completed. The way this is handled is straightforward: We give the runtime a function to call after it performed our I/O operation with its result. This function is called a callback function. We can see how the example would look like using callbacks.

function handleRequest() {
  doDatabaseQuery(function (err, data) {
    // first callback
    if (err) {
      handle(err);
      return;
    }

    doElasticsearchQuery(data, function (err, fileName) {
      // second callback
      if (err) {
        handleError(err);
        return;
      }

      readMyFile(fileName, function (err, result) {
        // third callback
        if (err) {
          handleError(err);
          return;
        }

        sendToClient(result); // strawman function to send a response to the client
      });
    });
  });
}

The I/O functions take a second argument this time, the callback. Note that we couldn't just return our result in this case. When handleRequest runs it will call doDatabaseQuery and then it will return immediately. The Node.js runtime will later call the callback, which will call doElasticsearchQuery. The callback also returns quickly. It will call only readMyFile with another callback which will finally call sendToClient to finish our request once the file was read. We returned result in the original example. This is impossible with callbacks, so we're using this strawman function sendToClient that sends the response back to the client.

Error handling is explicit in this model. By convention, the first argument of the callback function is an error object. If it is not undefined, something went wrong, and we can handle it in the callback. The second argument is, by convention, the result of the I/O operation. There are other styles, but they all boil down to the same idea: The error is communicated via some error argument to the callback.

This is the way Node.js handles I/O. Many will rightfully argue that the code looks messier than initially. The code tends to get more and more unreadable if the nesting of the callbacks becomes too deep. And error handling makes things even worse. This problem is referred to as callback hell. Several abstractions over callbacks have been developed to deal with this. The most widely used one is called Promise.

Promises

The idea of an asynchronous function not returning its result contributes greatly to the unreadability of callback-spaghetti-code. Promises fix this by letting an asynchronous function return something again. But because asynchronous functions still can't block, it can't be the actual value. Instead, they return a Promise, which can be interpreted as: "I promise that the value will eventually be here." The jargon is: "The promise resolves to the value". So this time, the I/O functions return promises that resolve to their respective values.

Furthermore, promises simplify error handling by splitting the error handling logic from the business logic. Instead of getting the error in the callback, you can register a dedicated error callback, which gets called instead of the normal callback if there is an error.

function handleRequest() {
  const dataPromise = doDatabaseQuery();
  dataPromise.catch(err => handleError(err));

  const fileNamePromise = dataPromise.then(function (data) {
    // first callback
    const fileNamePromise = doElasticsearchQuery(data);
    return fileNamePromise;
  });
  fileNamePromise.catch(err => handleError(err));

  const resultPromise = fileNamePromise.then(function (fileName) {
    // second callback
    const resultPromise = readMyFile(fileName);
    return resultPromise;
  });
  resultPromise.catch(err => handleError(err));

  return resultPromise;
}

The cool thing about promises is that they are designed to be chained. You can add callbacks to a promise chain with then(callback). The result is again a promise that resolves to the return value of the callback given to then(). If the callback returns another Promise, the promise returned by then will not resolve to this other Promise, but the value it resolved to. This enables chaining. And chaining avoids the deep nesting of pure callback approaches. Also, we can return something from handleRequest again. This time it's a Promise that resolves to result.

Chaining also works for errors! You can add an error callback with catch(callback). If an operation fails the closest error callback will be called. This helps a lot in our example because all our error handling code is the same.

We can write our example more elegantly. Firstly, we can eliminate the repetitive error handling and add the error handler only once. Secondly, we can use our I/O functions and the error handler directly as callbacks. This works because, e.g., the first callback in the code snippet takes data and returns a Promise resolving to fileName. This is exactly what doElasticsearchQuery is doing, which is why we can use it directly as an argument to then. We can do similarly for readMyFile and handleError.

function handleRequest() {
  return doDatabaseQuery()
    .then(doElasticsearchQuery)
    .then(readMyFile)
    .catch(handleError);
}

Promises have already helped tremendously in cutting down the complexity of callbacks. However, the resulting code is still a bit weird and not as clear as the synchronous equivalent. This is why async/await (and try/catch in async contexts) has been added to JavaScript!

async/await

async/await is so-called syntax sugar for promises. This means it gets compiled to promises by the JavaScript compiler before executing the code. And remember, promises are callbacks under the hood. Nothing magical about these things. So here is the example written with async/await.

async function handleRequest() {
  try {
    const data = await doDatabaseQuery();
    const fileName = await doElasticsearchQuery(data);
    const result = await readMyFile(fileName);
  } catch (err) {
    handleError(err);
  }
  return result;
}

As you can see, it looks very similar to the initial synchronous example. But actually, it is identical to the Promise version. This means you could replace the Promise version with this code and get the exact same function. Let's look at the differences to the initial synchronous example:

handleRequest became an async function
Use of the await keyword in front of the I/O functions. Even though they return promises, await turns those into the values they resolve to.
We return result directly. However, handleRequest will still return a Promise.

async will turn a function into an async function. This has two effects:

You can use await inside of async functions. Outside of them, you can't.
The return value of an async function is a Promise resolving to the value returned by the async function. Even if you don't explicitly return your async function will return a Promise that resolves to undefined.

await can only be used inside async functions (and JavaScript modules). It takes a Promise and turns it into the value it resolves to. It "waits" for value to be ready.

Furthermore, if there was an error and the Promise had no error callback attached, await will throw the error object that would have been passed as argument to the error callback. This makes error handling with try/catch easy and convenient.

Wrapup

I hope this showed how async/await fits into the I/O story for Node.js and JavaScript in general. It's just syntactic sugar for promises, which are themselves an abstraction over callbacks. This article just touches on the basics, though. I deliberately omitted important pieces of the puzzle, like error handling with promises, to keep it simple.

As a bonus, I will give some async functions and their identical twins implemented with Promises to show how the code is transformed.

async function f(x) {
  return x;
}

function f(x) {
  // resolve returns a promise that calls its callback immediately
  // with the value x. i.e. a promise that is immediately "ready"
  return Promise.resolve(x);
}

async function nothing() {
  // empty body
}

function nothing() {
  return Promise.resolve(undefined);
}

async function myFetch(x) {
  try {
    const data = await fetch(x);
    return data.toString()
  } catch (err) {
    return "fetch error";
  }
}

function myFetch(x) {
  return fetch(x)
    .then(data => data.toString())
    .catch(err => "fetch error");
}

async function parallelFetch(x, y) {
  const promises = [
    fetch(x),
    fetch(y),
  ]);

  // both fetches are being performed simultaneously in the background
  // (outside of the event loop, parallel to this code)

  // new promise that resolves when all given promises have resolved
  const bundlePromise = Promise.all(promises);

  // this will wait until both fetches are done
  const [resultX, resultY] = await bundlePromise;

  return { resultX, resultY };
}

function parallelFetch(x, y) {
  const promises = [
    fetch(x),
    fetch(y),
  ]);

  const bundlePromise = Promise.all(promises);

  return bundlePromise.then(([resultX, resultY]) => {
    return { resultX, resultY };
  });
}

Dates in JS

Florian Lackner — Tue, 21 Oct 2025 07:23:30 +0000

First posted here.

Date and time handling is arguably one of the most complicated things in computer science. It seems simple, since everybody knows how to read a clock or how to use a calendar. But the devil is in the details, as always. Since so many people seem to get it wrong over and over, we should talk about it.

In this blog post I want to offer a mental model to you. It created this famous click moment for me. Maybe it helps you too. Let me know, I'd be delighted.

Terminology

Let's give clearly defined names to the things we'll talk about. The topic is already complicated enough without confusion induced by the ambiguous nature of human language.

A Date is the information you can find on a physical calendar. It's a day, month and year.
A Time is the information you can find on a wall clock. It's an hour, minute and second. You can of course go finer by giving milliseconds etc.
A DateTime is a Date and a Time.
An Instant is a point in time on the planet. If two Instants are the same, this means that they happened at the same moment, physically speaking.
A Timezone is an algorithm to convert an Instant to a DateTime.

The key takeaway

A DateTime is NOT an Instant.

If you take one thing home today, it should be this. A DateTime is NOT an Instant. Neither can you convert between the two losslessly. They are fundamentally different concepts. In my opinion the confusion between the two is the cause of most bugs in date and time handling.

The mental model I'm offering is that these are different things that can't be converted without loss of information. You need to ask yourself every time which of the two you're working with and you can't mix and match them.

Let's use an example to show the difference. Say you're speaking on the phone with a friend who lives on the other side of the planet. Where you live it's maybe the evening, while your friend's about to start their day. Your DateTime is very different from your friend's DateTime. Yet, you're having a conversation at the same Instant in time. Of course, because you're saying something and your friend responds immediately (ignoring the slight delay imposed by the speed of light).

So let's repeat this again. A DateTime is NOT an Instant.

Timezones

Let's take the example further. Say you didn't have your conversation yet. Since you and your friend are both busy, you schedule it. Easy, you agree on an Instant in the future and be done with it. While it's true that you must agree on an Instant, it's unfortunately also true that people don't work on Instants. They work on DateTimes. How impractical. And since your friend lives far away, the DateTimes for the Instant of your call won't be the same.

You need to convert the Instant to a DateTime for each one of you. The algorithm to do so is called a Timezone. I'm saying algorithm, because Timezones are more than just a simple offset. There are complications like daylight saving time, leap seconds, and historical changes in time zones. I'd consider them black box algorithms, because they're complex and there's no shortcut around this fact.

Say you're living in France. Your Timezone is called "Central European Time" (CET) or Europe/Paris. Your friend lives in India. Their Timezone is called "Indian Standard Time" (IST) or Asia/Kolkata. You both agree on an Instant in the future. Then, you need to apply the respective Timezones to the same Instant to get your DateTimes. I've used India as an example, because its Timezone doesn't experience daylight saving time. In France, however, it does. So the way to calculate the DateTimes in each case are very different.

Universal Time Code (UTC)

The keyword "UTC" comes up a lot in discussions around time management. It is the name of a Timezone called "Universal Time Code". It is very often used to communicate Instants between actors in different Timezones. It has a special property that makes it very useful for storing Instants. It doesn't experience daylight saving time. This means that the conversion between Instants and DateTimes becomes reversible. Or in other words: A DateTime in UTC is equivalent to an Instant. You can convert between the two without loss of information.

Storage

So how do you store Instant, DateTime and Timezone ?

Instants can be stored as offset from a known Instant (epoch) in seconds. This is also called a timestamp. A common choice of the epoch is the Instant that corresponds to the DateTime Jan 1st 1970 at midnight in the Timezone UTC. The offset can be in seconds, milliseconds, etc. You can choose the granularity. This storage method is space efficient, since you only need to store one number.

DateTimes can be stored as strings or as Instant in UTC. There are several formats for the string representation. The most common format is the ISO 8601 format. It looks like this: 2023-03-15T12:34:56. This corresponds to March 15th, 2023 at 12:34:56. The Timezone is not specified in this example.

The second storage method is to store DateTimes as Instants in UTC. As already discussed, Instants in UTC map uniquely to DateTimes and vice-versa. This storage method is space efficient, since you only need to store one number. However, it is important to note that it is easy to make mistakes when using this method. You have to be very careful with your conversions.

Timezone values are usually stored as strings. There are standardized names for timezones. You should use these names. They are supported by libraries implementing Timezone.

`DateTime` or `Instant`?

Let's do some examples of when to use which for your information.

The time information of a log entry in a computer system: Instant, because it happens at a specific point in time.

Showing an Instant to a user: DateTime (obtained by applying the users Timezone).

A users birthdate: Date / DateTime , because that's what's written on their official documents.

The timing information of a one-off calendar event in a shared calendar: Instant, because it happens at a specific point in time. The Timezone of one user does not influence the Instant.

The timing information of a recurring calendar event. That's a tricky one. Think of every Monday at 2AM. What happens if the user changes their timezone? What happens on the day the clocks are reset for daylight saving time? Does the event happen twice? In my opinion there's no absolute answer here. It depends on how you want your system to behave. I'd store a DateTime + Timezone. I'd add code to handle the edge cases of the Timezone (using a library of course). And then I'd start praying.

The JS `Date` class

So what does the JS Date class represent? It's JS, so let's not be surprised by the answer: an Instant. Yes, that's the hard truth. And I want to be very clear: There is no Timezone information stored in the Date class. No UTC. It's an Instant. End of story.

But why does it have getters and setters for years, months, days, hours, minutes, and seconds? Because it's badly designed. And what do these return? They convert the Instant to a DateTime in the local Timezone of your user (frontend) or your server (backend). And then they extract the year, month, etc. and return them as numbers.

And here's another hard truth: Your users Timezone might be anything. You can't assume that:

it's correct.
it does / doesn't experience daylight saving time
its offset to UTC is positive / negative
it won't change

You need to code with this in mind.

I think the JS Date class should be avoided for anything related to DateTime. Instead, use one of the established libraries: Moment.js or Day.js. And in the near future, use the successor of Date, the new Temporal API.