The types allow you to very narrowly define functions so that you can, for example, require that a NonEmptyArray be passed. This helps to fulfill that requirement without casts.
As a Python person, that 2nd one looks like a bug. Expecting an exception there. Although also Python doesn't have an `undefined`; `None` would have to suffice.
Not really. If you try to take something from an empty container (language or real life) then you should get an error/issue. The container type doesn't change when it's empty, and the operation is just senseless; all that's happening here is added mental gymnastics that makes code unintuitive to read. Checking if/asserting a container isn't empty is a straight forward `if cont: ...` or `assert cont` in Python, which anyone can just get.
Right, you can attempt to take and potentially error, but if you already know that taking is possible you can skip the noise and simply return a result. Checking if your container is empty every time you remove an item is not free.
The type soft-enforces₁ it immediately for everyone though.
Without 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.
part of it is because js is a throwing language, and since there are no "checked" exceptions they need to basically rebuild the universe in their paradigm.
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.
Petty aside: Several JS people I know who were previously quite down on using a dependency injection framework are now seeing the benefits after adopting Effect. The most egregious example being a colleague who considered the adaption of DI tooling to be a language-level defect. It’s now one of his primary selling points for Effect.
i wouldn't consider the opinions of people who consider themselves "js people" to be particularly interesting, considering the ultimate state of that ecosystem. i say that as someone who writes js professionally.
you dont need an entire runtime to implement polymorphic console.logging. tbh the fact they want to implement the world to do this is more of an inditement against this approach than anything else
It isn't a case of wanting to implement the world to do this though.
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?"
Not playing devil's advocate or anything, but effect systems go beyond DI: it's not just about passing around a capability, but managing its lifecycle in a referentially transparent manner, i.e. monads all the way down. It's a real pain, but they set themselves up to bear the burden, so, good for the rest of us I guess?
claude-ai · · focus · HN ↗
slopinthebag · · focus · HN ↗
nvme0n1p1 · · focus · HN ↗
Rebuild JS's core data structures: <a href="https://effect.website/docs/v4/api/effect/Array" rel="nofollow">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.
maleldil · · focus · HN ↗
> Works with JavaScript arrays
nvme0n1p1 · · focus · HN ↗
slopinthebag · · focus · HN ↗
"Use when you need to guarantee a non-empty result after adding a required trailing value."
...whatever that means lol
spaethnl · · focus · HN ↗
itishappy · · focus · HN ↗
skeledrew · · focus · HN ↗
spaethnl · · focus · HN ↗
skeledrew · · focus · HN ↗
itishappy · · focus · HN ↗
spaethnl · · focus · HN ↗
Without 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 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.itishappy · · focus · HN ↗
slopinthebag · · focus · HN ↗
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
spaethnl · · focus · HN ↗
bbg2401 · · focus · HN ↗
slopinthebag · · focus · HN ↗
slopinthebag · · focus · HN ↗
spaethnl · · focus · HN ↗
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?"
itishappy · · focus · HN ↗
Console is IO and IO is the effect.
slopinthebag · · focus · HN ↗
ezst · · focus · HN ↗