zeugmasyllepsis

I plan to look into this deeper today, but truth be told I saw the little animation at the top of the page and paused.

Throwing the ball and watching this little character run was truly a delightful interaction. For whatever part you had in its creation, thank you.

I was curious about node/jitless node versus python/pypy:

      src time node primes.js             
    78498
    node primes.js  1.75s user 0.05s system 102% cpu 1.761 total
      src time node --jitless primes.js
    78498
    node --jitless primes.js  5.06s user 0.04s system 100% cpu 5.088 total
      src time python primes.py
    78498
    python primes.py  4.27s user 0.03s system 100% cpu 4.276 total
      src asdf shell python pypy3.9-7.3.9
      src time python primes.py
    78498
    python primes.py  0.91s user 0.07s system 100% cpu 0.970 total

Actually relatively on par with one another.

Playing around in a docker image of the beta build, it looks like this allows you to add a `unique nulls not distinct` constraint to a composite set of fields, but still does not allow you to specify those same fields a primary key. For example

    -- This works
    alter table announcement_destinations
        add constraint announcement_destinations_pk unique nulls not distinct (sender, receiving_group, optional_filter);

but

    -- Still does not work
    alter table announcement_destinations
        add constraint announcement_destinations_pk2 primary key (sender, receiving_group, optional_filter);

fails with a message like "ERROR: column "optional_filter" of relation "announcement_destinations" contains null values". Is there a motivation for this distinction?

Curious, what is your argument in favor of a container over a type union to represent Result? As long as the type checking system forces users to refine the union to use the value and is aware of blocks of code within type guards (I've heard this referred to as "flow-aware typing" but I'm not sure if that's a standard term) then the advantage of an explicit Result type isn't very obvious to me. What am I missing?

Smalltalk

This might work out well in practice when tracking a single effect with a monad (e.g. with Haskell's `do` notation) but I think it quickly falls apart when working with multiple effects. Monads don't have a general form of composition - at the very least the order that they're composed matters to the outcome of the program. Procedural code is generally flexible enough to allow you to mix-and-match how effects gets handled, which I think would be difficult and impractical to work out in monadic contexts.

> Real number counting is a bit more loose. To find the numbers between .1 and .2, you find all fractionals of a given size, normally 1/10.

Unfortunately the fractionals method does not work, since there are numbers (in fact, uncountably infinitely many!) irrational numbers which cannot be expressed as fractions, which are nonetheless real numbers (such as the square root of two and pi).

Go supports a handful of built-in generic types, like hashmaps. What Go currently lacks is user-defined generics, though that is actively being worked on.

Thank you for providing details and not just assuming the JIT was the cause of the difference.

Right - so if you're introducing type annotations into an existing project and have a method expecting some interface, used by many call-sites spread across various parts of the project, then you can go around wrapping the original type at each call-site as you've indicated.

Or add a single type annotations to the method declaring that the parameter satisfies a protocol.

Not without modifying the existing type. Since Interfaces rely on nominal typing, each type implementing an interface must explicitly declare that they do so. On the other hand, since Protocols are checked structurally you can declare a protocol after several types already implement it, and type checking will pass without having to modify the implementing types.

Sum and intersection types + pattern matching feels so natural in languages like F#, OCaml, Reason, and Elixir. I know they add a significant amount of complexity to the language, but the more I use them, the more I feel that the tradeoff lands in the goldilocks "just right" zone. I find myself missing them often.

> static type checking based on sequent calculus, one of the most powerful systems for typing in

Not exactly a common characteristic for Lisps