How does it compare to Gleam? Or rather, why use Elixir over Gleam now? I suppose Phoenix and Live View in particular are big draws to Elixir.
Phoenix and Ecto, really.
Elixir v1.20: Now a gradually typed language
91–100 of 426 posts
Re: Elixir v1.20: Now a gradually typed language
#92Earlier quoted context omitted.
Here's what you need for Java: Download SDKMan/Jenv Install the version(s) of Java you need for your projects Make sure your JAVA_HOME environment variable is set Ensure your IDEs locate the correct Java home Compared to all that, Elixir's two installers are trivial. And if you have a competent package manager, you can just tell it to get Elixir and it'll handle Erlang for free.
No you don't. The process is exactly the same for Java.
Nah, I work on a team that has multiple microservices written over the years in different versions of Java. "Just click the installer" is not sufficient. That's why programs like jenv, SDKman, nvm, and others even exist (and are popular). Your lack of real-world experience is showing.
Re: Elixir v1.20: Now a gradually typed language
#93How does it compare to Gleam? Or rather, why use Elixir over Gleam now? I suppose Phoenix and Live View in particular are big draws to Elixir.
Check Gleam website, they have the comparison right there.
Last I checked there were inacuracies. I am not sure if they have been addressed!
Re: Elixir v1.20: Now a gradually typed language
#94seems ironic that critics were saying, it needs typing, and all the elixir fans were saying you don't need typing, you don't get bugs related to typing because elixir is somehow magic, now they get typing and it finds bugs for them.... but you said you didn't need that to prevent bugs? But good to see! I spent a bunch of time trying out Elixir a while back, I enjoyed it, but just didn't agree with the lack of types.
I can’t swear I’ve never seen that claim - but I can’t remember seeing it if I ever did and certainly it would be a tiny minority position. The actual con arguments are basically “it is nice but has costs, maybe those don’t all get a good return”.
It’s possible that position was correct before set-theoretic type theory was developed.
Re: Elixir v1.20: Now a gradually typed language
#95Earlier quoted context omitted.
what do you mean by 'security related concerns'?
How to properly build a liveview thats safe against hijacking the websocket phoenix uses for liveviews. You can just do it from the devtools on client side. With regular HTTP requests at least I know what to look out for, with liveview there are almost no resources on how to build a view securely. Like I was able to just call the functions in my module by just addressing them from my browsers console. Just to name an…
[1] https://phoenix-live-view.hexdocs.pm/security-model.html
There's a guide in the LiveView docs that walks you through the security model. To be clear, you need to always assume that the user can send you anything. That's a fact of any networked system: Clients need to be assumed to be completely under the control of an evil user, because at the end of the day it is impossible to know whether you're talking to the client you wrote, or some evil program written by an adversary. Any function that acts as a handler for an event/message can be called by the user, at any time. You have to use session/socket state to handle authorization.
Re: Elixir v1.20: Now a gradually typed language
#96Earlier quoted context omitted.
It was the same thing with javascript/typescript and python. Sometimes you just have to let people think what they want.
The irony is that dynamic languages that predated them had optional typing. BASIC, Smalltalk vs Strongtalk, Common Lisp, Dylan It is the eternal September.
Elixir predates set-theoretic types. Simon Marlow took a solid crack at typed Erlang 30+ years ago and couldn’t make it work and preserve what Erlang is. 9 years later Success Typings was published and Dialyzer happened. Not the best, but far better than what any other dynamic language had at that time, and Elixir had that available from the beginning.
So it is possible new theory was actually needed to preserve everything that was judged more valuable than types.
Re: Elixir v1.20: Now a gradually typed language
#97seems ironic that critics were saying, it needs typing, and all the elixir fans were saying you don't need typing, you don't get bugs related to typing because elixir is somehow magic, now they get typing and it finds bugs for them.... but you said you didn't need that to prevent bugs? But good to see! I spent a bunch of time trying out Elixir a while back, I enjoyed it, but just didn't agree with the lack of types.
Not really a contradiction. You don't need typing, but it can help.
Re: Elixir v1.20: Now a gradually typed language
#98Earlier quoted context omitted.
Do you like Rust or do you like Erlang? Writing Gleam is like writing Rust, writing Elixir is like writing Erlang. I don't know the current state of Gleam OTP, but last I checked it wasn't great. If you don't care about either of those things and only about types, use Gleam. But then why not just use Rust?
Your last sentence is basically where I'm at, writing my backends in Rust these days. I'm interested in the BEAM promise of letting things crash but not sure how good that is in Gleam due to its OTP still being somewhat immature as the devs are rewriting GenServer as a typed library.
Hello! I'm the maintainer of Gleam. We are not rewriting OTP, regular OTP is used in Gleam. Most commonly the typed Gleam APIs for OTP are used, but you can use the untyped Erlang APIs if you wish.
This is the same as in Elixir, where macro-enabled APIs are offered, and they just wrap the regular Erlang APIs.
Re: Elixir v1.20: Now a gradually typed language
#99Earlier quoted context omitted.
Elixir's gradual type system cannot change the asymptotic complexity of your programs. The design explicitly rules out mechanism that causes slowdowns in other gradual type systems (runtime casts at static/dynamic boundaries) Most gradual type systems insert coercions when values cross the types/untyped boundary (checking every element of a list, wrapping values in typed proxies, etc) but Elixir's team published a "s…
i think the design can push people into writing unnecessary matches/guards just to trigger the typechecker. that said, I'm a fan
That can be a concern indeed but it is worth noting that strong arrows compose/propagate. So if you have a function without guards that calls a function that guards on said types, the caller is also strong! We will likely have mechanisms to measure "strength" when we introduce type annotations.
Re: Elixir v1.20: Now a gradually typed language
#100How does it compare to Gleam? Or rather, why use Elixir over Gleam now? I suppose Phoenix and Live View in particular are big draws to Elixir.
Do you like Rust or do you like Erlang? Writing Gleam is like writing Rust, writing Elixir is like writing Erlang. I don't know the current state of Gleam OTP, but last I checked it wasn't great. If you don't care about either of those things and only about types, use Gleam. But then why not just use Rust?
Hi, I'm the lead maintainer of Gleam.
> I don't know the current state of Gleam OTP, but last I checked it wasn't great.
Gleam uses regular OTP, it doesn't have a distinct OTP framework separate from other BEAM languages.