polysemy VS purescript

Thirdly, composing arbitrary effects without losing state is really, really difficult. Things are fine when you limit yourself to State and Reader, sure, but once you start with nondeterminism you’ll discover it’s shockingly easy to produce behaviors that are baffling unless you’ve spent a preposterous amount of time thinking about this stuff. (I’ve been bitten in prod by silent state-dropping bugs, and rarely have I been more flummoxed.) Consider this example, which produces silent changes in the semantics of <|> depending on whether you use it inside or outside of a higher-order effect. Every single effect library (besides the still-unreleased eff) gets certain combinations of effects + nondeterminism wrong. You could make the argument that most people don’t use nondeterministic monads, but eDSLs really shine when you have access to them, as you can turn a concrete interpreter to an abstract one fairly easily.

Looking for a few projects that make use of it, I found accelerate, hawk, polysemy and pretty-simple, so I'll be interested to poke around in their code and see how they have things set up.

Right, I think I'll just give it a shot to see. Polysemy is nice but I'm still having trouble getting what I want out of it (which may very well be entirely a fault of my own understanding)

Languages such as Koka only support algebraic effects, not scoping operations such as catch and listen. The Effect Handlers in Scope paper introduces scoping operations, which lead to the Haskell libraries fused-effects and polysemy, but they turned out to have some weird semantics. eff is her effort to fix that.

Looking at the interpreter for Reader might give some clues if this doesn't work. https://github.com/polysemy-research/polysemy/blob/master/src/Polysemy/Reader.hs#L38-L45

*But I'm not terribly well versed in Scala's other DI offerings. I came from Haskell and didn't find anything in Scala that clicked with me until I found ZIO. It reminded me a lot of my favorite way of writing Haskell programs (https://github.com/polysemy-research/polysemy)—albeit with a completely different implementation.

When I see this it makes me want to run for ReasonML/ReScript/Elm/PureScript.

Sum types (without payloads on the instances they are effectively enums) should not require a evening filling ceremonial dance event to define.

https://reasonml.github.io/

https://rescript-lang.org/

https://elm-lang.org/

https://www.purescript.org/

(any I forgot?)

It's nice that TS is a strict super set of JS... But that's about the only reason TS is nice. Apart from that the "being a strict super set" hampers TS is a million and one ways.

To my JS is too broken to fix with a strict super set.

A web application makes use of these same ingredients, i.e. HTML, CSS, and JavaScript, but it uses significantly more JavaScript. As the JavaScript powering your web application grows in size it can bring with it a variety of problems that a few languages, like TypeScript, ReScript, PureScript, and Elm, have attempted to solve. Each of the aforementioned compile to JavaScript languages have their pros and cons but it is beyond the scope of this article to get into those details. Suffice it to say, my preference is Elm. It is also not the goal of this article to convince you to use Elm but only to show you how Elm fits into the flow of creating a web application and hosting it on GitHub Pages. So let's continue by adding Elm to our project.

Naturally I’d recommend using a better language such as ReScript or Elm or PureScript or F#‘s Fable + Elmish, but “React” is the king right now and people perceive TypeScript as “less risky” for jobs/hiring, so here we are.

Unless you want to switch to https://www.purescript.org/.

PureScript[1][2] seems pretty alive these days. From my relatively small, self-contained experiments, it's a lot more flexible and expressive than Elm at the expense of (maybe?) being a bit harder to learn up-front.

[1]: https://www.purescript.org/

[2]:https://github.com/purescript/purescript