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.
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.
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 https://youtu.be/Jf5Hsa1KOc8
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.