proposal-pipeline-operator VS dune

Current Status: You'd have to check the TC39 proposals repository or the official proposal text for the most recent status. As of my last update, it had not yet reached Stage 4 (final stage) of the TC39 process, which means it wasn't part of the ECMAScript specification yet.

Javascript may get it https://github.com/tc39/proposal-pipeline-operator https://youtu.be/dQw4w9WgXcQ

It can be further simplified. For example, you don't need two separate functions to extract the first chat completion message etc.

This version:

- uses existing language constructs

- can be immediately understood even by the most junior devs

- is likely to be 1000 times faster

- does not rely on an external dependency that currently has 143 issues and every two weeks releases a new version adding dozens of new methods to things

Note: one thing I do wish Javascript adopted is pipes: https://github.com/tc39/proposal-pipeline-operator

Still in stage 2 atm https://github.com/tc39/proposal-pipeline-operator

Both are active tc39 proposals :)

https://github.com/tc39/proposal-pipeline-operator - Stage 2

https://github.com/tc39/proposal-pattern-matching - Stage 1

Hopefully we get both in the next couple of years.

Some time ago I saw how hyped JS community was about pipeline operator proposal. So I tried to make something similar in python. There is how tipe module was created. Check it out if you are interested: https://github.com/mishankov/tipe

We often add promising TC39 proposals into Civet so people can experiment without waiting.

We've added https://github.com/tc39/proposal-pipeline-operator, a variant of https://github.com/tc39/proposal-pattern-matching, a variant of https://github.com/tc39/proposal-string-dedent and others.

Since our goal is to be 99% compatible with ES we'll need to accommodate any proposals that become standard and pick up anything TC39 leaves on the table (rest parameters in any position, etc.)

The Proposal is for the Hack pipe, so your example would be

If you are using the dune build system, add the tag(s) to your dune-project file's package stanza. E.g.:

One way to get around this is to modify the api/dune file with (include_subdirs qualified); this means that every subdirectory of api/ can be referenced by module namespacing and we don't have to write dune files for every route (or pages) folder. However, the OCaml LSP does not like it and red squiggles will show up in the editor (although the app with still compile without errors). Trying to develop the app knowing those red squiggles cannot be vanquished would drive me nuts, so instead of using (include_subdirs qualified) I just wrote dune files for every route (and page) which gets rid of the red squiggles.

2) Neither would having all source/targets specified, as that would entail listing them all in the dune file as wildcard rules is apparently still not a thing: https://github.com/ocaml/dune/issues/307

There is a small example on the dune home page: https://dune.build/

Dune (https://dune.build/) is the preeminent build tool for OCaml development. I don't love its input syntax (s-expressions), and I sometimes miss the ability to write high-level functions to reduce boilerplate (especially for unit tests), but it always gets the dependencies right, and it's fast. This is in stark contrast to some of my experiences with various other build systems, and I am super happy that the default option for OCaml build systems is so good.

It's still weird because dune's own site only makes Jane Street references: https://dune.build/.

ONE of the big benefits of OCaml is its powerful REPL (also called the toplevel), the interactive command-line utility where you can load modules, type in and execute code, and see its results. The modern REPL, utop, has powerful auto-completion and integration with the build system dune, which enables productive workflows like loading an entire project's libraries in the REPL and interactively exploring them.