Strong arrows: a new approach to gradual typing
elixir-lang.org
Strong arrows: a new approach to gradual typing
1–10 of 87 posts
Re: Strong arrows: a new approach to gradual typing
#2Slightly OT (though I do really like Elixir: I used to work with José and he’s a goddamned visionary): TypeScript just hits it out of the park here. With arguably harder erasure constraints than either Java or C# the covariance and contravariance bounds and ergonomics are so much more intuitive than either. The MSR brain trust is clearly keeping their eye on the ball.
Elixir looks to be one of few languages that is never going to sit still on absorbing the best ideas. At the risk of repetition, no one would expect less from the person who’s passion created it.
Re: Strong arrows: a new approach to gradual typing
#3I cannot support much in terms of money or time currently, but somehow I'd wish there are ways to speed this up.
Sure, sponsoring from big corps comes with their own problems, but maybe that would be an option? There are quite some that use Elixir (or BEAM in general) out there...
Idk what would be the best approach.
But I am very convinced that Elixir and the wider ecosystem (not only phoenix liveview) is (or could be) the very best "default" web app stack we have right now in general. It solves _so many_ problems of other comparable tech stacks right out of the box, one way or the other, and is the only one I've noticed a sentiment of pure joy from seasoned devs that also lasts well after the novelty wears off.
At this point it looks "only" like a number problem to become mainstream (again a number problem). No idea how to solve it, just felt I needed to share my thoughts as a data point here.
Like the type system here: I'd _kill_ to have this exact implementation today rather than _maybe in a few years_. And yes, I can draw comparison to Typescript, Rust and Haskell which I used for projects in the past. Its like combining the very beast ideas (and adding some more) into one awesome thing.
Re: Strong arrows: a new approach to gradual typing
#4I cannot support much in terms of money or time currently, but somehow I'd wish there are ways to speed this up. Sure, sponsoring from big corps comes with their own problems, but maybe that would be an option? There are quite some that use Elixir (or BEAM in general) out there... Idk what would be the best approach. But I am very convinced that Elixir and the wider ecosystem (not only phoenix liveview) is (or could…
> It solves _so many_ problems of other comparable tech stacks right out of the box
Could you expand top 5(or more) major pain points that it solves?
Re: Strong arrows: a new approach to gradual typing
#5I cannot support much in terms of money or time currently, but somehow I'd wish there are ways to speed this up. Sure, sponsoring from big corps comes with their own problems, but maybe that would be an option? There are quite some that use Elixir (or BEAM in general) out there... Idk what would be the best approach. But I am very convinced that Elixir and the wider ecosystem (not only phoenix liveview) is (or could…
> It solves _so many_ problems of other comparable tech stacks right out of the box Could you expand top 5(or more) major pain points that it solves?
I don't thinks that would be a helpful discussion right here. Any one point there might come someone who points at some external "solution" (package, tool, ...) that might also do the same feature in some way for X, ignoring the fact that there are lot of Y without that particular thing still, but leads into derailing the argument anyways.
Elixir (and esp. Phoenix for web dev) is more like the culmination of the best ideas and heavily draws/depends on the last decades of real-world experience. Most stuff isn't (or shouldn't) be surprising, but the point is that everything you might need for the vast majority of projects is right there, nicely packaged up into a unified nice thingy.
But to give you a few of _my_ top points:
1. Architecture and DX for complex interactions: there is no need to bring in supplemental infrastructure crutches (Redis, AWS whatever service, ...) in many cases to begin with. OTP, which is like a core library always available, already includes the building blocks for things like cache servers, application clustering and supervision strategies, ... .
2. Reliability and availability: this tech is the original one achieving the "nine-nines" of uptime record. To get an idea of how, https://www.youtube.com/watch?v=JvBT4XBdoUE this talked is packed and excellent, and also highlights a few things why it can achieve my point 1 above.
3. "SPA-like" interactivity with full server side rendering without all the pains of exposing/consuming a dedicated HTTP API in between, or overcomplicated nuances of rendering pipelines (also see react server components) to achieve SSR/CSR in a way that not sucks or is noticeably slow. Liveview is tried to be replicated in other stacks, but they don't come close in reality today or complicate the apps' infrastructure with additional crudges. And don't get me started on the integration testing story compared with SPA+Backend setups.
4. Agents/Message passing parallelism (not only concurrency, but also distributed!) at your fingertips, which makes modeling current "async problems" kinda trivial. OTOH, building something like a proper async-based web framework in rust is quite a pain in the ass, with lots of type fiddling needed, instead of doing the solution you actually want to deliver with it.
5. Some absolutely awesome takes on some typical libraries. Take the ORM options for javascript/typescript (all with severe tradeoffs, and analysis paralysis ontop). Take Rails' ActiveRecord with lots of magic and while great to get started becomes quickly bloated (iE fat models) in bigger projects. And then Ecto got it "just right" with slim schemas, changesets, and basically pure functions + pipelines. Any "model" can be used within new usecases by adding new changesets/validations explicitly and easily, there is no "general" validation right on the model level you have to tiptoe around, and starting If-cascades.
Re: Strong arrows: a new approach to gradual typing
#6> If the function returns none() (i.e. it does not type check) or a type which is a subset of its codomain (i.e. its output), then it is a strong arrow.
Unless I didn't understand correctly, surely 'none()' is also a subset of the codomain? Or is none() a type containing all errors?
Anyway the concept of strong arrows is interesting. But does it also mean you can 'weaken' an arrow if you implement a more general version of a function? That would make it a bit odd because you can't know up front whether an arrow is strong or not. It makes code very non-local.
Re: Strong arrows: a new approach to gradual typing
#7This blog post makes this look like a type system for theoretical type theory people to play with than something designed to actually be practical and useful.
Re: Strong arrows: a new approach to gradual typing
#8Earlier quoted context omitted.
> It solves _so many_ problems of other comparable tech stacks right out of the box Could you expand top 5(or more) major pain points that it solves?
I don't thinks that would be a helpful discussion right here. Any one point there might come someone who points at some external "solution" (package, tool, ...) that might also do the same feature in some way for X, ignoring the fact that there are lot of Y without that particular thing still, but leads into derailing the argument anyways. Elixir (and esp. Phoenix for web dev) is more like the culmination of the best…
I would add some more points.
6. Livebook, Jupyter notebook are amazing in Python, Livebook is the same but for Elixir. Also you can connect to your running environment and interact with it.
7. The Nx ecosystem, ML is not only a Python thing now, Elixir is completely usable for ML now.
8. Ash framework, this is not a web framework but a framework for your domain, it's amazing
Re: Strong arrows: a new approach to gradual typing
#9This blog post makes this look like a type system for theoretical type theory people to play with than something designed to actually be practical and useful.
I guess I'd be glad to have my type system designed by people well grounded in theory.
Re: Strong arrows: a new approach to gradual typing
#10the arc of progress in software engineering bends towards static typing. in the future, our type systems will be so powerful they'll be able to do more inference so that we have to be less explicit. then people who have come to hate static type because of these explicit type declarations will know they hated the costume after all, not the person in it.