passer-by-123

Both Erlang and Elixir have CI running on Windows and provide installers. I am aware of many using Windows for development, although I am not aware of people deploying on Windows.

While Dialyzer can be handy, it is not a type system.

Elixir/Erlang do have typespecs, which helps on the documentation aspect, but a type system would give much more on the performance and guarantees departments.

Thanks! I would be great if you wrote an article on these with more details, as it would be really helpful to both Elixir and Erlang communities.

A type system will allow you to catch a certain category of errors. There are still whole categories of logical errors and runtime errors, such as the ones that arises with communication with other systems and processes, that you can’t foresee and making sure that your system will go back to a working state in face of those errors is essential.

From this perpective, a type system is a nice to have and a recovery mechanism is a must have.

However, a type system is much more than preventing a certain class of errors. It is documentation, it is a design tool, it can improve performance, and others. Plus, if you can catch errors earlier, why not? At the end of the day, I would love a type system in Elixir, but I am certainly happier that the recovery system is there right now.

While I agree deployment is probably the major pain point, I don’t see a reason to add time zones or time formatting to Elixir, given those problems are well solved in the community with the Timex and Calendar packages. I prefer the Elixir standard library to continue small and focused.

> If all of those extra characters are for extra flexibility (maybe for using more repositories in future?) then it smells of premature optimization. I'll happily do without it.

I wouldn't say it is to use more repositories in the future (I also hate future-proofing code) but rather to make it explicit what is happening on the database side. It aligns well with other ideas in Ecto, such as letting the database do uniqueness checks.

Most of the problematic Rails projects I worked with were because of this coupling between business logic and database that ActiveRecord encourages. But this is nothing new, it is one of the top 3 complaints about Rails.

FWIW, deploying a non-Phoenix app with distillery is exactly the same as deploying a Phoenix app.

Not only strings, but better error messages, the new breakpoint support, functions for working with collections, protocols, tasks, etc. It goes quite beyond tooling.

I think your second point is unfair. It has nothing to do with Ruby but the fact a lot of people are joining the platform. It takes time for them to understand how everything fits together. Most experienced developers I talk to are actually appreciative of Erlang. Elixir also helps a lot since it points developers to use the Erlang libraries instead of wrapping them.

But mostly you shouldn't expect people to grasp functional programming, concurrency and OTP when they are just getting started.

There is no reason to use LFE. It doesn't add anything that Erlang does not have (besides macros) and it is very poor on the documentation side.

Even if you don't like Elixir, it brings more to the table than just syntax and macros, such as tooling, Unicode support, protocols, better error messages, better debugging, tasks, etc.

If Elixir is not your cup of tea, definitely Erlang all the way.

We definitely use databases such as Postgres, MySQL, Riak, etc. It is just that when it comes to ephemeral data, the tools that ship with the Elixir and OTP may be enough. See how Phoenix does the whole pubsub and presence without Redis or similar.

As many others said in the thread, forget about the relationship between Ruby and Elixir, and give Elixir a try. It is much more than syntax: structs, protocols, the test framework, documentation, tooling... even the new error messages and debugger make a big difference on every day development.

There are reasons for picking Erlang over Elixir but if the reason is that "Elixir does not offer anything beyond syntax", it is likely the person has not been paying much attention.

I would say the difference is that you can start small. You can start thinking about functions and data and you can build a large amount of software with the simpler abstractions. I would say this is not specific to Elixir but to functional languages. A good amount of my code is just functions and data. Processes, macros, protocols, etc come only when strictly necessary.

The performance aspect also makes a huge difference in development. The application boots fast and the live reloading experience is rewarding. Having a 100 test cases that hit your endpoint+database running in less than a second is pure joy.

The push to new technologies are not based solely on performance.

Rust brings a type-safe and memory-safe guarantees. Elixir brings concurrency and functional concepts that lead to clearer code. Even node.js has the benefit of ubiquity. Even if you want to debate those claims, those are perceived reasons for people adopting those platforms - just ask them. Having a more scalable and performant platform is just a nice bonus.

It is also misleading to think that performance impacts only the user experience. No, it drastically affects the developer experience too! Over the years the Ruby community has struggled with performance issues. Your application takes a long time to boot? Let's introduce a tool like Spring that works only half of the time. Your application cannot handle blocking requests? Let's push our whole design towards jobs. View rendering is slow? Let's add cache layers over cache layers (aka russian doll caching) and then good luck debugging cache expiration issues.

Even running tests is unnecessarily slow in Rails. When one test is querying the database, another test should be running. I am not talking about multi-core concurrency, just simple IO-based concurrency. Extra points if a language can give me CPU concurrency too!

Those are long term issues that impact the developer productivity and increase the maintenance burden on your teams. That's without taking into account other issues prominent in the Rails community, such as abusive use of monkey patching and global state. I moved away from Rails not because I wanted performance but because I wanted simplicity and long-term productivity.