I think elixir would be the best functional language available if it had a HM type system.

Currently, I have programmed professionally in Scala only, and I don’t miss it at all. The complexity of managing to exist in that ecosystem was unbearable, you just never know what to expect. One minute you’re coding like it’s Haskell, and then the next you’re dealing with some huge inheritance hierarchy, and implicits OMG, don’t get me started. I still have nightmares about SBT. I will never accept a job using Scala again.

Other than that, I have written programs using Kotlin, and F#. One thing Elixir, Scala, Kotlin, F#, Clojure all have in common is that they are all built on top of pre-existing platforms, and this is where ( so far ) Elixir outshines all of the competition to me. In Kotlin, Scala, and F#, as soon as you pull in a dependency from the Platform ( jvm / .net), you are right back in OOP land, which defeats the whole purpose. Sure you get access to a huge ecosystem, but at what cost? To some, it may be worth it, but to me, it’s not.

My job requires me to program in Go, which is not as bad a language as a lot of people make it out to be, but if you think functionally, it sucks. For me, Elixir is like the Golang of the Functional programming world, to some that may sound like an insult, but it’s not. Elixir is super simple, and simplicity is hard. Go is unapologetically procedural and it makes very few compromises. It’s a very stripped-down language that gets out of your way and lets you do everything you need to do in order to get work done ( albeit very procedural manner ) and has very good support for concurrency. I would choose it over any OOP language available in a heartbeat.

Elixir is the same except for it lets you do everything you need to do in a functional manner, and it ( like Go ) has great support for concurrency and makes no compromises about what it is. It is not a confused language and it did not have to add language constructs that do not fit its paradigm in order to adapt to the underlying platform, I like that a lot.

Re: arguments - it’s quote easy to add types to function arguments (guards and inline stuff like fnname(foo = %Abc{}). For me that’s good enough level of static typing

As mainlymortal mentioned auto-completion for struct fields is supported within struct definitions for ElixirLS. In practice (for me at least) this isn’t too large of an issue because I generally prefer pattern matching out fields of a struct because then the code will fail to compile if I change a field name. If you use the my_struct_instance.my_field version then you will get a runtime error if you rename your field from my_field to my_better_field. So instead I typically do %MyStruct{my_field: my_field} and then use my_field in the rest of the code.

I suspect that Dave may have either been using Alchemist.el (unfortunately no longer maintained), although I’m not sure if it has the feature that you want, it may have been using some type of heuristics to guess the variable type (or that could have been supplied by some other emacs plugin).

Thanks for the reply, I think that what is provided by the plugin will be fine for now, I just need to adjust my code to what you advised, pattern matching seems like much more idiomatic elixir approach than accessing struct fields by name.

I do think it would still be a nice added feature though.

Yeah, I agree that it would be a nice feature. An PR’s that implement that would most definitely be welcomed