kjaer

This made me smile :)

  if (looping.mode === "off") {
    // If you waited for a day, you deserve to see this workaround...
    // Since there is no way to not loop a gif using gifwrap,
    // let's just put a reeeeaaaaallly long delay after the last frame.
    return 8640000;
  }

Though they share the word "algebraic", algebraic data types != algebraic effects. And while Java has good support for concurrency primitives and concurrent data structures, it does suffer from the problem highlighted in the article:

> Over time, the runtime system itself tends to become a complex, monolithic piece of software, with extensive use of locks, condition variables, timers, thread pools, and other arcana.

I'm not an expert on this, but my understanding is that the problem that algebraic effects tries to solve is to improve language semantics to make it easier to separate different levels of abstraction (e.g. separating the what from the how), while also encoding the performed effects into the type system.

Scala Native and GraalVM Native Image are projects with different goals, so I wouldn't say that one makes the other unnecessary.

Both projects aim to compile to native code, and have use-cases for projects where the JVM startup time is too high. However, one of the main goals of Native Image is to offer as much partial evaluation (PE) at compile-time as possible. Scala Native does also seem to do some PE, but my understanding is that it's less than what Native Image does. However, Scala Native has the advantage of working on a representation of the source code instead of the byte code, and may therefore be able to do certain Scala-specific optimizations that would be more difficult for Native Image.

I think different projects may find that either one or the other project may be more suitable to their needs, so I think both projects can coexist.

Graal Native takes JVM bytecode as input, and Scala 3 is binary compatible with Scala 2, so it should be compatible with Graal Native out of the box.

Luckily, these commits came in before the bump to 3.0.0! The second one, at least, seems to have been in preparation for the stable release.

People are more likely to already have npm installed and to be familiar with it. So there's an argument to be made that all else being equal, picking npm lowers the barrier to entry for new contributors. This consideration could be especially important for open source projects.

With the addition of workspaces and yarn.lock support to npm 7, are there still reasons to use yarn over npm?

I don't know if this actually helps Google show more ads. With a 30k rule limit, I'm imagining most adblockers will prioritize the most common ad domains, and I'm pretty sure Google would be at the top of that list. This may really be a win for the long tail of smaller ad networks rather than the bigger players.