Adapting to Elixir, coming from C# and Typescript

[aochagavia]

Two months ago I started working professionally on an Elixir project. I had no previous Elixir experience, but I am picking it up at a reasonable pace (previous experience with Rust, Haskell and non-blocking programming in general have proved very useful). One of the things that I find myself missing is the top-notch IDE support I used to have in C# and Typescript, which gave me an incredible productivity boost and made it possible to find my way in new codebases very quickly. Unfortunately, IDE support for Elixir is quite basic at the moment, and my productivity suffers from it (though the fact that I am still learning the language also accounts for the productivity hit). Did anyone here have to adapt to Elixir coming from statically typed languages with great IDE support? How did you adapt?

Some concrete things that boost my productivity as a programmer, which I find myself missing, are:

1. Find all usages of functions, modules, struct fields, etc.
2. Rename functions, modules, struct fields, etc and have their usages automatically updated.
3. A strict compiler that catches type errors, enabling things like “type-error driven development”, where you change something and chase the compiler errors until everything is fixed (it is almost magical to fix all errors and see that the change you introduced “just works”!).

Without these features, I notice that I am much less confident about changing existing code, which I find problematic, because frequent refactoring is often necessary to keep a codebase healthy. Writing new code is not a problem, though.

For the time being, I am using plain textual search a lot (which doesn’t really cut it given the size of the codebase, but I know of nothing better at the moment), using @spec wherever it makes sense (it is not as nice as proper types, but it helps a bit) and writing tests to ensure everything is working properly (ExUnit is great).

By the way, I understand that many of these features are incredibly complex or even impossible to have in a language such as Elixir, so it is probably not a matter of waiting until the tooling gets better. That is why I am looking for ways to adapt my workflow as a programmer, since I assume I am not the first one to stumble upon these obstacles.

I’m looking forward to your suggestions and insights!

[cmo]

3. I don’t know if the IDE is responsible for providing a type system. That’s surely not how C# works

Have you tried intellij with the plug-in?

[krstfk]

I’d recommend you let it go and use testing (unit testing and property based testing) to get to the same level of confidence. If you write idiomatic elixir/erlang code you’ll end up writing pretty robust code (although it might hard to use OTP abstractions at first).
Neovim’s support for elixir through LSP is pretty good and the IntelliJ plugin is nice.
However when I was taught programming it was with a pencil and paper…

[asianfilm]

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).

[AstonJ]

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:

Which code editor or IDE do you use? (Poll) (2022 Edition)

We last posted a poll like this in 2017 - here’s an updated version for 2022 - this one is slightly different… You can select up to 3 - just pick the ones you use most poll If you are using a Vim or Emacs variant, please say which one in the thread - general thoughts or comments also welcome.

Do you use Dialyzer in your projects?

Do you use Dialyzer/Dialyxir in your Elixir projects? poll If you only use it in some of them, which ones? If you don’t use it, why not? If you do, any thoughts or experiences you’d like to share?

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:

Elixir for Programmers, Second Edition (PragDave)

[Screenshot 2021-11-14 at 13.30.44] @pragdave has just released the second edition of his course - it looks like it’s changed quite a bit since the first edition so am posting it as a dedicated thread. A Little History This is the second edition of this course; the original was written in 2016. Perhaps surprisingly, the Elixir language itself has not changed much in the intervening years. Some of the tooling works a little differently, but not enough to worry about. The major changes are in…

[crova]

@aochagavia

Find all usages of functions, modules, struct fields, etc.

Take a look at Compilation tracers , it’s not going to be on the IDE but you could probably write a tracer to dump to a file and use your IDE’s go to file/definition to jump around.

[aochagavia]

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.

[axelson]

@aochagavia

One trick I am already applying is to use structs for GenServer state, and pattern match on the struct when handling messages

I’m a big fan of that

A library that I’d recommend you look into if you’re working with a decent sized code base is Boundary: Boundary - enforcing boundaries in Elixir projects

It’s great for enforcing some architecture/boundaries on a code base and it can also generate nice images of the boundaries that you’ve defined in your application.

[cjbottaro]

@asianfilm

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.

Heh, this.

To OP, welcome… and welcome to dynamically typed languages!

For me, Elixir is the perfect balance between Ruby (dynamically typed, interpreted, aka literally zero static analysis) and something like Rust (statically typed, compiled, very strict static analysis). The compiler and dialyzer warnings are enough for me to be happy in dynamically typed land. But it won’t give that ease of refactoring / IDE support as in a static typed language.

ElixirLS in VS Code is pretty awesome though.

[cjbottaro]

@aochagavia

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.

Behaviours (kinda like functional interfaces) are nice also and will generate compiler warnings.

[cjbottaro]

@asianfilm

Elixir is not (and is likely never) going to give you the type-driven development experience of Haskell.

I have high hopes for the gradual typing systems being worked on. See Gradualizer and Gradient.

[sabiwara]

@aochagavia

Rename functions, modules, struct fields, etc and have their usages automatically updated.

This library has just been published, I haven’t tried it yet and it seems fairly early stage but it could be helping with the refactoring story.

@aochagavia

A strict compiler that catches type errors

I understand that Dialyzer and typespecs do not provide the experience you’re looking for, but the new missing_return and extra_return flags added in OTP25 are quite a nice improvement. I was never able to turn on underspecs/overspecs due to the amount of false positives, but the new flags are catching legit type errors.

[wfgilman]

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

[bmitc]

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.