I wonder when Firefox is going to add a configuration menu for keybinds.

all of these are different ways to say “firefox account”?

Basically yes. The idea is that each suffix represents something that's typically a separate word in English, and you can mix and match suffixes just as you'd mix words.

• my account -> tilini
• to an account -> tilille
• to my account -> tililleni
• to my account too -> tilillenikin

As a Finnish speaker, I just can't see generic localisation systems like Fluent working with agglutinative languages. For instance, consider the Polish example for Firefox Account from Fluent's front page:

-sync-brand-name = {$case ->
   *[nominative] Konto Firefox
    [genitive] Konta Firefox
    [accusative] Kontem Firefox
}

In Finnish, this would be called Firefox-tili. Tili means account and belongs to the Kotus type 5 words, which specifies how the word is inflected with various suffixes. Fluent doesn't support agglutination, so you'd have to specify every form of the word separately:

-sync-brand-name = {$case ->
    [nominative] Firefox-tili
    [partitive] Firefox-tiliä
    ... 10ish more inflections
    [nominative first person] Firefox-tilini
    [partitive first person] Firefox-tiliäni
    ... 10ish more inflections
    ... the above inflections but for 2nd and 3rd persons
    [nominative first person plural] Firefox-tilimme
    [partitive first person plural] Firefox-tiliämme
    ... 10ish more inflections
    ... the above inflections but for 2nd and 3rd persons plural
    [nominative first person questioning] Firefox-tilinikö
    [no idea what this is even called] Firefox-tilittömänäkin
    [no idea what this is even called 2] Firefox-tililleensäkään
    ... lots more
}

Ideally, you'd only specify that Firefox-tili is a type 5 word and the system generates all of that boilerplate.

Teams does actually have a sound cue when people join calls: high-pitched repeated beeps that most people can't hear due to presbycusis, and the few who do hear it think they're going crazy.

Related reddit thread.

Regular expressions are great and can always be matched in linear time with respect to the input string length.

The problem is that JS standard library RegExps aren't actually regular expressions, but rather a much broader language, which is impossible to implement efficiently. If RegExp switched to proper regular expressions, they would match much faster but supporting backreferences like /(.*)x\1/ would be impossible.

I appreciate that the talk focuses more on automated approaches to safety this time. I feel the past years' talks were much more focused on goading developers to follow core guidelines, which doesn't really work in industry.

It would be much easier to read if it was actually table, i.e., if hex codes and the characters were separated into their own columns.

My workplace has the opposite problem.

The company has been in dire need of programmers for years, so they hired people (including myself) without tests. However, the work involves lots of custom iterators and the occasional handcrafted parser, which most of the company is incapable of writing. The bright side is that management has their metrics mostly right, so I'm getting lots of raises for solving fun problems.

The author wanted "a more powerful type of inference that can actually infer the whole type of a function by analyzing the body of the function", which Rust doesn't have by design.

In C++23, you can zip the two arrays, so there's no need to declare an otherwise useless index variable:

int stdSumOfValidDataPoints(const MyData& data)
{
    using namespace std;
    auto&& r = ranges::views::zip_transform(
        [](int data, bool valid){return data * valid;},
        data.dataPoint,
        data.dataPointIsValid
    );
    return accumulate(begin(r), end(r), 0);
}

Unfortunately, the current implementation of zip_transform in GCC doesn't understand that the output length is constant 8, so it does needless cmps every iteration to check if it should stop iterating. (Godbolt)

In languages with static and convenient type systems, I try to instead encode units as types. With clever C++ templating, you can even get implicit conversions (e.g. second -> hour) and compound types (e.g. meter and second types also generate m/s, m/s^2 and so on).

Similar problems (and more) have been solved long ago by libraries, because the issues aren't specific to music. More importantly, how does utf8 support count as a "horrible edge case" in 2022?