infernu VS proposal-pipeline-operator

Or maybe a sound type system can only be achieved either by limiting JavaScript or with a different language that compiles to JavaScript?

Very constrained. Since "constraints liberate, liberties constrain", as Bjarnason said. Inspired by Golang's minimalism, and Elm's guardrails. For learnability and maintainability. Since discipline doesn't scale (obligatory xkcd: with too much power, and the wrong nudges, all it takes is a moment of laziness/crunch-time to corrupt a strong foundation), and a complex language affords nerd-sniping kinds of puzzles, and bikeshedding and idiomatic analysis-paralysis. Counter-inspired by Haskell. The virtue of functional programming is that it subtracts features that are too-powerful/footguns (compared to OOP), namely: mutation & side-effects. The language designers should take care of and standardize all the idiomacy (natural modes of expression in the language). "Inside every big ugly language there is a small beautiful language trying to come out." -- sinelaw. The language should assume the developer is an unexperienced, lazy, (immediately) forgetful, and habitual creature. As long as software development is done by mere humans. This assumption sets the bar (the worst case), and is a good principle for DX, as well as UX. The constrained nature of the language should allow for quick learning and proficiency. Complexity should lie in the system and domain, not the language. When the language restricts what can be done, it's easier to understand what was done (a smaller space of possibilities reduces ambiguity and increases predictability, which gives speed for everyone, at a small initial learning cost). The language should avoid Pit of Despair programming, and leave the programmer in the Pit of Success: where its rules encourage you to write correct code in the first place. Inspired by Eric Lippert, but also by Rust.

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