You can generalize this with TS's fancy mapped types:

    type Sum<K> = <T> (cases: Pattern<K, T>) => T
    type Pattern<K, T> = {
      [V in keyof K]: K[V] extends any[] ? (...args: K[V]) => T : never
    }

which takes TS very close to ML:

    type Shape = Sum<{
      circle: [number, number, number],
      rectangle: [number, number, number, number]
    }>

    function Circle(x: number, y: number, r: number): Shape {
      return ({ circle }) => circle(x, y, r);
    }

    function Rectangle(x: number, y: number, w: number, h: number): Shape {
      return ({ rectangle }) => rectangle(x, y, w, h);
    }

    function area(shape: Shape): number {
      return shape({
        circle: (x, y, r) => Math.PI * r * r,
        rectangle: (x, y, w, h) => w * h
      });
    }

Faster startup, mouse works as you'd expect in a regular desktop app. Switch panes, tabs, open new tab, scroll panes, resize panes, select ranges, all in the terminal. I know not using the mouse is one of the reasons why one would choose vim, but the mouse really is faster/more intuitive in some situations.

Using a mouse is not faster if you really know how to use vim. I guarantee I can get to any line in any window in any tab faster than it takes for my hand to even reach the mouse. Same for resizing splits, selecting ranges, whatever. It's only more intuitive if you're stuck in a GUI mental model. Disable mouse support and learn to navigate vim just like you learned to edit in vim.

Not trying to come off as confrontational, just my 2¢.

Resizing panes is more intuitive with a mouse imo. Doing it with a command just leaves me guessing and estimating how much to move things.

It should be possible to use something like EasyMotion to resize panes, taking the guesswork out of it and making it as fast or even faster than using the mouse.

Being "stuck in a GUI mental model" means I use IDEs for most development I do instead of vim/emacs (which I guess would be the extreme of being stuck in that model?). At the end of the day using my mouse to open a file doesn't impede my ability to code in the slightest.

I've never understood the almost subtle elitism behind being able to use Vim without a mouse because "moving your hand to the mouse is slow". If a problem is so simple my writing/editing a solution for it is constrained by... the time it takes my hand to move to my mouse... I usually just fire up nano.

It's not about elitism, it's about using the tool you've chosen efficiently.

If I used the IDEs you use, and you suggested to me a way of using them more efficiently, I wouldn't accuse you of elitism. I'd thank you for showing me something new and improving the way I work.

Have you ever witnessed somebody using a mouse to move between form fields? My bet is you at least thought about telling them they can use the tab key. You probably wouldn't expect them to come back with some comment about the subtle elitism behind using the tab key.

If I told them they didn't really know how to use a browser because... they didn't know to use tab to move between fields... I wouldn't be surprised in the slightest if they came back with some comment about the subtle elitism

Ha, fair enough. But that really only shows that my example wasn't great.

If you eat soup with a fork, you don't know how to use silverware. If you drive nails with a ball-peen hammer, you don't know how to use hammers. That's not hammer or silverware elitism.

IMO, using a mouse in vim shows that you don't know vim. You can still get the job done, but why not commit to using the tool as intended?

Have you used a PDF form where the order of the fields is wrong so Tab moves all over the place? I sure have. There is no silver bullet.

Most IDE's have fantastic fuzzy search and go-to-identifier tools you might want to try. I find it much easier to stay concentrated on a change when not needing to hunt files with the mouse.

The mouse features you describe are already available in regular vim; I have been using them since long before NeoVim existed. Are they improved somehow?

I can already use the mouse normally in vim... is it that the configuration is too hard?

For this reason, I think of objects as not equivalent to closures, but rather ML-style functors. I think implementing objects as records with closures as fields is really just a poor man's parameterized module.

It's a view generation library, not a DOM-diffing library. That's like asking how to rotate a subtree in an RB tree library.

> view generation library

If it were simply a view generation library you could use a dom-diffing library to diff it. But React does full lifecycle management in addition to "generation".

The fact that you can't use React along with other libraries in the same space means its a framework.

Is this guy really a former Google employee? Those posts sound like they were written by an elementary school kid.

Looking forward to this. Registration doesn't seem to work yet.

Please add 'monospace' to the font-family declaration. The site looks terrible in Ubuntu.

'monospace' fallback added. Thanks!

This is so cool. I only wish the screen were a little bigger and could show all the colors.

Here's how to make shift-pgup/pgdn work in screen:

    echo "termcapinfo xterm ti@:te@" >> ~/.screenrc

Awesome, I will give this a try, thanks!