Elixir is kinda nice. I like their macros, db querying layer and mix and low latency.

But I feel no typesystem would bite me in bigger project.

The type system problem is somewhat mitigated by ubiquitous use of pattern matching. In python, the function

  def foo(mymap):
     blah

Has no real information about what my map is. In contrast, a staticly typed language like Java would have

  public static HashMap<String,Integer> foo(HashMap<String,Integer> mymap){
    return mymap
  }

which encourages you to have a lot of classes defining different types of things, which is rigid, but at least makes it clear what exactly the function is expecting. Elixir is somewhere in between, where you'd write

  def foo(%{"username" => username, "password" => password}) do
     {username,password}
  end

which makes it abundantly clear what the function expects ( a map, with keys "username" and "password"), and handily unpacks those values for you, making it feel more immediately useful than "In the future it'll be nice to have more clear code", which helps with adoption.

In practice, the Python example is likely to have considerable information hidden in the “blah” from which existing tooling can often infer much of what would be declared in a language with mandatory explicit static typing; and it has existing tooling for optional explicit static typing, too.

So does Elixir with typespecs and Dialyzer, but I'm talking about quick, at a glance analysis of a function definition. Which is really the only benefit from a brittle type system like C or Java's, in contrast to a proper type system like Rust's or Haskell's, which have their place and cannot be adequately replaced merely with pattern matching.

Python 3.10 introduces pattern matching: I've not had the chance to really play with it yet so can't say how fully featured it is, but you can do something like:

    def foo(login_data):
       match login_data:
          case {"username": "foo", "password": "blah"}:
              return True
          case _:
              return False

In addition you can use type hinting:

    def foo(login_data: dict[str, str]) -> bool:
        match login_data:
          case {"username": "foo", "password": "blah"}:
              return True
          case _:
              return False

Unfortunately I don't think you can yet do the neat argument unpacking as per your Elixir example, but it's some of the way there.

I don't know that that's the big issue with dyanmicism, at least not for me. In Ruby the main thing that bugs me once in a few months is a silly typo - calling a misspelled ivar or method. It happens maybe once in half a year but it's still humbling when it happens. It's rare because usually your IDE is very good in spotting these mistakes - even in Ruby, and also decently tested code should break right away. But I do wish and hope the tools will become better - whether it's Rubocop or something completely new, that the chance of this happening will be almost zero. It's not there.

I worried about this too, but I found that 90% of the places I want "types" are elegantly handled with pattern matching and what other langs would call "function overloading." I also love that you can treat structs like a map, which I feel is the best feature from javascript.

I feel there's more to the dynamic language world that's not clearly explained by the lack of types. I have used both Python and Elixir for production apps, and I get an order of magnitude more type errors with Python than Elixir, for some reason.

IMO it's a disservice to compare Elixir's typing to languages like Python, and we need a new category to distinguish the two.

The fact that there are a lot of standard behaviours (GenServer, Supervisor, Agent, e.t.c) and conventions followed makes this not such a big issue for me. Dialyzer is also a great tool which catches a lot of errors for me.

I'm in exactly the same boat, and hoping that others follow suit. It feels like "the good old days", but the community is still small and resources are scattered, so sometimes doing simple things mean a bit of trial and error at first. Still, it's actually been enjoyable again.

Elixir & Phoenix comes across as a "full-stack" framework with tons of potential, much more so than Ruby on Rails.

I agree that Elixir & Phoenix are the natural evolution in a post-Rails world, but looking further ahead, I think we've reached a point where the compiled & typed languages are starting to have all the goodies that used to be reserved only for the highest of the high level languages, and with web assembly support on the rise, it's going to start to become possible to use languages like this for both backend and frontend in a unified way. So for me, the next natural evolution is using something like Rust or Crystal but with very solid Railsy conventions and intelligent code sharing between frontend and backend. I think this combined with something like the Phoenix live view, but in Rust, is at least where I want my future to be, and I think a workflow like this could become the dominant pattern before, say, Elixir/Phoenix overtakes Rails.

I tip my hat though to people diving into Elixir --- it is definitely a cool direction and one I would follow if I weren't already so sold on Rust/Crystal/etc.

Well the game has also changed for dynamic languages. Writing JS or Ruby with a powerful IDE today isn't what it used to be 5-10 years ago and it will keep getting better. The tools and linters will become smarter about catching silly typos. It will never be like writing in a compiled language but the gap will narrow. Also - I don't think we'll ever agree on any language. Sure, some languages will be dominant - Java maybe or Rust or whatever, but there will always be room for alternative approaches. Humans don't fully agree on much.

yes, it's true that with sophisticated gradual typing and expressive static langs, dynamic and static languages are far more similar than they used to be.

personally, I still enjoy the extreme dynamism of lisp and lisp-like langs (julia), but we may never see a resurgence of them in popularity

Where Elixir makes everything work is the runtime that allows millions of concurrent processes to coexist without taking over the processor.

I can’t think of another language, even Rust, where you could run a full database inside your codebase without negatively impacting everything else.

That BEAM runtime just makes things possible that aren’t in other languages.