Erlang vs Groovy: What are the differences?
What is Erlang? A programming language used to build massively scalable soft real-time systems with requirements on high availability. Some of Erlang's uses are in telecoms, banking, e-commerce, computer telephony and instant messaging. Erlang's runtime system has built-in support for concurrency, distribution and fault tolerance. OTP is set of Erlang libraries and design principles providing middle-ware to develop these systems.
What is Groovy? A dynamic language for the Java platform. Groovy builds upon the strengths of Java but has additional power features inspired by languages like Python, Ruby and Smalltalk. It makes modern programming features available to Java developers with almost-zero learning curve.
Erlang and Groovy can be primarily classified as "Languages" tools.
"Real time, distributed applications" is the primary reason why developers consider Erlang over the competitors, whereas "Java platform" was stated as the key factor in picking Groovy.
Erlang and Groovy are both open source tools. Erlang with 7.74K GitHub stars and 2.1K forks on GitHub appears to be more popular than Groovy with 1.49K GitHub stars and 414 GitHub forks.
According to the StackShare community, Groovy has a broader approval, being mentioned in 79 company stacks & 73 developers stacks; compared to Erlang, which is listed in 70 company stacks and 47 developer stacks.
What is Erlang?
What is Groovy?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using Erlang?
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
Postmates built a tool called Bazaar that helps onboard new partners and handles several routine tasks, like nightly emails to merchants alerting them about items that are out of stock.
Since they ran Bazaar across multiple instances, the team needed to avoid sending multiple emails to their partners by obtaining lock across multiple hosts. To solve their challenge, they created and open sourced ConsulMutEx, and an Elixir module for acquiring and releasing locks with Consul and other backends.
It works with Consul’s KV store, as well as other backends, including ets, Erlang’s in-memory database.
Some may wonder why did we choose Grails ? Really good question :) We spent quite some time to evaluate what framework to go with and the battle was between Play Scala and Grails ( Groovy ). We have enough experience with both and, to be honest, I absolutely in love with Scala; however, the tipping point for us was the potential speed of development. Grails allows much faster development pace than Play , and as of right now this is the most important parameter. We might convert later though. Also, worth mentioning, by default Grails comes with Gradle as a build tool, so why change?
Another major decision was to adopt Elixir and Phoenix Framework - the DX (Developer eXperience) is pretty similar to what we know from RoR, but this tech is running on the top of rock-solid Erlang platform which is powering planet-scale telecom solutions for 20+ years. So we're getting pretty much the best from both worlds: minimum friction & smart conventions that eliminate the excessive boilerplate AND highly concurrent EVM (Erlang's Virtual Machine) that makes all the scalability problems vanish. The transition was very smooth - none of Ruby developers we had decided to leave because of Elixir. What is more, we kept recruiting Ruby developers w/o any requirement regarding Elixir proficiency & we still were able to educate them internally in almost no time. Obviously Elixir comes with some more tools in the stack: Credo , Hex , AppSignal (required to properly monitor BEAM apps).