return to table of content

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

julienmarie
29 replies
16h49m

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 )

- Queues, pipelines and batch processing, etc... natively or with GenStage, Broadway or Oban depending on your use case

but for me, the killer feature is IEX, Elixir's REPL. Being able to interact directly with my running code easily ( in dev or in production ), introspect it, debugging it, is just life changing.

Adding types is indeed the last piece to the puzzle to bring even more confidence in the code we ship.

theonething
5 replies
14h31m

killer feature is IEX, Elixir's REPL

Don't many other languages have this? Ruby has IRB for example. Is there anything IEX does that IRB doesn't?

skndr
2 replies
14h10m

The cool thing is that you can, with the BEAM, connect your shell[0] to a running server and use something like recon_trace[1] to watch functions as they’re getting called. The same principle is used for libraries like this distributed profiler so you can watch the aggregate performance of your application[2].

[0] https://hexdocs.pm/iex/1.12/IEx.html#module-remote-shells (the remsh flag)

[1] https://ferd.github.io/recon/recon_trace.html

[2] https://hexdocs.pm/orion/Orion.html

cess11
0 replies
8h38m

Not just a running server, you can hook into a running cluster and do such things.

The Observer, :observer.start(), is another very nice tool. Might require some widget libraries for the GUI but you'll likely have set that up on the machine you're doing the introspection from.

15155
0 replies
9h15m

This was possible with various flavors of Pry and DRB once upon a time.

rkangel
0 replies
9h3m

Beam/OTP has a lot of tools for understanding the runtime state of the system. And you can attach the REPL to an existing, already running instance.

As with many things Elixir/Erlang related, there isn't a lot that's unique and not seen anywhere else. It's more that the pieces are carefully thought through and come together to make a fantastic whole.

auraham
0 replies
13h4m

Personally, I prefer iex over irb, iex feels more intuitive. Recently, some improvements were made into iex, the most relevant to me is the ability to use Ctrl+l to clean the output. Now, iex is getting closer to ipython.

impulser_
4 replies
7h27m

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 Python you get to use the one maintained by OpenAI. Using a language like Python, JS, Go ect. you almost never run into this problem because libraries are usually maintained and aren't abandoned and if they are there are usually enough users that a fork appears.

So yeah Elixir has great uses, but is it worth the possible future headaches of having to maintain a bunch of libraries to get your app going? Instead of using Go, Python, JS ect where you can rely on a massive community

Very very few companies build and maintain SDKs for Elixir.

externedguy
3 replies
6h31m

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, why not embrace it in your company or product, as many have done (including me)? I think most devs should be OK with taking a tolerable risk if they see opportunity to increase productivity by N times

impulser_
2 replies
5h41m

We did and it was a lot of work. We had to maintain 5-6 libraries ourselves instead of using one maintained by the services themselves. We had to fork libraries because they became abandoned.

Elixir has been around for 12 years now and still hasn't gained any meaningful traction.

The risk of using Elixir vastly out ways the benefits today if you are trying to build a product.

There is a reason why almost every product today is built using JS and Python because it easy to find developers, it's easy to find everything you need, almost every service supports it and there are tons of resources for it.

We switched for Elixir to JS and we only have to maintain the app itself. We have hundreds of OSS helping maintain the libraries we use most of them working for companies that the libraries are for. That's the massive advantage of using popular languages that everyone uses.

Elixir is a fun language but that's about it.

taatparya
1 replies
5h20m

Million+ concurrent users per server - Discord are certainly having fun.

ikety
0 replies
1h25m

All while having so few employees. I don't blindly copy discord, but I pay attention to most things they do engineering wise. IIRC they have like 2 people working on the mobile app. It's insane, and I think a great story for those that want to start small and stay small.

birracerveza
3 replies
10h48m

Now the only thing left: figuring out how to deploy it.

dankai
2 replies
10h46m

it's pretty straightforward and simple with `mix release`

birracerveza
1 replies
10h37m

I remember trying to deploy it a couple years ago and it was fairly complicated. Granted, I was trying to deploy a multi-node mnesia cluster, which is probably what caused all my issues.

But for non-production single nodes I just created a Dockerfile and deployed it because the other options were too much hassle. Can't remember the details, but in my (in)experience, deploying was always the hard part with Elixir.

I will need to try it again, it's been a while and the ecosystem has improved dramatically in the meantime ... and it was already excellent before. Good stuff!

rkangel
0 replies
9h1m

My view on Elixir deployment is that for a given complexity of setup, it's no harder than anything else. For a basic single node webserver, `mix release` makes it like releasing anything else (often more easily). For complex multi-node setups, yes there's some hard work to do, just like there with on any other platform. The difference is that the development experience of getting to a working stable multi-node setup is so much easier on Elixir than anything else that you notice the difficult deployment more.

bcardarella
3 replies
15h10m

I'll take the opportunity for a shameless plug on LiveView Native. In addition to mobile apps we can also build for desktop, watch, TV, and even Apple Vision Pro. All using LiveView concepts, performance, and ease of development.

auraham
1 replies
13h10m

Hi Brian, thanks for all effort put into LiveView Native.

Quick suggestion, it would be nice if the landing page [1] has more information or links to actual examples of how to use LiveView Native. That page has not been updated in a long time and give the (misleading) impression that the project is on hold.

[1] https://native.live/

bcardarella
0 replies
5h51m

website comes last

gmt2027
0 replies
6h10m

Already sold. Just waiting for updates on production-readiness and Android support.

valenterry
2 replies
10h32m

Adding types is indeed the last piece to the puzzle to bring even more confidence in the code we ship.

This is the hard missing piece for me and why I'm looking curiously over to Gleam. Coming from a language with a very powerful and useful statical typesystem, I just can never go back to something like Erlang or Elixir in my life. :-(

AlchemistCamp
1 replies
3h18m

Go back? Have you ever worked on a significant project in either Erlang or Elixir? If so, what issues did you experience?

valenterry
0 replies
1h41m

This was meant for the statical typesystem. I've worked without statical typesystem in other languages, yes. (never professionally on the BEAM though)

epiccoleman
2 replies
15h6m

The Elixir REPL is world-class, and I agree that it's a truly killer feature of the language. I miss it terribly when I write stuff in other languages (i.e. any time I'm coding, you know, for money).

Having a good REPL just removes so much of the friction you normally have to contend with in programming. You can build up ideas piecewise and test things as you go, instead of having to make guesses and run the whole damn app just to poke some troublesome piece of code. The Elixir standard library is great, and it's extremely easy to access the docs via the REPL, which I find really helps me stay in the flow. When I'm coding in Elixir, popping over to a browser window to search small questions is pretty rare, because I can usually find the answer without leaving the REPL. This also encourages me to write good docstrings for my own code!

But it gets even better, because you can run the REPL while also running your code. I mentioned above having to "run the whole app to poke a piece of code" - when you find yourself needing to run the app, you're welcome to, and you can manipulate live data (in dev, of course ;) ) and inspect what's going on in ways that you either can't do or need a debugger for in other stacks. And now, with the introduction of some typing facilities, I expect the tools to get even better.

Then there's all the fun and power of the functional paradigm while still having extremely robust ways to deal with mutability and state, and not having to deal with the syntax of LISP (sorry LISP). It's a language that just hits every note for me, I'm a huge fan.

barrell
1 replies
12h6m

Recently moved my python app over to Elixir, and currently gushing over Elixir every day. I'm a huge fan and have loved everything about it, except...

Comping from a LISP, the Elixir REPL really is not world-class. It's a really far, distant second. It's nice, I enjoy it more than python's personally, and more than what I remember from irb back in the day -- but nothing beats the integration of structural editing and nREPLs.

LISP doesn't have to be for you, but there's still a lot to learn from that REPL experience if the Elixir community wants to grow ;)

epiccoleman
0 replies
1h58m

Yeah, I considered adding a caveat to my post. The LISP repl experience is of course the real gold standard (especially when you've got good editor integration, like the various Emacs packages).

I love LISP in general - was a big Clojure fan for a while - but I feel like Elixir threads the needle of usability much better for me.

Anyway, I'll stand by my claim - Elixir's REPL is leaps and bounds better than Python's, and better than irb and pry by some smaller amount. It's a pleasure to use. I would love to see a world where I can send expressions for evaluation to the REPL as easily as you can with LISP. Maybe we'll get there someday!

x3qt
1 replies
45m

Recently live development capabilities were added to Ruby as well, thanks to latest patches to inf-ruby, now it's possible to eval code around the breakpoint and in the global context as well, everything available right under cursor.

kimi
0 replies
12h15m

You are forgetting WebRTC with Membrane...

barrell
0 replies
12h13m

Don't forget:

- ExUnit for incredibly easy tests

- Hex package manager that just works

- FLAME for the ability to scale different processes to different computers with nearly 1 line of code (the whole library itself is just a few hundred LoC if I remember)

- Ecto for interacting with SQL databases in a functional manner (I still never know how to feel about ORMs, but I was able to write a few composable queries and get rid of 90% of my SQL, so I'll call that a win)

After months of struggling with deployments, uptimes, segfaults, package times, etc I moved my webserver & data layer over to Elixir + Phoenix. It's more well tested than ever, so much easier to reason about, I trust it will scale, and deployment was a breeze.

Because of convention over configuration, I was able to get up and running _insanely_ quickly with Phoenix (way more than FastAPI). I really wish I did this months ago.

Now I'm training models in Nx, playing around with Bumblebee/Livebooks, and adding presence/live functionality to my app for nearly free.

sapiogram
17 replies
1d6h

Does anyone know what they mean by "set-theoretic types"? I'm a PL nerd, but I've never heard this term before.

bobwaycott
11 replies
1d6h

From the original paper[0]:

We present a gradual type system for Elixir, based on the framework of semantic subtyping ... [which] provides a type system centered on the use of set-theoretic types (unions, intersections, negations) that satisfy the commutativity and distributivity properties of the corresponding set-theoretic operations. The system is a polymorphic type system with local type inference, that is, functions are explicitly annotated with types that may contain type variables, but their applications do not require explicit instantiations: the system deduces the right instantiations of every type variable. It also features precise typing of pattern matching combined with type narrowing: the types of the capture variables of the pattern and of some variables of the matched expression are refined in the branches to take into account the results of pattern matching.

[0]: https://www.irif.fr/_media/users/gduboc/elixir-types.pdf

williamdclt
10 replies
1d5h

sounds like what typescript does, I'm not clear if the Elixir approach is different from "structural typing" (as TS calls it) or if they're rediscovering the same thing. Either way, I'm happy it's the way they're going

weatherlight
6 replies
1d5h

Typescript's type system isn't sound. The Set theoretical type system proposed for Elixir is.

lolinder
5 replies
1d4h

For more information about what that means, see this playground [0] from the TypeScript docs. PL people often make a big deal about TypeScript's lack of soundness as though it was some kind of mistake, but it was very much an intentional choice given the trade-offs they were making at the time.

If Elixir can pull off soundness without compromising expressivity that will be a huge feat, and I'm excited to see it!

[0] https://www.typescriptlang.org/play/?strictFunctionTypes=fal...

zarathustreal
4 replies
1d4h

Yea I never bought this assertion from the TS team, saying “given the trade-offs at the time” is the same as saying “we’re already backed into a corner by previous decisions” - the decision(s) may have been intentional at each step but the design itself probably was not. Given the choice of sound or unsound, considering that the purpose of a type system is to give certain guarantees, a type system design must always choose soundness to be considered reasonable.

That being said, I don’t think it’s possible to “pull off soundness without compromising expressivity” because the expressivity in this context is self-referential types which equate to non-terminating unification logic (and thus, unsoundness). Still, I’m excited to see what they do with this type system! Reminds me a bit of Shen’s type system.

lolinder
3 replies
1d3h

Is the TypeScript team correct in explaining that soundness would exclude functions accepting subtypes as laid out there? If so, it seems like any type system that was meant to be able to type common JavaScript idioms would have to be unsound.

zarathustreal
1 replies
1d1h

Sub-types can be represented with algebraic types so I’m not sure that’s necessarily true, for example an abstract class with subclasses can be represented as a sum type

zem
0 replies
21h11m

only if there is a fixed set of subclasses, which is not always or even mostly the case.

deredede
0 replies
10h38m

Yes and no - you can't have bi-variant argument types as shown here and be sound, but that does not mean you can't type those idioms. You just need the type system to be able to express a dependency between the name of the event handler and the type of the associated function. It is not exactly straightforward (this is a complex type system feature) though, I don't blame the TS devs for going for an escape hatch there.

(Edit: to be clear, allowing to refine function types in the way they do is part of the solution, the unsound part is that it is not checked afaik)

josevalim
1 replies
1d4h

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/gradual typing (which is sound): https://elixir-lang.org/blog/2023/09/20/strong-arrows-gradua...

I recommend reading Giuseppe Castagna's work for those who want to dig deeper: https://www.irif.fr/~gc/

williamdclt
0 replies
21h11m

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 says “Of course, we can provide syntax sugar for those constraints”: seems like this sugar could be ‘a extends number’ to me, like typescript does. I don’t see how TS does _not_ map to set operations

throwawaymaths
0 replies
18h8m

Elixir is going to be fundamentally different from TS though. The base set of datatypes is quite well defined, and function activities are rather composable unlike JS where "basically anything can happen".

gregors
1 replies
1d5h

If you're into watching talks, this will be well worth your time.

ElixirConf 2023 - José Valim - The foundations of the Elixir type system

https://www.youtube.com/watch?v=giYbq4HmfGA

freedomben
0 replies
1d4h

Thanks, this is a fantastic talk. Long, but well worth it, especially if you work with Elixir

aatd86
0 replies
1d2h

It's the definition of types as set of values. Then you have set operations on these types that are lade available. That translates into subtyping considerations.

Cf. Castagna's et.al. For semantic subtyping.

mike1o1
15 replies
1d1h

I've been using Elixir as a backend for a side project (with a Remix frontend) and it's been really pleasant and productive to work with on the backend. I appreciate how productive LiveView can be, but for my specific case I needed to handle poor network connections and LiveView was (as expected) a poor experience.

I wish Elixir was able to decouple itself from LiveView in a sense in the minds of developers. Even without LiveView and realtime/channels, just using Elixir as a backend for a simple API has been really fun.

elbasti
8 replies
22h0m

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 meaning to a new-to-phoenix-and-liveview dev is proof enough to me that liveview should not be the default way of doing things.

It creates a very steep learning curve where, crucially none is required. elixir/phoenix are easy.

I would even say that the correct learning order for a new-to-elixir/phoenix dev should be:

- Phoenix with deadviews (MVC style).

- "Elixir in action" to learn the basics of OTP. This book is was both easy and utterly eye-opening to me and changed the way I code basically everything.

- Then, and only then, LiveView.

[0]: https://hexdocs.pm/phoenix_live_view/security-model.html#liv...

josevalim
1 replies
11h52m

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!

elbasti
0 replies
4h3m

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 shared vocabulary among people that do web development that LiveView is alien to.

Web frameworks have historically been great tools to drive adoption of programming languages (Ruby/Rails, react/ts). The same could be true of Elixir.

However, in order for that to obtain, the learning curve can't be too steep, at least in the initial portions of it. I think you'll find that with LV the learning curve looks like a step, and imho that step is a bit too high.

Of course, all these arguments apply both at the individual level and the company/org level. Think about a new hire's time-to-productivity if they first have to learn elixir, then phoenix + liveview vs just elixir & MVC phoenix.

If there's a way I could contribute to an effort that helps people learn elixir sans lv--perhaps writing, sketching, or even reading a guide/documentation--I'd be happy to give it a crack.

birdfood
1 replies
16h1m

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 searching for strings alone (vscode editor tooling seems to just not work for me?). I'm also struggling to grasp how state is stored in a liveview and it isn't helped that a lot of the resources I've found online are now out of date. Going with a simpler approach of MVC sounds promising - I do want to get to the point where I'm actually taking advantage of the BEAM (I'm aiming for long running processes + user interactivity + maybe multi-user editing).

I'd be keen to hear your development workflow for building an MVC style app, what you use for the front end, and how you go about refactoring, e.g. when editing a struct which is stored in the DB and shown in a view is when I particularly feel like I'm flying blind.

myaccountonhn
0 replies
6h25m

I echo this. It’s always the struggle of DIY + understanding what’s going on versus taking the magic off the shelf solution where it works until it doesn’t.

arrowsmith
1 replies
21h12m

Shameless self-promotion - if you're struggling to learn LiveView then you could try my tutorial: http://phoenixliveview.com/

epiccoleman
0 replies
15h19m

You'll be pleased to know that you got at least one sale from this post. I've struggled a bit to go from knowing Phoenix reasonably well to grokking LiveView. Looking forward to finding some time to dive into your course.

tpdly
0 replies
1h26m

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).

conradfr
0 replies
11h53m

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...

manchmalscott
4 replies
1d

You can use Phoenix without LiveView by running mix phx.new with the —no-live flag (or manually pull it out of an existing project).

mike1o1
1 replies
1d

Yes, I totally get that (and have been doing that). My complaint/suggestion is more around the marketing and messaging. There is so much more to Elixir than LiveView!

barrell
0 replies
12h1m

I get this. Currently have a front-end built, with the need (& existing functionality) for offline local first etc. Switched to phoenix on the backend, and the amount of liveview stuff I have to 'wade through' is really distracting. It also seems to be eating up about 75% of the hype in the Elixir community :laugh:

bnchrch
1 replies
1d

But too the OPs point. This is not a technology that should be included by default. No matter how cool.

Saying this as a die hard Elixir fan who's been using it since 2015.

arrowsmith
0 replies
12h24m

Why not? If you don't like it just build the app without LiveView. Having `phoenix_liveview` as a dependency in mix.exs doesn't do any harm if you're not using it.

sbuttgereit
0 replies
1d

There are a couple comments to you so far and both of them miss the point.

decouple itself from LiveView in a sense in the __minds of developers__

This isn't a technical knowledge issue or if a given technology should be the default on install. Assuming I understand your original post correctly this is a mindset issue: too many people dismiss Elixir and the rest of the ecosystem because the first thing they think about is LiveView while ignoring the rest of the ecosystem and that's a shame, because it's much more than that... and I would agree with that point. Even Phoenix is more than LiveView.

It's possible to have solidly productive, cost effective Elixir applications not involving LiveView or even Phoenix for that matter. The choice of Elixir in the backend should be more common than it is, though I understand some of the conventional wisdom and fears that motivate other choices.

dankai
13 replies
23h54m

I've been building my startup 100% fullstack in elixir, and it's been the most wonderful technology I've ever worked with. I'm evangelising all my serious tech friends about how great it is.

Now it would be awesome if rabbitMQ and its client would run on OTP 27, would love to upgrade :(

davidw
9 replies
20h58m

If I may ask, what are you working on where Elixir hits the sweet spot compared to other technologies?

dankai
8 replies
20h29m

A news aggregator (and premium news chatbot) that indexes and analyses around ~150.000 new articles a day (http://im.fo)

I'm absolutely certain the real time processing would be unfeasible in any other technology in terms of complexity and the minimal compute resources it's running on.

Modules like broadway, ash, oban, phoenix liveview ... make it not just a pleasure to work with but insanely performant.

With over 20 years of programming experience, I can say with certainty that there is no language that makes me as productive as elixir. It's at least 10x my python productivity (despite being at an expert level in python as well).

Thaxll
7 replies
14h15m

You know that Elixir is on the low end of performance right, so you take Go/Java/C# that are close to 10x faster.

dankai
2 replies
10h58m

performance has many dimensions. for example the cost/speed of spawning a process/thread and their intra process communication.

neonsunset
1 replies
5h17m

Very cheap in C# and Go. I assume Java has now closed the gap with its Green Threads implementation.

(Spawning an asynchronously yielding C# task is ~100B of allocations depending on state machine box size, with very small overall overhead and threadpool handling millions of them, they are cheaper than Elixir tasks which make different tradeoffs (and are subject to BEAM limitations), you can try this out on your machine by running the examples from this thread: https://news.ycombinator.com/item?id=40435220)

dankai
0 replies
4h52m

thanks for sharing!

svnt
0 replies
13h58m

I don’t know enough about news aggregators to evaluate the claim, but presumably that is why parent mentioned both complexity and compute, not just performance.

rkangel
0 replies
8h54m

For "straight line" single thread number-crunching, other languages will often be faster. With the new JIT, I doubt they are 10 times faster, but you're right there is a difference.

That's often not the limiting factor though. Elixir makes it very easy to have excellent parallelism on your work so you actually take full advantage of processor. The design of the BEAM means that things are naturally quite low latency, and often you lose performance due to just waiting for things (this characteristic is why webservers on the BEAM are pretty fast).

The other key aspect is NX - like ML libraries in Python, Elixir is just orchestrating and the number crunching is done in C libraries or on GPU etc.

cess11
0 replies
7h12m

If you need per-core number crunching performance you'd reach for Nx, similar to how you would do the crunching in Python. With OTP it's then (almost) trivially concurrent.

Compared to squeezing performance out of multiple cores with the JVM it's absurdly convenient and consumes way less RAM. I have two reasons for still working with the JVM, multiplatform desktop GUI and high quality PDF libraries that support rather low-level aspects of the standard that I need. It's kind of obvious why these things aren't readily available on the BEAM, though.

barrell
0 replies
11h55m

Which parts of his application need a 10x speed improvement?

Joel_Mckay
2 replies
23h22m

RabbitMQ is pretty solid, are you running into a performance leak or something?

We've used the SSL cert client login method for years, and have been very happy with the reliability.

Cheers, =)

Joel_Mckay
0 replies
22h3m

I guess we wait a bit more for a stable release. =)

tiffanyh
10 replies
1d5h

How does this compare to Gleam (strong) typing?

https://gleam.run

weatherlight
8 replies
1d5h

Different type system with different goals.

Gleam uses a modified version of the Hindley-Milner Type system. (Which is a rock solid tested type system.)

A Set theoretical type system is more expressive(which suits the dynamic nature or Elixir better.) You can do Union and Intersection Types, and Negation Types, among other things, that you can't do with a HM type system. but it comes at the cost of how fast the program can be typed.

HM types systems have amazing type inference capabilities and do so at O(n). Im not sure what the time complexity of the algorithm they are using to do the type checking for Elixir programs, but I bet it's more expensive than that. (Which is probably why they are rolling out the type system slowly.)

tiffanyh
4 replies
1d4h

Does Gleam check types at compile-time?

And Elixir check types at run-time?

(If at run-time, would that mean it would slow down your entire app as a result?)

bo0tzz
1 replies
1d4h

My understanding is that the BEAM vm already has some (optional) runtime typechecks in the form of guards, which this new typesystem will also add for you automatically. And that these guards are actually used to speed things up, for example by JITing more optimized code.

throwawaymaths
0 replies
19h24m

So inserting those type checks automatically will cause regressions because those checks are not free at runtime, and there are cases where the JIT will look at the code and not bother optimizing.

davydog187
0 replies
1d4h

Both the Elixir and Gleam type systems run at compile time (and whenever you recompile during development)

There are no plans for runtime checking AFAIK

arrowsmith
0 replies
1d4h

Elixir checks at compile time.

throwawaymaths
0 replies
19h26m

It's also not clear that an h-m type system is what people want. For example, checking json inputs in gleam will always either be awkward or behind a "marshaller for me but not for thee" sort of inside-ball stuff, and the interface with other members of the beam ecosystem will be poor. It is possible to build a set theoretic type system without these problems, but I don't see these cases being handled by elixir's type system, either.

nerdponx
0 replies
1d4h

A Set theoretical type system is more expressive(which suits the dynamic nature or Elixir better.) You can do Union and Intersection Types, and Negation Types, among other things, that you can't do with a HM type system. but it comes at the cost of how fast the program can be typed.

I doubt that Python's static type hints existing within a formal mathematical framework, but it's interesting that intersection types have been under consideration for a long time now: https://github.com/python/typing/issues/213

cobbal
0 replies
21h53m

HM is worst-case exponential, but it just happens to have good performance in practice.

throwawaymaths
0 replies
1d5h

Gleam's type system is (IIUC) basically h-m bolted onto the beam. elixir's is its own

GiorgioG
8 replies
1d6h

Super-excited for this release. I wish someone would put some resources into the Elixir IntelliJ plugin. I've tried, but I just can't enjoy using VSCode (vs IntelliJ based IDEs, Visual Studio, etc.)

epiccoleman
3 replies
15h1m

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 definitely be interested in a Jetbrains level IDE for Elixir stuff.

cschmatzler
1 replies
11h34m

Use lexical instead of elixirls and most of your worries will be gone

epiccoleman
0 replies
2h2m

Oh man, I can't wait to try this out. Thanks for the pointer!

mtndew4brkfst
0 replies
8h3m

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 & productive version of LSP support.

barrell
2 replies
11h49m

Zed has been amazing so far for my Elixir journey, and their latest preview release has additional support for Elixir tests. Not sure how it compares to IntelliJ

spiderice
1 replies
4h58m

I’ve also been using Elixir + Zed for the last couple months. Love it. And it’s so snappy. It’s the first editor I’ve found where ElixirLS doesn’t feel like it’s making my editor lag. Not sure what they do differently.

barrell
0 replies
3h32m

From what I gather it’s a combination of immutable data structures, light caching, and running the lsp/treesitter in background processes. The founder has a bunch of interesting interviews going deep into the mechanics if you’re interested!

azurelake
0 replies
21h0m

Same. I would pay 50 / month for an Elixir plugin that had a comparable amount of polish to RubyMine.

pawelduda
6 replies
1d6h

This is it, the final piece I wanted. Looking forward to the further stages. Apart from that, the language is 100% feature-complete as far as I am concerned.

Tao3300
5 replies
17h11m

Last time I looked at Elixir, it seemed like the consensus was "you're going to need to do Erlang too". Is that still the case, or is dipping down into Erlang no longer required?

theflyinghorse
1 replies
14h40m

As elixir noob I find I reach into erlang often, mostly for things like sets, queues. Do people often end up writing erlang alongside elixir code in the same project?

cess11
0 replies
7h0m

I'd say it's uncommon but you'll often use Elixir wrappers around OTP stuff or Erlang libraries. Sometimes there isn't a wrapper for the library you want so you'd just call into the Erlang library directly, which is much easier and "noob"-friendly than FFI:s usually are.

For sets it's usually recommended to use Elixir MapSet. There is a Queue-wrapper around the FIFO-queue in OTP as well. For fun and learning you can also implement your own queues, or things like process pooling around the tooling already available.

rkangel
0 replies
8h51m

I occasionally end up reading Erlang so I can see what's going on in some library. I haven't had to write very much.

If you have decent familiarity with Elixir, understanding Erlang isn't very difficult. You spend 20 minutes grokking the slightly weird syntax and then it's generally just a subset of Elixir. This is of course a bit of a simplification, but it's close enough for when you're trying to understand someone's Erlang code.

mtndew4brkfst
0 replies
8h12m

I call Erlang functions or libraries very often, but in ~10 years of writing BEAM software I've never actually written Erlang code. Reading it is a useful skill and occasionally necessary, as is being able to consume its documentation for things like gen_statem.

jasonpbecker
0 replies
11h57m

We have a four year old application, 10+ developers, 2500+ PRs, and I don’t think a line of erlang has been written by us. Maybe there’s one or two instances of calling an Erlang function in Elixir, but we’re 94.7% Elixir, 3.7% HTML, 1.1% JS, and 0.5% Other in our monorepo, full application.

bhaney
6 replies
1d6h

I'm excited about the type system so far, but I'm especially excited to hear about what else the type system is going to enable in the future. I remember José describing this as a "gradual gradual type system," where the gradual type system is going to be gradually added in stages, with this being the first stage. Any cool new type-system-related stuff coming up in the next few stages? I'm especially hoping for newly enabled compiler optimizations.

pawelduda
4 replies
1d6h

Doesn't gradual type system mean something else here? As in developers being able to iteratively add types while leaving untyped parts for later? At least this is how Ruby's Sorbet describes it

mhanberg
1 replies
1d6h

Correct, a gradual type system is a form of type system and not the method for rolling it out.

arrowsmith
0 replies
1d4h

It's a gradual type system that they're rolling out gradually.

pjam
0 replies
1d6h

Yes, but the discussion here was about it being a gradual, gradual type system, as in, the gradual type system being added gradually

dub_gui
0 replies
1d2h

You’re right about what a gradual type system means! A gradual type system allows flexibility in how you approach typing a codebase. It also means that your system incorporates a dynamic type, making your types 'gradual'.

Interestingly, gradual set-theoretic types are flexible enough to let you gradually implement type inference for that system. Hence, the gradual gradual type system. :-)

aczerepinski
5 replies
1d4h

For 10 years I’ve been reading about cool Elixir stuff here. Love the language. I gave up on finding a job in Elixir many years ago though after seeing salaries consistently lower than more mainstream languages. It may be the language I’d want to use most, but salary and cool product are more important to me than tech stack so it may never happen. Still fun to follow from afar.

ch4s3
3 replies
1d3h

seeing salaries consistently lower than more mainstream languages

That seems surprising to me as an Elixir developer. Are you looking in the US, or elsewhere?

davidw
2 replies
20h55m

I keep an eye out in the US and there just aren't many of them out there.

And you have to be careful because some of those are

* "Bob wanted to try out Elixir, so now we use it for this one microservice, but we're mostly a PHP/Rails/Java/Python/whatever shop and we'd like to rewrite it one day, because Bob left a few years ago" - places where someone wanted to play with something shiny and new.

* Early stage firms where someone is a true believer that BEAM is some kind of magic scaling bullet or secret sauce.

barrell
0 replies
11h51m

Can confirm, am early stage founder who is a true believer that BEAM is some kind of magic scaling bullet or secret sauce, currently looking for elixir dev.

(mostly joking, if anyone is actually interested in ML, NLP, and Elixir, I have more pragmatic reasons for switching. Feel free to get in touch)

Tao3300
0 replies
17h13m

Dammit that first bullet is giving me PTSD

acangiano
0 replies
1d3h

Salaries are consistently above other mainstream stacks, partly because most Elixir jobs look for senior engineers.

vohk
4 replies
11h39m

Any recommendations for an entry point into Elixir? I've been teaching myself Rust through resources like Rustlings and 100-exercises-to-learn-rust, and I've found that approach to be pleasantly accessible. I've yet to find something similar for Elixir, whether interactive or just well laid-out.

mtndew4brkfst
0 replies
8h1m

If you're optimizing for career opportunities at all, Rust has more hiring potential than Elixir by a country mile. Both are lightly infested by web3 grift, though.

cess11
0 replies
6h39m

Boot up a Livebook and step through some of the basics on the Elixir homepage. Someone else recommended Elixir in Action, which is a very good book once you have some grasp on the fundamentals.

neillyons
3 replies
1d5h

Nice feature in this release is the addition of `get_in/1` which works with structs. eg. `get_in(struct.foo.bar)`

If `foo` returns `nil`, accessing `bar` won't raise.

mtndew4brkfst
2 replies
1d4h

It was still possible to do this in prior versions of Elixir, just syntactically noisy. Any layer which isn't a vanilla map needs Access.key, as in:

    get_in(struct, [Access.key(:foo), :bar])

skrebbel
1 replies
7h49m

But that’s way less clear than just

    if struct.foo do struct.foo.bar else nil end

mtndew4brkfst
0 replies
7h22m

Sure, this snippet is a trivial example and doesn't sufficiently motivate get_in and family, which can be much more powerful when needs aren't so simple.

It's also very hard to be as concise with more vanilla syntax when competing with put_in/update_in instead. The pattern and ability to generalize it is valuable IME.

CaptainOfCoit
3 replies
17h57m

This Elixir version introduces the Duration data type and APIs to shift dates, times, and date times by a given duration, considering different calendars and time zones.

We chose the name “shift” for this operation (instead of “add”) since working with durations does not obey properties such as associativity. For instance, adding one month and then one month does not give the same result as adding two months:

I'm not exactly sure why adding one month and then one month would give a different result compared to just adding two months. Don't you in reality want the same thing? Why is "shift" more useful than "add"?

icedchai
0 replies
16h7m

There are edge cases near month end.

I once wrote a billing system for my own small business. If the customer signed up for a monthly plan near month end, on a day >= 28, their next billing date was always on the 28th to keep things simple.

bhaney
0 replies
17h31m

There's a code example immediately after your quote specifically for addressing your confusion

Tao3300
0 replies
17h22m

"One month" is a tricky unit because it's not always the same size. They have a good example right there. What's a month after Jan 31? Feb 28 or 29. A month after that? Mar 28 or 29.

What's two months after Jan 31? Mar 31.

Maybe you think it should behave otherwise, but they picked a way and changed the name so you wouldn't think of the addition operation and its expected properties.

notemaker
2 replies
1d6h

Really impressed with how thoughtful _and_ fast they are delivering on their type system.

widdershins
1 replies
1d1h

I'm really curious to know if many people with large Elixir problems are finding any issues with the new type system. This is pure curiosity, I don't have a dog in the fight!

sergiotapia
1 replies
23h40m

Can't say enough good things about Elixir and Phoenix. Now with types coming, it'll get even better.

By the way, you hear a lot about the BEAM and it's power - but in my experience you can go a LONG LONG LONG way before you ever have to even think about that part of your stack. Phoenix does such a tremendous job abstracting that for you. You just get the gainz with no effort. Other parts of the stack also just abstract that for you.

Case in point: Oban. You get powerful, flexible and easy to use background jobs for essentially free. Right there in Postgres, with your Elixir code. It's crazy.

Try it.

mtndew4brkfst
0 replies
7h54m

I fully agree with you were it not for LiveView, which combined with the marketing obsession around LV, means people who could have glossed over OTP for a while longer are now confronted with it much earlier in their journey, possibly on their first controller route.

Writing robust LiveView flows, and testing them well, is exactly as intellectually complex as writing stateful genservers with multiple non-linear flows and various call/cast entry points. LVs use different jargon and have small convenience layers like async-assigns, but mechanically genservers are literally what they are. I'd say that's crucial to understand well if you want to use them effectively.

Love Oban and miss it deeply in other ecosystems.

nelsonic
0 replies
22h45m

Awesome work Elixir & Erlang Devs! <3 Cannot wait for the "no types" excuse to go away for mass adoption of Elixir! Keep up the great progress.

mikl
0 replies
21h23m

The introduction of set-theoretic types has truly been a technical tour-de-force. A huge improvement of the language, but in a backwards-compatible fashion.

gregors
0 replies
1d5h

Elixir and Erlang teams are absolutely killing it over the last few years, not to mention all the work done by the library and book authors out there.

I've never been more excited about a release. I've been watching commits to both Elixir and OTP for awhile now and I feel Elixir/Erlang has really picked up steam.

Thanks to everyone involved for making my life easier!

dimitrisnl
0 replies
1d6h

I'm very happy for this release. I picked up Elixir recently, and the missing a type system was my only pet peeve.

auraham
0 replies
12h51m

Aside note: Have any of you used elixir-desktop [1]? It is a wxWidgets + LiveView bundle, pretty much like a Electron app.

In [2], Wojtek Mach explains how the team behind Elixir build Livebook Desktop. He explains how the project started, some subtle bugs found when building the app for MacOS, some limitations of wxWidgets in Windows, and many other implementation details.

It would be awesome if the Elixir team releases something like elixir-desktop based on Livebook. That is, forking the Livebook repo and release an official template project for generating desktop applications based on LiveView. Right now, Livebook is distributed as an executable for Windows and Mac. Why not follow the same approach to allow developers to publish self-contained executables pretty much like Electron?

I am aware of LiveView Native [3] but I think they follow a different direction.

[1] https://github.com/elixir-desktop/desktop-example-app

[2] https://www.youtube.com/watch?v=Kiw6eWKcQbg

[3] https://native.live/