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.

Yes! See the redesigned implicits [1] and macros [2].

[1] https://dotty.epfl.ch/docs/reference/contextual/motivation.h...

[2] https://dotty.epfl.ch/docs/reference/dropped-features/macros...

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.

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:

http://dotty.epfl.ch/docs/reference/metaprogramming/inline.h...

This effectively makes it possible to have a limited form of partial evaluation.

Indeed, the blog post is up now! https://scala-lang.org/blog/2021/05/14/scala3-is-here.html

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.

[1] https://docs.scala-lang.org/scala3/book/introduction.html [2]: https://www.youtube.com/watch?v=j-H6LSv2z_8&list=PLTx-VKTe8y...

And that's why you should always use a different domain for your status pages! GitHub does it well, for instance: https://www.githubstatus.com/

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.

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.

[1] https://wiki.archlinux.org/index.php/Lenovo_ThinkPad_X1_Carb...

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.

The assignment of these could go either way, depending on what you prefer :)

Yes. I'm referring to the original HoloLens and HoloLens 2, so to the hardware versions.

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.

[1] https://www.microsoft.com/en-us/research/wp-content/uploads/...

[2] https://homes.cs.washington.edu/~kklebeck/lebeck-tech18.pdf

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

Show me a Typescript codebase not using the type 'any'! In a decent system language you can't get away with that, it's just a fake sense of security.

I don't know the comparison to system languages is fair though, because the use-case for JS is quite different from system languages.

Javascript (and by extension, Typescript) is commonly used to interface between the user and the network, both of which often are outside the bounds of the type system. Add to that any code that interfaces with plain JS, such as external libraries or legacy code. When dealing with those, it's natural to use statically untyped values and type ascriptions based on reasonable assumptions.

Taking that into account, I actually think Typescript's type system is fairly well-designed for the use-case. The problem isn't really with Typescript, it's just intrinsic to the use-case of JS.

Here's the video of the author presenting the extension at the Chrome Dev Summit keynote: https://youtu.be/zPHyxvPT0gg?t=1424

I just tried it on Windows 10, and the error message is:

    This file name is reserved for use by Windows. Choose another name and try again.

It looks like zsh with the Oh My Zsh [1] with the Agnoster theme [2].

1. https://ohmyz.sh/

2. https://github.com/robbyrussell/oh-my-zsh/wiki/Themes#agnost...

I wrote it in Scala below; it's a bit shorter, and I really like the map(base). Getting the digits from a number turns out to be most of the work, and the int->string->int conversion also seems to be the best approach.

  val base = List("noa", "taha", "ua", "tolu", "fa", "nima", "ono", "fitu", "valu", "hiva")
  def tongan(n: Int) = n.toString.map(_.asDigit).map(base).mkString(" ")

jxub called it on the Dropbox Foundation thread 2 days ago

https://news.ycombinator.com/item?id=16428729

lit-html is relatively short and well documented.

https://github.com/PolymerLabs/lit-html

If you're using Promise.all to run code in parallel, then async await can't really replace that, as far as I know. But you can still use `await Promise.all(...)`, which will free you from having callbacks everywhere; running parallel code will no longer have to look so different from running it sequentially, which is quite nice.

If you're just rewriting these Promises because the syntax is too verbose, you might be interested in checking out async/await as another alternative; I just rewrote some Promises to that recently, and it's really, really nice. Of course, if you prefer RX Observables, go right ahead :)

I'm currently studying at the EPFL (one of the two Swiss Federal Institutes of Technology) and fees are actually almost half the amount you state -- I pay around 1250$ a year.