You raise some good points but

maximum' :: (Ord a) => [a] -> a  
maximum' [] = error "maximum of empty list"  
maximum' [x] = x  
maximum’(x:xs) = maximum’(xs)

In Haskell is logically wrong, and type checks. If you want probably correct software you need a theorem prover and it’s a whole new level of difficulty, that most of us can’t afford.

While true, that with some assumptions and a type system on par with the Haskell’s type system you can go a long way when refactoring ( I would highly recommend the https://www.cs.ox.ac.uk/publications/books/functional/
book to get an idea of what it’s about), it’s not a way to prove your software is correct.

We also have some pretty great tools to insure correctness : dialyzer + prop check + unit tests can go a long way.

Not to say that you’re wrong to want a strong/static type system. I wish I had it when working with elixir or erlang, but then again, the benefits of the os_like ecosystem and the simplicity of these languages compensate the lack of static typing for me.

Sure, your point is well-made. I don’t believe passing type-checking means software is inherently correct anymore than I believe than dynamic types means software can’t be correct. It’s just a tool in the belt and one measurement of several that matter, but I find it a very useful one even so.

I don’t disagree, and that’s actually why I don’t feel this thread is very useful.

When I started working in my current position I was tasked with looking for an alternative to the tech stack (LAMP) for our web apps. I did not want to go on with the p, I hate it, irrationally. I’ve considered a few languages including ocaml, haskell, scala, rust, erlang, elixir. For each of those I’ve evaluated the costs and benefits for my use case and settled on elixir although there are things I don’t like here either (eg: lack of static typing, syntax, variable shadowing by default and pin operator…).

I’m not concerned because it’s niche. The beam is not.

What I’m trying to express is that companies/individuals may have valid reasons to ditch Elixir/erlang, but these won’t necessarily be reproducible.

Also, it’s fairly easy to interact with the outside world with nifs, ports, c nodes, Java nodes, or message queues

Of course you wouldn’t write a cli unless in elixir unless you had to, nor a desktop app (although observer and wings3d would be counter examples).

If this thread isn’t useful (and I certainly understand why you say it is not), as a newcomer I certainly find it interesting.

Not having built anything other than a toy app so far, I’m getting a little nervous about deployment. Libraries struggling to find maintainers is another thing that concerns me. Both these points I have come across before this thread, though, so can’t say I learned about them in this thread.

Personally, I couldn’t care less about static typing (Elixir being dynamic was a big attractor), syntax, or any of that. The most annoying thing about the syntax for me was that coming from Ruby, I kept thinking I was in Ruby which would slow me down, but I got over that. Otherwise, I’m pretty into the syntax—even the pin operator! Maybe going with prime and no re-binds would have been nicer, but it took me very little time to get used to pinning and the amount of times I rebind I single var in a function is far more than I pin.

ANYWAY

@shanesveller, I’m interested to hear more of your thoughts on hot code reloading if you would. I understand what it is, but I don’t fully understand its implications and why it wouldn’t be desirable (again, I’ve never deployed anything Elixir or Erlang). I’ve always thought of the pursuit of vanity as throwing as many services and acronyms into your tech stack as possible… deploying with just your language and getting zero-downtime-for-free seems like a very noble pursuit to me. I do understand that not everything can be done with OTP, but how far it can seemingly get you, especially in the greenfield phase, is very attractive to me.

Of course, I’m also the type of person who will read about a new tech craze and 9/10 times think, “Damn, that’s really interesting, but I hope I never have to use it!!! …and oh lord I hope my employer doesn’t find an excuse to start using it…”

I might be a little off base here, but I’m very curious about all of this. As a beginner I would love to see deployments mix release right up front and centre in the language’s marketing material. I mean, Phoenix is already spouting NO JAVASCRIPT why not NO DOCKER! I dunno, again, I may be off base here.

It’s a fairly new addition to the language, though. There was distillery before(and still is!), but before 1.9 releases weren’t so “blessed” by the language itself. Now reading the docs to run mix release with a :tar step configured is all I need, really.

Considering the latest updates to elixir that focused exactly on configuration and releases, why is it the case now?

I don’t quite get what you mean with that, but for this part:

The core team seems to agree with you.

However, the language is designed to be extremely good at solving a family of problems that made them sacrifice static typing, so it’s a matter of tradeoffs. Considering that, I doubt there is something to be done as it’s a non solved issue and there’s active research going on. Sure, you can interop Gleam with Elixir for the pure, not message related parts, but I feel it as strange as when I try to mix ReasonML with JavaScript, in those cases type-safety is still very hard to achieve. And don’t get me started on TypeScript unsoundness and HORRIBLE web api bindings.

However, while possible for the adventurers, many of those fields are non-goals for the language. This reminds me of the bad usage of the language/libraries that hurts marketing, such as people trying to develop games with LiveView(that I can’t even play because I live at the other end of the world and latency is of at least 300-500ms) and shadowing the usecases that make it unique and tempting.

But Rust is far from being a 1:1 replacement for Elixir, at least not out-of-the box(and I’m not sure there’s something like the BEAM for rust. Emphasis on for as afaik theres a beam implemented in rust).
Elixir and Erlang are all about the guarantees they offer, not only about memory safety or “async capabilities”.

In your gist you mention:

Error handling with tagged tuples is fairly verbose, and we didn’t always have with as a special form, which helped a lot. Similar to my comments above, it’s something that needs intent and attention to handle correctly, because “forgetting to check for nils and errors” is not something that the compiler will call you out for.

But I must say that’s also true for Rust, OCaml, Haskell, Gleam… with the Option/Maybe and Result/Either types. You may also see tagged tuples as ADTs. Sadly, I feel implementing proper abstractions from category theory like those seem odd even in this functional language and such formal ideas are a barrier for people coming from non functional languages. Also point-free style is odd with capture syntax.

It is not my intention to question your reasons, you’ve invested several years on it and you clearly know why you do what you do, moreover I agree with the points I haven’t quoted, but as mentioned in this reply there are many hidden stories behind the opinions we form over time and it’s hard to extract a general gist of where and why are we failing, as it is needed to make case-by-case studies.

This other article from Fred Hebert is a good take on why people come and leave from the beam ecosystem and where value really is.

PS: I rewrote this reply several times and I hope it came out as something productive and not fueling a circular discussion.

You may have missed my point… I’m not saying that I was expecting to see release mix up front and centre NOW—I know it’s relatively new. I’m saying that I hope beefing it up is a priority and that one magical day in the foreseeable future we’ll seeing, “Elixir is a dynamic, functional language designed for building scalable and maintainable applications with a kick-ass, brain-dead deployment process—no Docker or Kubernetes required!” (there is definitely some hyperbole in there). If there is signal out there that this is on the roadmap, please point me to it! I’m very much talking in terms of attracting newcomers here (as well as wanting it for myself, of course).

Otherwise, when I do go to release, I’ll be pinging you for pointers

And now that I’ve written that reply and read the rest of your post, thanks for the link to the core teams take on hot reloads!

I’ve digested more of your post its various links (I’ve worked my way through a bit of Fred H’s blog but had yet to get to that one) but in particular I’d like to respond to the aforementioned link about the core team’s take on hot code reloading.

I understand their rationalization but the problems associated with hot code reloading seem on par with—if not even easier to reason about—zero-downtime-deployments involving structural DB changes in any language’s ecosystem. It seems like a hot code deploy is max two deploys whereas some DB migrations could be get to five or more deploys with a larger blast radius codewise.

Again, I’m new and might not have the whole picture.

I would also like to acknowledge that I do realize I’ve been conflating hot code reloading and general deployment wishes in my posts.

Edited to add: Wellllll ok, if you had to treat every deploy this way, I could see it becoming a burden.

I agree with this and have seen it many times on this forum and various community chats, which is actually why I wrote a blog post about it to try and help. That said, with config/runtime.exs coming in Elixir 1.11, I’m hopeful we’ll finally have a unified configuration system. I just hope we can get generators of popular projects like Phoenix to embrace it quickly, or it will be like string formatting in Python – too many choices for newcomers.

I just want to be a little picky here about release handling. It is NOT a language or libraries feature, there has been support in OTP from very early for releases. Support both for building them, see the :systools module in the SASL application, and for doing configuration at startup time. It is the mix tool which in the beginning chose not to provide support for building releases. I don’t know why.

And I really agree Fred Hebert has written some really interesting and good stuff, both books and articles, which are also extremely readable. His Learn You Some Erlang also describes releases .