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 "strong arrows" result specifically to achieve soundness without those runtime checks. The bytecode the compiler emits is semantically identical to untyped code.

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 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 types were introduced.

> you don't get bugs related to typing because elixir is somehow magic,

I've never followed Elixir particularly closely, but what I saw in some Erlang discussions was different. Discourse there was that you need to gracefully handle failure anyhow, so type errors can (should?) just get handled by the failure recovery machinery you're supposed to have anyhow. I disagree with that point of view, but it's much more defensible than "$LANGUAGE is magic".

It was the same thing with javascript/typescript and python. Sometimes you just have to let people think what they want.

I think Elixir is interesting and there is real value but some stuff being sold as "all these libs/packages that haven't had any updates for over a year is fine because Elixir" I just don't buy it

and to that point around typing feels like the same wish-washy hand waving from the community that is very off putting

BEAM has genuine use cases but its not as wide as its made to believe. There are very good places where that is a perfect fit but it simply cannot upend Typescript.

Elixir feels very similar to how Clojure started getting traction and then ultimately forgotten apart from its die hard fans, I'm not saying Elixir will go the same way but seems very hard for something new and bold to replace what is popular and boring.

I do want Elixir to succeed (also Clojure as well and I advocated for it for a bit) but the low number of jobs still puts it in similar proximity to Clojure but BEAM I think would still provide uplift where Clojure simply could not

Please share that conversation you reference where the community said Elixir doesn’t need types because it is magic.

> you don't get bugs related to typing because elixir is somehow magic

Really? All the Elixir fans were saying that?

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?

Phoenix and Ecto, really.

Check Gleam website, they have the comparison right there.

Gleam doesn't have macros, which many Elixir libraries (such as Phoenix and Ecto) uses to great effect.

Gleam for example has issues with verbosity of decoding/encoding json whereas in Rust you derive serde and in Elixir it's just a function call away.

Elixir has a more mature ecosystem. While you can for example use Phoenix with Gleam (or some other Gleam framework) the experience just isn't the same.

The big draw with Gleam over Elixir is the typing (where Elixir is now closing the gap) and being able to compile to JavaScript (which is also what Hologram is doing for Elixir).

I prefer Gleam's typing system and the Rust-like syntax, but for now I feel Elixir is the better choice for all my web dev projects.

https://pragprog.com/titles/lhelph/functional-web-developmen...

don't let the title fool you - the first half of the book is just elixir

over the past 8 years this is the book i've used to ramp back up on elixir and it works like a charm every time - i've never finished it

for me, a mark of a good programming book in this tutorial-project style is that I have started it half a dozen times and never finished it because at some point before the end I've been equipped w/ the tools to go off and do my own thing

> I love everything about Elixir, but Elixir constantly makes me doubt myself like no other language. My brain isnt made for functional stuff, but this makes me want to try again.

I experienced this really painfully when I was in college and took a kind of "survey of programming paradigms" course and tried Haskell for the first time. I'd been programming for years by then, and I couldn't believe how helpless I was at trying to complete things that had long felt "basic" to me.

But I don't think it's about the brain not being suited, I think it's that contrast of your experience level in imperative languages vs. the fact that when working in a pure functional style, you start out as a newbie again.

I think you'll gradually improve. I think the thing that finally made functional programming feel comfy for me was realizing how much I love composing code that basically feels like more generously spacer Bash "one-liners". The data starts out in one shape, so you run a command to dump it. Then you think of a step that gets it closer to what you want, you pipe it to that next command, and you take another look. And you keep going and at the end what you're looking at is typically pretty close to a series of transformations of data that you never mutate!

Part of what makes this feel comfy in the shell is that you build up that vocabulary of commands just by puttering around your file system every day. Over the years my library of familiar "functions" in a Unix-like environment has grown quite large. In a pure functional programming environment, you have to do the same thing but it takes a little more effort to learn the vocabulary. Your most frequently used "commands" will be functions like map, fold, and zip instead of grep, cat, or sort. But the core of it is really the same, and what I love about building pipelines applies equally to both: you can build it piece by piece, and for each puzzle you're on, you can forget about the previous steps and just think about the next transformation of the data that's in front of you. There is something refreshingly, relaxingly low-context about that.

Anyway I hope you give it a try and enjoy it. When we can learn to enjoy being bad at something, that's how we finally get good at it.

I invite you to ask on ElixirForum. I have never seen a truly hostile response.

Sometimes posts don't get traction due to ambiguity, and some smelled like "do my homework" so people ignored them.

But every post with a genuine curiosity in it gets answered, as far as I can tell.

Do you maybe know some Rust? I'm also not that experienced with FP languages, but Gleam felt familiar enough, due to some Rust-isms, to allow me to focus more on the concepts rather than the syntax. Granted, I spent a few afternoons with it, but if I were to pick a FP language again to wrestle my brain into submission, I'd probably go with Gleam due to familiarity.

Comments like this always confuse me as object oriented programs riddled with state are much harder to reason about to me.

Do https://htdp.org and follow all the exercises carefully (yes, it will feel like baby work at first) - you will retrain your brain for functional stuff. :-)

What functional stuff is throwing you off? A whole bunch of it can be written procedurally when starting out.

I find beginners respond well to this resource: https://joyofelixir.com/toc.html

community is super nice I am sure you will get help.

That is just wrong.

> You need Beam and the Elixir. I find that really weird, because I'm used to just the language like in Python, Java, C, Rust. Not something underneath it, too

The beam is a VM. You get that Java requires a VM too right? It’s called JVM for a reason. And Python requires an interpreter.

> There is no debugger. The way to debug Elixir is to print stuff to the console, like 40 years ago.

That is false. https://www.erlang.org/doc/apps/debugger/debugger_chapter.ht... and you have observer. And you have a lot of other debugging tools. I hear Java has a good one and maybe it’s better (I never used it) but it’s not true there exist no debuggers for the beam.

Java has the JVM the same way that Elixir has Beam/OTP/...

If you're used to Java, Elixir is like `javac`, Beam is like `java`. Mix is like a (way better) version of Gradle. You need elixir to compile your app, you only need the Beam to run it. Once you've built your project, you don't need Elixir anymore exactly like java/javac. C and rust compile to machine code so don't have a runtime dep, but otherwise they still require you to have a compiler at build time, just like elixir.

To be fair, there is more than just print debugging. You have access to tools like red(x)bug https://github.com/nietaki/rexbug, the Elixir-LS project has Debug Adapter Protocol support. And in my opinion, the REPL (and decent software architecture) makes it easy to investigate your code by just running the functions as needed (even if your live production system if you want).

I genuinely needed that laugh. Thank you

The syntax you are commenting on has always existed in Elixir, before v1.0, as part of patterns and guards.

You are commenting as if we added this now but we have made no changes to the language surface. The difference is that we now leverage these same language constructs to extract precise type information.

You can of course still do the second thing, the types are not forced if you don't want them!