What is Erlang and what are its top alternatives?
Top Alternatives to Erlang
- Elixir
Elixir leverages the Erlang VM, known for running low-latency, distributed and fault-tolerant systems, while also being successfully used in web development and the embedded software domain. ...
- Haskell
It is a general purpose language that can be used in any domain and use case, it is ideally suited for proprietary business logic and data analysis, fast prototyping and enhancing existing software environments with correct code, performance and scalability. ...
- Golang
Go is expressive, concise, clean, and efficient. Its concurrency mechanisms make it easy to write programs that get the most out of multicore and networked machines, while its novel type system enables flexible and modular program construction. Go compiles quickly to machine code yet has the convenience of garbage collection and the power of run-time reflection. It's a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language. ...
- Clojure
Clojure is designed to be a general-purpose language, combining the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multithreaded programming. Clojure is a compiled language - it compiles directly to JVM bytecode, yet remains completely dynamic. Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system. ...
- Akka
Akka is a toolkit and runtime for building highly concurrent, distributed, and resilient message-driven applications on the JVM. ...
- OCaml
It is an industrial strength programming language supporting functional, imperative and object-oriented styles. It is the technology of choice in companies where a single mistake can cost millions and speed matters, ...
- Rust
Rust is a systems programming language that combines strong compile-time correctness guarantees with fast performance. It improves upon the ideas of other systems languages like C++ by providing guaranteed memory safety (no crashes, no data races) and complete control over the lifecycle of memory. ...
- Java
Java is a programming language and computing platform first released by Sun Microsystems in 1995. There are lots of applications and websites that will not work unless you have Java installed, and more are created every day. Java is fast, secure, and reliable. From laptops to datacenters, game consoles to scientific supercomputers, cell phones to the Internet, Java is everywhere! ...
Erlang alternatives & related posts
Elixir
- Concurrency171
- Functional158
- Erlang vm132
- Great documentation111
- Great tooling104
- Immutable data structures84
- Open source79
- Pattern-matching76
- Easy to get started61
- Actor library58
- Functional with a neat syntax29
- Ruby inspired28
- Homoiconic24
- Erlang evolved23
- Beauty of Ruby, Speed of Erlang/C21
- Fault Tolerant17
- Simple13
- High Performance13
- Good lang10
- Stinkin' fast, no memory leaks, easy on the eyes9
- Pipe Operator9
- Doc as first class citizen9
- Fun to write7
- Resilient to failure7
- OTP6
- GenServer takes the guesswork out of background work5
- Pattern matching4
- Idempotence4
- Fast, Concurrent with clean error messages4
- Not Swift4
- Error isolation2
- Dynamic Typing1
- Easy to use1
- Fewer jobs for Elixir experts11
- Smaller userbase than other mainstream languages7
- Elixir's dot notation less readable ("object": 1st arg)5
- Dynamic typing4
- Difficult to understand1
- Not a lot of learning books available1
related Elixir posts
When you think about test automation, it’s crucial to make it everyone’s responsibility (not just QA Engineers'). We started with Selenium and Java, but with our platform revolving around Ruby, Elixir and JavaScript, QA Engineers were left alone to automate tests. Cypress was the answer, as we could switch to JS and simply involve more people from day one. There's a downside too, as it meant testing on Chrome only, but that was "good enough" for us + if really needed we can always cover some specific cases in a different way.
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).
- Purely-functional programming89
- Statically typed66
- Type-safe59
- Open source39
- Great community38
- Built-in concurrency30
- Composable29
- Built-in parallelism29
- Referentially transparent23
- Generics19
- Intellectual satisfaction14
- Type inference14
- If it compiles, it's correct11
- Flexible7
- Monads7
- Proposition testing with QuickCheck4
- Great type system4
- Purely-functional Programming3
- One of the most powerful languages *(see blub paradox)*3
- Highly expressive, type-safe, fast development time2
- Reliable2
- Kind system2
- Pattern matching and completeness checking2
- Better type-safe than sorry2
- Type classes2
- Great maintainability of the code2
- Fun2
- Best in class thinking tool2
- Orthogonality0
- Predictable0
- Error messages can be very confusing8
- Too much distraction in language extensions8
- Libraries have poor documentation4
- No best practices3
- No good ABI3
- Sometimes performance is unpredictable2
- Poor packaging for apps written in it for Linux distros2
- Slow compilation1
related Haskell posts
Why I am using Haskell in my free time?
I have 3 reasons for it. I am looking for:
Fun.
Improve functional programming skill.
Improve problem-solving skill.
Laziness and mathematical abstractions behind Haskell makes it a wonderful language.
It is Pure functional, it helps me to write better Scala code.
Highly expressive language gives elegant ways to solve coding puzzle.
Golang
- High-performance534
- Simple, minimal syntax389
- Fun to write356
- Easy concurrency support via goroutines297
- Fast compilation times269
- Goroutines191
- Statically linked binaries that are simple to deploy178
- Simple compile build/run procedures149
- Backed by google135
- Great community132
- Garbage collection built-in51
- Built-in Testing43
- Excellent tools - gofmt, godoc etc42
- Elegant and concise like Python, fast like C38
- Awesome to Develop35
- Used for Docker25
- Flexible interface system24
- Deploy as executable22
- Great concurrency pattern22
- Open-source Integration19
- Go is God16
- Fun to write and so many feature out of the box16
- Easy to read15
- Its Simple and Heavy duty14
- Powerful and simple13
- Easy to deploy13
- Best language for concurrency12
- Concurrency11
- Safe GOTOs10
- Rich standard library10
- Clean code, high performance9
- Easy setup9
- High performance8
- Hassle free deployment8
- Simplicity, Concurrency, Performance8
- Used by Giants of the industry7
- Single binary avoids library dependency issues7
- Cross compiling6
- Simple, powerful, and great performance6
- Gofmt5
- Garbage Collection5
- Very sophisticated syntax5
- Excellent tooling5
- WYSIWYG5
- Keep it simple and stupid4
- Widely used4
- Kubernetes written on Go4
- No generics2
- Operator goto1
- You waste time in plumbing code catching errors41
- Verbose25
- Packages and their path dependencies are braindead23
- Dependency management when working on multiple projects15
- Google's documentations aren't beginer friendly15
- Automatic garbage collection overheads10
- Uncommon syntax8
- Type system is lacking (no generics, etc)6
- Collection framework is lacking (list, set, map)3
- Best programming language2
related Golang posts











How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:
Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.
Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:
https://eng.uber.com/distributed-tracing/
(GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)
Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark
Winds 2.0 is an open source Podcast/RSS reader developed by Stream with a core goal to enable a wide range of developers to contribute.
We chose JavaScript because nearly every developer knows or can, at the very least, read JavaScript. With ES6 and Node.js v10.x.x, it’s become a very capable language. Async/Await is powerful and easy to use (Async/Await vs Promises). Babel allows us to experiment with next-generation JavaScript (features that are not in the official JavaScript spec yet). Yarn allows us to consistently install packages quickly (and is filled with tons of new tricks)
We’re using JavaScript for everything – both front and backend. Most of our team is experienced with Go and Python, so Node was not an obvious choice for this app.
Sure... there will be haters who refuse to acknowledge that there is anything remotely positive about JavaScript (there are even rants on Hacker News about Node.js); however, without writing completely in JavaScript, we would not have seen the results we did.
#FrameworksFullStack #Languages
Clojure
- It is a lisp118
- Persistent data structures101
- Concise syntax100
- jvm-based language89
- Concurrency88
- Interactive repl82
- Code is data76
- Open source61
- Lazy data structures60
- Macros55
- Functional48
- Simplistic22
- Immutable by default21
- Excellent collections19
- Fast-growing community18
- Simple (not easy!)14
- Multiple host languages14
- Practical Lisp14
- Because it's really fun to use9
- Community9
- Addictive9
- It creates Reusable code8
- Web friendly8
- Rapid development8
- Minimalist7
- Programmable programming language5
- Java interop5
- Regained interest in programming4
- EDN3
- Compiles to JavaScript3
- Share a lot of code with clojurescript/use on frontend2
- Cryptic stacktraces9
- Need to wrap basically every java lib4
- Toxic community4
- Good code heavily relies on local conventions3
- Slow application startup2
- Tonns of abandonware2
- Usable only with REPL1
- Hiring issues1
- Bad documented libs1
- Macros are overused by devs1
- Tricky profiling1
- IDE with high learning curve1
- Configuration bolierplate1
- Conservative community1
- Have no good and fast fmt0
related Clojure posts










Stitch is run entirely on AWS. All of our transactional databases are run with Amazon RDS, and we rely on Amazon S3 for data persistence in various stages of our pipeline. Our product integrates with Amazon Redshift as a data destination, and we also use Redshift as an internal data warehouse (powered by Stitch, of course).
The majority of our services run on stateless Amazon EC2 instances that are managed by AWS OpsWorks. We recently introduced Kubernetes into our infrastructure to run the scheduled jobs that execute Singer code to extract data from various sources. Although we tend to be wary of shiny new toys, Kubernetes has proven to be a good fit for this problem, and its stability, strong community and helpful tooling have made it easy for us to incorporate into our operations.
While we continue to be happy with Clojure for our internal services, we felt that its relatively narrow adoption could impede Singer's growth. We chose Python both because it is well suited to the task, and it seems to have reached critical mass among data engineers. All that being said, the Singer spec is language agnostic, and integrations and libraries have been developed in JavaScript, Go, and Clojure.
I adopted Clojure and ClojureScript because:
- it's 1 language, multiple platforms.
- Simple syntax.
- Designed to avoid unwanted side effects and bugs.
- Immutable data-structures.
- Compact code, very expressive.
- Source code is data.
- It has super-flexible macro.
- Has metadata.
- Interoperability with JavaScript, Java and C#.
- Great concurrency model32
- Fast17
- Actor Library12
- Open source10
- Resilient7
- Message driven5
- Scalable5
- Mixing futures with Akka tell is difficult3
- Closing of futures2
- No type safety2
- Very difficult to refactor1
- Typed actors still not stable1
related Akka posts
To solve the problem of scheduling and executing arbitrary tasks in its distributed infrastructure, PagerDuty created an open-source tool called Scheduler. Scheduler is written in Scala and uses Cassandra for task persistence. It also adds Apache Kafka to handle task queuing and partitioning, with Akka to structure the library’s concurrency.
The service’s logic schedules a task by passing it to the Scheduler’s Scala API, which serializes the task metadata and enqueues it into Kafka. Scheduler then consumes the tasks, and posts them to Cassandra to prevent data loss.
I decided to use Akka instead of Kafka streams because I have personal relationships at @Lightbend.
- Satisfying to write5
- Pattern matching4
- Also has OOP3
- Easy syntax3
- Very practical3
- Extremely powerful type inference3
- Small community3
- Royal pain in the neck to compile large programs1
related OCaml posts
- Guaranteed memory safety138
- Fast125
- Open source83
- Minimal runtime75
- Pattern matching69
- Type inference61
- Concurrent55
- Algebraic data types55
- Efficient C bindings45
- Practical43
- Best advances in languages in 20 years36
- Fix for C/C++29
- Safe, fast, easy + friendly community29
- Stablity23
- Zero-cost abstractions22
- Closures22
- Extensive compiler checks19
- Great community18
- No NULL type16
- Completely cross platform: Windows, Linux, Android14
- Async/await14
- No Garbage Collection13
- Great documentations12
- High-performance12
- High performance11
- Super fast11
- Safety no runtime crashes10
- Fearless concurrency10
- Generics10
- Guaranteed thread data race safety10
- Compiler can generate Webassembly9
- Helpful compiler9
- Macros8
- Prevents data races8
- Easy Deployment8
- Painless dependency management7
- RLS provides great IDE support7
- Real multithreading6
- Good package management4
- Support on Other Languages4
- Hard to learn26
- Ownership learning curve23
- Unfriendly, verbose syntax11
- Variable shadowing4
- High size of builded executable4
- Many type operations make it difficult to follow4
- No jobs3
related Rust posts
Hello!
I'm a developer for over 9 years, and most of this time I've been working with C# and it is paying my bills until nowadays. But I'm seeking to learn other languages and expand the possibilities for the next years.
Now the question... I know Ruby is far from dead but is it still worth investing time in learning it? Or would be better to take Python, Golang, or even Rust? Or maybe another language.
Thanks in advance.
Sentry's event processing pipeline, which is responsible for handling all of the ingested event data that makes it through to our offline task processing, is written primarily in Python.
For particularly intense code paths, like our source map processing pipeline, we have begun re-writing those bits in Rust. Rust’s lack of garbage collection makes it a particularly convenient language for embedding in Python. It allows us to easily build a Python extension where all memory is managed from the Python side (if the Python wrapper gets collected by the Python GC we clean up the Rust object as well).
Java
- Great libraries593
- Widely used444
- Excellent tooling400
- Huge amount of documentation available390
- Large pool of developers available333
- Open source205
- Excellent performance201
- Great development155
- Vast array of 3rd party libraries149
- Used for android148
- Compiled Language60
- Used for Web51
- Managed memory46
- High Performance45
- Native threads44
- Statically typed43
- Easy to read35
- Great Community33
- Reliable platform29
- Sturdy garbage collection24
- JVM compatibility24
- Cross Platform Enterprise Integration22
- Universal platform20
- Good amount of APIs20
- Great Support18
- Great ecosystem14
- Backward compatible11
- Lots of boilerplate11
- Everywhere10
- Excellent SDK - JDK9
- It's Java7
- Static typing7
- Mature language thus stable systems6
- Better than Ruby6
- Long term language6
- Cross-platform6
- Portability6
- Clojure5
- Vast Collections Library5
- Used for Android development5
- Most developers favorite4
- Old tech4
- Javadoc3
- Stable platform, which many new languages depend on3
- History3
- Testable3
- Best martial for design3
- Great Structure3
- Faster than python2
- Type Safe2
- Verbosity32
- NullpointerException27
- Overcomplexity is praised in community culture16
- Nightmare to Write16
- Boiler plate code12
- Classpath hell prior to Java 98
- No REPL6
- No property4
- Code are too long3
- There is not optional parameter2
- Floating-point errors2
- Non-intuitive generic implementation2
- Terrbible compared to Python/Batch Perormence1
- Returning Wildcard Types1
- Java's too statically, stronglly, and strictly typed1
related Java posts











How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:
Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.
Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:
https://eng.uber.com/distributed-tracing/
(GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)
Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark
When you think about test automation, it’s crucial to make it everyone’s responsibility (not just QA Engineers'). We started with Selenium and Java, but with our platform revolving around Ruby, Elixir and JavaScript, QA Engineers were left alone to automate tests. Cypress was the answer, as we could switch to JS and simply involve more people from day one. There's a downside too, as it meant testing on Chrome only, but that was "good enough" for us + if really needed we can always cover some specific cases in a different way.