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.
This is correct, though the inline feature does also unlock some optimizations. For instance, see this example from the docs where a recursive method is optimized to a few sequential commands when some of its parameters are constants:
I think the Scala 3 book [1] might be what you're looking for!
There's also an ongoing video series called "Let's talk about Scala 3" by the Scala Center and 47 Degrees [2], which are more in-depth on certain topics, but still quite beginner-friendly. Especially the video on setting up a development environment, and the video on Scala 3's data structures might be good introductions.
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.
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.
The trackpad didn't work out of the box, I had to change some settings; annoying, but no big deal. What's a bigger problem is that the trackpad buttons don't work after suspending/hibernating, and I still haven't been able to fix that. Also, the fingerprint reader and NFC do not have any drivers on Linux.
The Arch wiki page[1] has been tremendously helpful in getting set up. However, I think the length of the article goes some way toward showing that compatibility is far from perfect.
The trackpad / NFC issues seem to only be present on laptops with NFC behind the trackpad, so my recommendation would be to avoid that one if it's possible to get a similar model without.
I recently switched to a X1C6, and I wholly agree. It's an amazing laptop in terms of hardware and build quality, but it does have a bunch of Linux compatibility problems.
For finger tracking, version 1 used random forests [1], because of the performance/hardware budget trade-off: they're harder to train than a traditional deep learning algorithm, but are much more efficient to compute on the device (branching being basically free on a CPU).
Version 2 uses a deep learning accelerator [2], which makes it possible to do the heavier computation of DNNs (which involve floating-point operations, which would be much more expensive on the CPU).
From an engineering perspective, I just love seeing how it touches all abstraction layers of the stack, and the types of solutions that come out of thinking about the silicon and the high-level ML models at the same time.
That's pretty nice. For people looking for an alternative with the same convenience as Medium, converting the archive of Medium posts to a GitHub Pages site could be a decent solution.
Not only that, but it's another Facebook project moving from Flow to Typescript. Jest also announced a Typescript migration last week: https://github.com/facebook/jest/pull/7554