Rebuild JS's core data structures: https://effect.website/docs/v4/api/effect/Array
Then rebuild the entire JS ecosystem on top of their custom data structures.
And then the main heading on their home page is "Reliable TypeScript for the AI era"? Really? I'll pass.
> Works with JavaScript arrays
a = [1, 2, 3];
foo = effect.Array.append(a, 4);
instead of using what's built in to the language? a = [1, 2, 3];
foo = [...a, 4];"Use when you need to guarantee a non-empty result after adding a required trailing value."
...whatever that means lol
a = [undefined];
res = a.pop() // undefined
a = [];
res = a.pop() // undefinedWithout the type there are a few possibilities: 1. I could forget the assertion and have buggy code without realizing. 2. I could ensure that all uses do the assertion. Even if we can statically know that it is empty. This costs us the check for every call of the function, and ends up being more code.
Alternatively I could statically know in advance. The code won't let me `Array.pop` because that is invalid, so:
1. I *cannot* make that mistake
2. It cost no runtime performance
3. It cost no extra code in a function
1: I say soft-enforce because if someone were to pass a value incorrectly cast as NonEmpty, it would still have a runtime error, but that is a bug elsewhere, not here.but they seem to want to rebuild everything, eg
> The Console service exposes common console methods such as logging, warnings, errors, groups, counters, tables, and timers. Because console access goes through a service, programs can use custom console implementations in tests or other environments. This module also includes scoped helpers that close console groups or timers automatically.
yeah idk mate
Instead, it is a case of the active users of the library saying, "Wow, the Effect way of doing this is so much nicer, can we have everything this way please?"
Console is IO and IO is the effect.