Consider writing your core business logic in Gleam because Elixir is not (and is likely never) going to give you the type-driven development experience of Haskell.

I have a modern 50,000 line Elixir codebase that uses best practices like Credo, Dialyzer and test suites for its core business logic and it never gives me enough refactoring confidence.

I’m considering moving its core business logic to Gleam, which has a lot of Elm influence, and some new IDE support in its latest release (but that aspect is also still a work-in-progress).

Thanks for your answers! I forgot to mention I am currently using vscode with the ElixirLS and Elixir Test extensions. I assume other IDEs offer a somewhat similar development experience (btw I tried IntelliJ a few months ago, but it didn’t work as smoothly).

Right now it looks like I will need to get used to basic IDE / compiler support and hope the features of the language compensate for that. Some that are already proving very useful are:

1. Process as a first class citizen (I really like the idea of putting state in processes rather than objects, because you are forced to think up-front about supervision)
2. Easy multi-node programming (I recently had the joy of using a replicated Nebulex cache; with just a few lines of code, everything magically worked, whereas in other language I would have needed to deploy an additional service like Redis)

My hope is that these and other benefits will in the end outweight the limitations caused by lack of static typing (and the great IDE they usually enable). Thanks to @AstonJ for pointing this out!

Now if anyone has any tricks to keep a codebase maintainable, I’d be glad to hear them (maybe there is a cheat sheet somewhere). One trick I am already applying is to use structs for GenServer state, and pattern match on the struct when handling messages, so you get compiler warnings if you try to access non-existent fields and get autocomplete support in the IDE.

For what it’s worth, in Jose’s 10yr talk he speaks about prioritizing the IDE experience to make Elixir more accessible and make the learning process easier. It’s toward the end of the presentation here Celebrating the 10 Years of Elixir | José Valim | ElixirConf EU 2022 - YouTube

Hi @aochagavia! I also came to Elixir from statically typed languages, one of which was F#. I am still struggling a bit with Elixir to a degree because with dynamic languages, there seem to be a wide variety of different styles of programming. For me, I find it unacceptable to have to read a function’s (and its subfunctions’) implementations to understand what it does. I want @typedoc and @spec and the function and argument names to tell me that. I don’t think you’ll necessarily find that in most Elixir codebases. However, many seemingly seem comfortable moving through such codebases and making changes. I’m simultaneously impressed but also suspicious, because I have found several bugs because of this in those codebases.

For me personally, I use Visual Studio Code with the ElixirLS extension (ElixirLS: Elixir support and debugger - Visual Studio Marketplace). The extension plus features of Visual Studio Code can help somewhat for your (1) and (2) but definitely not what you’re used to with Visual Studio (I presume). But as far as I know, it’s about as good as you’re going to get right now. For (3), ElixirLS will dynamically display type information, but it’s usually way too generic to be useful. I personally shoot for 100% coverage of typespecs (I see almost no reason not to) and then use Dialyzer. Dialyzer is not really a type checker. It’s sort of its own thing, but it’s as close as you’re going to get to help with this.

In Elixir, you can accomplish type-driven development, and this is definitely something I strive for. Use structs as much as possible and define @type t() :: ... for them so that you can use that type definition in modules that use your structure, including in the module that defines that struct with __MODULE__.t(). I also heavily use @type definitions to create domain-specific types that help make my code easier to read and understand, while also utilizing Dialyzer.

For the most part, I’d say 95% of code away from I/O and process/message boundaries in Elixir and Erlang does not need to be dynamic. So, I treat if it was statically typed via detailed @spec usage, clear argument names, custom @type definitions, and using Dialyzer.

This is certainly an opinionated stance, but I personally see no other way to write solid code that is easily read and maintained and can onboard new developers.

There is no fundamental reason why an advanced and modern IDE experience doesn’t exist yet. It’s just that Elixir is new and it hasn’t been taken on by somebody.

Welcome Adolfo!

Something we often tell people coming to Elixir from Ruby is that despite how it looks with the obvious Ruby influence on syntax, Elixir isn’t Ruby and there are some stark and fundamental differences.

So that’s something I would say here too - keep in mind Elixir isn’t C# or Typescript and while you may be leaving some things from those ecosystems behind, you will be gaining others (for instance, whatever the reasons might be why you have found yourself working with Elixir now).

With regards to working with Elixir itself, you might find these threads interesting:

Personally I think neovim is great, and if you want to see it in action (as well as Dialyzer) you may want to go through PragDave’s course: