28 days of Elixir - Development Environment
Welcome to day 1 of (hopefully) 28 days of Elixir! I’ve set a goal to write a technical blog post every single day this month, and I’m really excited about Elixir right now. I don’t know what the entire series will bring, but I do know that I’ll basically have to be putting all of my thoughts and experiences about Elixir out there over the next month.
I’m going to start this series off with something light: development environments. Specifically, the one that I use and things that I’ve found enjoyable coming from another language like Ruby or Javascript. I don’t intend to convince anyone of anything on this (especially with regards to editors), but I do think there’s some interesting things about Elixir specifically that can apply to every environment. Let’s jump in.
Elixir Installation
I use kiex to manage my elixir versions and kerl to manage my erlang/OTP versions. kiex has been great, it’s really easy to use! I have to say that I’m genuinely impressed with how little speed bumps I’ve encountered over time. I do recommend using some sort of version manager rather than brew, because there will definitely be more than one project in Elixir over time!
kerl on the other hand, has generally been fairly painful to use. I think the biggest thing here is that Elixir versions need recompiled once OTP is changed. I could be wrong here because I haven’t had to do it too often, but I do distinctly remember significant pain from the OTP 20 upgrade. This happens very infrequently though.
One thing that I wish kiex had was the concept of a .elixir-version file like rbenv. It has to be done manually right now, which is error prone on a team.
My Editor
Although I’ve tried to get into other editors over time, I have found myself drawn again and again to the simplicity and flexibility of atom, so that’s what I’ve been using lately. There are 3 packages that I use specifically for atom that are, I think, absolute must haves: atom-elixir, language-elixir, elixir-jump-around.
atom-elixir and language-elixir provide the base for the actual act of authoring code. The auto-complete functionality works generally well, although there are some core quirks. Due to how Elixir compilation works, tools like atom-elixir look into the actual _build output of the code to produce auto-complete and documentation services. This is really interesting to me, because it means that any editor should be able to accomplish that same task. Whether emacs, vim, vscode, whatever is being used, it should be completely achievable to have full auto-complete and documentation capabilities.
In addition to great auto-complete capabilities, atom-elixir has a really good “go to definition” functionality. When I am authoring Ruby code, I find that only Rubymine has been able to achieve true definition jumping. ctags can provide some of it, but jumping into installed libraries is very useful for debugging problems or understanding how a method works. For example, do you want to know how an Enum method is implemented? Just alt+click and you’re there! Elixir’s compilation design makes this all possible in any editor, not just a Jetbrains editor. Check it out!
Lastly, “jump to test” is so useful for me. My typical flow for creating a file has become:
- Create the module in my lib folder somewhere
- Press opt-g-t to jump to the non-existent file
- Copy the module definition, add Test to it, then save the file
I’m able to do this entire flow very quickly and without navigating a file tree.
Docker vs Native Execution
Some people really like to develop software on the OS that is going to run it in production, and more power to them! However, I’ve found myself drawn to having software that is runnable on my macbook, natively, rather than using a tool like Docker or Vagrant. However, I do utilize Docker for CI and production build processes.
Mix Format
I’ve begrudgingly accepted the mix formatter over the past few weeks. I find that I often have issues with getting a file to format in certain situations. This seems like a bug in the formatter, though. The format itself is generally agreeable but sometimes is not and there is no customization route. I think that it’s better to accept a standard, even if it’s not my desired standard, if it improves the community and team at large.
I run this manually as I go. Now that I think about it more, I should probably have this setup in some semi-automated fashion until it becomes too slow.
Wrapping up
That ended up being longer than I anticipated, but I’m still sure there are many things I didn’t cover. Feel free to reach out if you have any question about how my setup works or if you have awesome tools that you can’t live without!
See ya tomorrow hopefully! It is only day 1, so we’ll have to see how it goes.