Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

elixir-lang.org

Post reply on HN
Print view View original

161–170 of 170 posts

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#161

Post by aki237 »

externedguy wrote: post #129
impulser_ wrote: post #123

Earlier quoted context omitted.

When you use Elixir you have to go into it knowing you might have to end up maintaining any library you are using because the vast majority of Elixir libraries are abandoned. You have to search through libraries to find out which one is being maintained. For example if you want to use an OpenAI API client, you wouldn't want to use the most starred one because that hasn't been maintained in 7 months. If you just use P…

> Very very few companies build and maintain SDKs for Elixir. This is true with any tech until it gets traction. React/Next is backed by a big company, but Vue/Nuxt still managed to grab its piece of the pie. In order to get traction Erlang / Elixir needs enthusiasts who are ok with risking and introducing it to their company or product, at least partially. No offense, but instead of condemning the Elixir ecosystem,…

I don't fully agree with your statement. We had used Scala around the time the devs were playing around with dotty. I loved many features of the language (compile times were painful, but the language itself was fun). But we had to stay back because a specific db dependency did not resolve well with later versions of Scala (2.13 it broke).

Similar thing recently, there was an obscure Scala version mismatch error when trying to use it with spark. (Not that significant of a problem).

It is definitely a headache trying to cope with the conditions till we get better especially with smaller teams who can't afford to fork and maintain something. A

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#162

Post by josevalim »

elbasti wrote: post #138
josevalim wrote: post #98

Earlier quoted context omitted.

Thanks for the link. This is my fault because the sentence is ambiguous. Where it tries to explain that "you need to remember to perform auth checks both", it rather means that you need to protect controller routes and LiveView routes the same way, but for a single LiveView, you don't need to do both. I will try to clarify it! If you have other footguns in mind, feel to shot me an email at jose dot valim on gmail!

Hi José, thank you for the reply. I hope I didn't come across as critical of the incredible work the elixir (and LV) teams have done. You are all absolute treasures to the programming ecosystem. I think you'll find that my argument ("LiveView shouldn't be the default way of doing things") is fairly common. It's not necessarily about the footguns (or lack thereof), or improving the docs: it's about there being a share…

Hi elbasti, sorry for the late reply. I didn't find your comment critical at all. I appreciate the feedback, especially when it allows us to improve things.

We should always improve the learning curve, regardless of its steepness! Any work in this direction is always welcome. I don't have anything in mind at the moment but if you do stumble upon anything, feel free to PR. :)

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#163

Post by sph »

mtndew4brkfst wrote: post #119
epiccoleman wrote: post #81

Earlier quoted context omitted.

Absolutely agree. I love Elixir but the editor integration has always been unfortunately second-class. The happy paths in VSCode work well enough with the ElixirLS, but there are a few flaws that are a quite a bummer. One major one is no rename / refactor functionality (seriously?!) and a more Phoenix-specific issue is trying to contend with auto-complete in templates, which is no fun. I like VSCode fine, but I'd def…

It frustrates me to no end that we have three separate, incomplete LSP implementations for Elixir, none of them collaborate and none of them are first party tools from the language maintainers - they're all minor community figures. They are one of the jankiest part of my experiences working with the language and it's very disappointing to live with when I also use rust-analyzer all the time and have seen the polished…

FWIW I have moved to next-ls because IIRC José is a premium sponsor of the project, so I feel safe relying on it for the time being. Agree that the duplication is unnecessary and wasteful.

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#164

Post by josevalim »

williamdclt wrote: post #61
josevalim wrote: post #23

Earlier quoted context omitted.

While both Elixir and TypeScript are structural, they are different type systems. A set-theoretic type system is not one that has unions, intersections, negations, but rather one where the foundation of the type system is represented on top of unions, intersections, and negations. Even relations such as subtyping, compatibility, etc. are expressed as set-theoretic. We also have a very different approach to dynamic/gr…

I did read your article, and it’s actually how I came out with the idea that Elixir had come up with the same idea as TS haha! I’m sure I’m missing something as I have no doubt you’re by far more knowledgeable than I am, but TS also represents types as sets (semantically, dunno about internal implementation), structural typing seems to inherently map to set theory For example, about bounded polymorphism the article s…

Sorry for the late reply but I wanted to double check before following up. And I am glad I did because I was told my first response was inaccurate. :)

It is fair to call both TypeScript and Elixir as set-theoretic type system. The big difference is that Elixir's implements semantic subtyping. Here is the paper you can use to dig deeper. I hope it helps: https://www.irif.fr/~gc/papers/lics02.pdf

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#165

Post by goosejuice »

miguno wrote: post #160
bcardarella wrote: post #132

Earlier quoted context omitted.

website comes last

That is sad to hear. Spending even just thirty minutes on the website to better communicate what one can/cannot do would go a long way. In any case, thank you for your work.

Completely agree here. It would probably save time just having to explain timeline/status here, forum, etc.

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#166

Post by goosejuice »

impulser_ wrote: post #123
julienmarie wrote: post #75

The last few years the Elixir ecosystem has started to become the simplest solution to so many use cases: - Web development with Phoenix and Liveview is immensely enjoyable and fast - AI with NX, Axon, Bumblebee - Audio and Video streaming and manipulation with Membrane - CQRS and Event Sourcing with Commanded - Embedded with Nerves to make your own devices - Mobile apps with Liveview Native ( in development ) - Queu…

When you use Elixir you have to go into it knowing you might have to end up maintaining any library you are using because the vast majority of Elixir libraries are abandoned. You have to search through libraries to find out which one is being maintained. For example if you want to use an OpenAI API client, you wouldn't want to use the most starred one because that hasn't been maintained in 7 months. If you just use P…

For API clients it's hardly any work to write your own. Sure large communities have more off the shelf options but those options are also more likely to go out of vogue.

NIFs and small services can often fill the gap if really needed.

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#167

Post by goosejuice »

tpdly wrote: post #145
elbasti wrote: post #56

Earlier quoted context omitted.

I love elixir. I use it for basically everything. And LiveBook has become my go-to place to start building toy software. I just can't do liveview. I have a very hard time grokking it, and it has a lot of footguns. (ex: if you need to remember to perform auth checks both doing a `pipe_through` in a router and using the `on_mount` callback in a LiveView, see [0].) In fact, the fact that the above sentence has zero mean…

Very re-assuring to find this opinion elsewhere. I am absolutely drowning in Liveview. So difficult to /really/ grok. I'm becoming more convinced that it just isn't worth the effort, especially considering the interface will glitch if the user drives through a tunnel. Meanwhile deadviews + channels is /miles/ better than python/rails/laravel (imho).

I'll take liveview over any frontend framework. But it's not either or.

Whether it works for you really depends on your needs. I always hear the offline tradeoff but for most businesses it's not a deal breaker. What % of websites do you use every week where you expect it to work offline?

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#168

Post by goosejuice »

conradfr wrote: post #97
elbasti wrote: post #56

Earlier quoted context omitted.

I love elixir. I use it for basically everything. And LiveBook has become my go-to place to start building toy software. I just can't do liveview. I have a very hard time grokking it, and it has a lot of footguns. (ex: if you need to remember to perform auth checks both doing a `pipe_through` in a router and using the `on_mount` callback in a LiveView, see [0].) In fact, the fact that the above sentence has zero mean…

I recently started a project and could have pushed for LiveView but knowing I would need very detailed and complex auth/auth which SUCK in Phoenix I went back to Symfony + VueJS&TS for some parts and I'm amazed how fast and productive I am. Sure when I need to write a REST route + its consumer in the client I die a little because I know that's the part I could have avoided...

Haven't had any issues with authn/authx in phx land. What are you trying to do?

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#169

Post by goosejuice »

birdfood wrote: post #77
elbasti wrote: post #56

Earlier quoted context omitted.

I love elixir. I use it for basically everything. And LiveBook has become my go-to place to start building toy software. I just can't do liveview. I have a very hard time grokking it, and it has a lot of footguns. (ex: if you need to remember to perform auth checks both doing a `pipe_through` in a router and using the `on_mount` callback in a LiveView, see [0].) In fact, the fact that the above sentence has zero mean…

I've been having a similar experience trying to build an app with liveview. I've been simultaneously building the same app with Phoenix + LiveView and Dream (OCaml) + HTMX. With the OCaml stack I'm finding it really easy to follow the data flow through the whole app thanks to the compiler. With the Phoenix app I'm struggling to internalise how all the code fits together and having to navigate the code base off search…

Jump to definition works well with each of the lsps out there. Has for years. No refactoring functionality but llms filled that gap.

Each liveview is an isolated process. You can easily inspect this in the process tree with the phx dashboard that is bundled. State & messaging is certainly the hard part to grok with the beam. I found elixir in action to cover these concepts very well and nothing has really changed since it's first release.

Your experiencing trying to follow data through Phoenix is the complete opposite than what I had when I picked it up many years ago. The request response cycle is pretty straightforward to follow being a struct piped through the endpoint. Liveview isn't much different. Breath of fresh air for me really. Coming from a year or two studying rails which is a nightmare in comparison with all the metaprogramming.

While I do think you can be productive in this stack without knowing much about the BEAM, just taking a week or so to get to know it will pay dividends. It's a paradigm shift compared to a lot of what's out there -- but isn't one that I found difficult to grok as a new developer in the middle of my CS undergrad at the time. Many of my friends shrugging it off for python found their way to elixir eventually :)

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#170

Post by goosejuice »

goosejuice wrote: post #169
birdfood wrote: post #77

Earlier quoted context omitted.

I've been having a similar experience trying to build an app with liveview. I've been simultaneously building the same app with Phoenix + LiveView and Dream (OCaml) + HTMX. With the OCaml stack I'm finding it really easy to follow the data flow through the whole app thanks to the compiler. With the Phoenix app I'm struggling to internalise how all the code fits together and having to navigate the code base off search…

Jump to definition works well with each of the lsps out there. Has for years. No refactoring functionality but llms filled that gap. Each liveview is an isolated process. You can easily inspect this in the process tree with the phx dashboard that is bundled. State & messaging is certainly the hard part to grok with the beam. I found elixir in action to cover these concepts very well and nothing has really changed sin…

I found this free resource that explains the phoenix liveview lifecycle pretty well if helpful: https://www.youtube.com/watch?v=ffB9gmzYJJg.
Post reply on HN