Sonata

Great to see this moving forward.

It does seem a bit of a mixed message to enable this by default while still saying the functionality is experimental. I fear many people will take this as a signal to start using the feature in production, then find a later Node.js update breaks things if the behaviour changes.

The approach taken to this problem by Cats Effect (a Scala concurrency library) is interesting. It allows cancellation of a fiber from outside, but let's blocks of code be marked as uncancelable. If a fiber is cancelled while executing one of these blocks, it will complete the block before cancelling. This protects against cancellation in between two operations which leaves the program in a broken state.

The drawback of this approach is that the onus is on anybody writing code which might be cancelled to correctly mark the uncancelable regions.

As long as they don't make them mutable!

Nice to see some Scala content on HN.

Hope he finishes the book.

Here a common example:

Given the following tables:

  CREATE TABLE person (
    id INT PRIMARY KEY,
    name VARCHAR NOT NULL
  );

  CREATE TABLE pet (
    id INT PRIMARY KEY,
    name VARCHAR NOT NULL,
    owner_id INT NOT NULL
  );

It is common to want to join them, like so:

  SELECT owner.id, owner.name, COUNT(pet.id) AS numberOfPets 
  FROM person AS owner
  LEFT OUTER JOIN pet ON owner.id = pet.owner_id
  GROUP BY owner.id

This doesn't work in standard SQL, because all columns in the SELECT list have to either be aggregated or included in the GROUP BY. owner.name is neither. That is a bit silly though because we know each result row will only have one unambiguous value for the owner name, since the GROUP BY is on a unique column from the same table as the owner name.

We can solve this with ANY_VALUE:

  SELECT owner.id, ANY_VALUE(owner.name) AS name, COUNT(pet.id) AS numberOfPets 
  FROM person AS owner
  LEFT OUTER JOIN pet ON owner.id = pet.owner_id
  GROUP BY owner.id

Youth culture is alive and well.

And as for music subcultures, I'm a fan of several genres which have distinctive fashions, art styles and world views - rave, psytrance, drum and bass, hardcore punk, metal. It's great to go along to gigs and meet people from those different groups.

I think what has changed is that those subcultures are no longer exclusive to young people. It has become more acceptable for people to be outwardly "alternative" later in life, so people remain in the cultures they found when they were young.

I'm glad people are working on this problem. Typescript's compiler performance is certainly a weakness.

Other commenters have rightly called out the complexity of the type system as the reason why this is difficult. The other reason is that Typescript does not have a formal specification. The tsc compiler is the only reference for the correct behaviour. It would be great if the official compiler and these reimplementations could share a common test suite to ensure compatibility.

Interesting. I'm not aware of any other lazy dynamic languages. I would assume it is difficult to optimise such a combination.

Having a good knowledge of HTTP is useful in many different contexts.

- The correct semantics for each HTTP method

- What different status codes indicate

- Common headers, particularly around caching

- HTTP 1.1 vs HTTP 2

- Common authentication protocols - OAuth 2.0, JWTs, etc.

The important thing is that it separates the order of side-effects from the order of evaluation of expressions. This isn't a particularly important distinction in an imperative language, but in a functional language when you introduce things like laziness and memoization, the order in which expressions will be evaluated is not obvious.

Because pure I/O preserves referential transparency, it gives the compiler far more ability the optimize the code by changing how, when and whether things are evaluated, while still being able to prove that it has not modified the external behaviour of the program.

Haskell doesn't use pure I/O out of zealotry - without it, Haskell couldn't and be lazy-by-default and the compiled code would probably be much slower.

This sounds similar to how Cloudflare Workers work - using the V8 isolate technology built for Chrome to provide secure isolation of backend processes without the overhead of VMs or even containers.