How have you introduced Elixir in your company?

One consideration here, presuming that adoption involves mid-to-long-term insights, is considering if the (presumably) coming Set Theoretic Typing bridges the gap sufficiently for your team and if that wait is feasible. Naturally it might be neither sufficient nor timely, but it’s worth thinking about.

Existing typing tools like Dialyzer I think could be helpful in at least creating greater surety about typing issues, but it has its own issues and doesn’t go near as far as static typing. In the end its a mitigation that at least helps handle the perception that you’re working without a net.

I’ve worked on a very large Ruby codebase where the lack of static types wasn’t a (big) problem and even as it stands today, pattern matching makes Elixir a much more solid dynamic language than Ruby. yet, I’ve worked on a very confusing Elixir codebase that wasn’t even that big. It really comes down to the developers and your company’s practices.

I think the biggest issue you would probably face is having Java developers trying to bend Elixir into the patterns they are already comfortable with. I think this is probably the biggest problem with any big language change at an org.

I could have being more specific, but it’s mainly Scala. Which is nice because they’re already familiar and like the functional approach, but worse because they want even more types. I’ve stayed on meeting when the devs were simply discussing the correct way to represent an ID for hours. I like types, but this is mind blowing

Oh my…

Although I was recently on a call where we spent 20 mins trying to figure out if something was actually centred in a div (which is, of course, impossible ) so ya…

Ah ya, probably a little better for sure, but Elixir is still a bit of a special flower, lol. My experience of people making messes trying to shoehorn other language concepts has been from one OO language to another OO language so I’d just be cognizant of it, is all.

I have worked with a codebase with 20k+ source files. The types were never a problem there, for a few reasons:

• the architecture of the project enforced some pretty clear rules about the code design;
• the development/maintenance was being done by skilled engineers, some of the best I’ve worked with so far;
• the project had a lot of tests and each bugfix/feature was accompanied by more tests.

At the same time I think the concern you are having is valid but I would address it the following way:

Is designing software in elixir a risk when it is done in the same manner as in static typed languages or other paradigms?

I would answer to this question a resounding yes. I’ve seen small projects designed by newcomers to elixir in the same manner they used to do it in other languages and sometimes it can get really bad, like so bad that you lose all the benefits of the ecosystem. In those projects everyone starting from business people to developers are not happy and in the end they migrate to another ecosystem sooner or later.

In order to avoid that, I highly recommend hiring a veteran elixir developer, that can teach your team the dos and don’ts. If you’re up to the task you should do it yourself, I can’t stress how vital that is for a good elixir adoption and a successful project.

Language choice is religious and unless you have considerable influence, no amount of reasoning will help persuade people to use an alternative, even if you believe it will benefit the company. People will always find a reason not to use it - not because of the reasons they say, but because they want to use what they know is accepted in their current and future careers, and because significant change is risky.

I was lucky enough to be in a position to guide the choice of development platforms at my last role. We started out in Go, mostly because I had trouble previously in large Python codebases and junior developers not respecting data types.

Go has exceptional concurrency and is very explicit, making reading through codebases much much easier. However, we ended up switching to Elixir for better concurrency primitives and error recovery.

You definitely need better testing to avoid type errors in Elixir, despite the pervasive pattern matching. I would actually not put the blame on elixir though, but rather the lack of exhaustiveness checking. Misspellings in atoms and map keys proved to be the biggest issues for us, but these seem to be all issues that are in the process of being addressed.

I would like to add one minor point though, transitioning to elixir did lead to an overuse of structs. The team was very used to thinking in terms of types for every data-type getting passed around.