What is Erlang and what are its top alternatives?
Erlang is a concurrent, functional programming language designed for building scalable, fault-tolerant systems. It is known for its lightweight processes, message passing, and actor model, which make it ideal for building distributed systems and real-time applications. Erlang also comes with built-in support for hot code reloading, making it easy to upgrade systems without downtime. However, Erlang's syntax can be a bit challenging for new users, and its runtime system may not be as efficient as some other languages.
- Elixir: Elixir is a dynamic, functional language that runs on the Erlang VM, making it compatible with Erlang libraries and tools. It features a more user-friendly syntax and tooling compared to Erlang, while still maintaining the same level of concurrency and fault tolerance.
- Akka: Akka is a toolkit for building concurrent, distributed, and resilient applications on the JVM. It provides actors, message passing, and supervision strategies similar to Erlang, but in a Java/Scala environment.
- Haskell: Haskell is a purely functional programming language known for its strong type system and expressive syntax. While not as focused on concurrency as Erlang, Haskell offers powerful abstractions for building robust and reliable systems.
- Go: Go is a statically typed, compiled language that emphasizes simplicity and efficiency. It provides built-in support for concurrency through goroutines and channels, offering a different approach to building scalable systems compared to Erlang.
- Clojure: Clojure is a Lisp dialect that runs on the JVM and emphasizes immutability and functional programming. It offers a rich set of concurrency primitives and tools, making it a strong alternative to Erlang for building distributed systems.
- Rust: Rust is a systems programming language that prioritizes safety and performance. While not as focused on concurrency as Erlang, Rust's ownership model and memory safety features make it a compelling choice for building low-level, high-performance systems.
- Scala: Scala is a hybrid functional and object-oriented language that runs on the JVM. It offers actors and concurrency support through libraries like Akka, providing a familiar environment for Java developers looking to build scalable systems.
- Pony: Pony is a statically typed, actor-based programming language designed for high-performance and fault-tolerant systems. It offers features like reference capabilities and capabilities-based security, making it a unique alternative to Erlang for certain use cases.
- Crystal: Crystal is a statically typed, compiled language with a syntax inspired by Ruby. It is known for its performance and simplicity, offering native concurrency support through fibers, making it an interesting alternative to Erlang for certain applications.
- Racket: Racket is a general-purpose, multi-paradigm programming language known for its extensive library ecosystem and language-oriented programming features. While not focused on concurrency like Erlang, Racket offers powerful tools for building domain-specific languages and runtime extensibility.
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
- Concurrency174
- Functional162
- Erlang vm133
- Great documentation113
- Great tooling105
- Immutable data structures87
- Open source81
- Pattern-matching77
- Easy to get started62
- Actor library59
- Functional with a neat syntax32
- Ruby inspired29
- Erlang evolved25
- Homoiconic24
- Beauty of Ruby, Speed of Erlang/C22
- Fault Tolerant17
- Simple14
- High Performance13
- Doc as first class citizen11
- Good lang11
- Pipe Operator11
- Stinkin' fast, no memory leaks, easy on the eyes9
- Fun to write9
- OTP8
- Resilient to failure8
- GenServer takes the guesswork out of background work6
- Pattern matching4
- Not Swift4
- Idempotence4
- Fast, Concurrent with clean error messages4
- Easy to use3
- Dynamic Typing2
- Error isolation2
- 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 understand2
- 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 programming90
- Statically typed66
- Type-safe59
- Open source39
- Great community38
- Built-in concurrency31
- Built-in parallelism30
- Composable30
- Referentially transparent24
- Generics20
- Type inference15
- Intellectual satisfaction15
- If it compiles, it's correct12
- Flexible8
- Monads8
- Great type system5
- Proposition testing with QuickCheck4
- One of the most powerful languages *(see blub paradox)*4
- Purely-functional Programming4
- Highly expressive, type-safe, fast development time3
- Pattern matching and completeness checking3
- Great maintainability of the code3
- Fun3
- Reliable3
- Best in class thinking tool2
- Kind system2
- Better type-safe than sorry2
- Type classes2
- Predictable1
- Orthogonality1
- Too much distraction in language extensions9
- Error messages can be very confusing8
- Libraries have poor documentation5
- No good ABI3
- No best practices3
- Poor packaging for apps written in it for Linux distros2
- Sometimes performance is unpredictable2
- Slow compilation1
- Monads are hard to understand1
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-performance553
- Simple, minimal syntax397
- Fun to write364
- Easy concurrency support via goroutines303
- Fast compilation times273
- Goroutines195
- Statically linked binaries that are simple to deploy181
- Simple compile build/run procedures151
- Backed by google137
- Great community137
- Garbage collection built-in53
- Built-in Testing47
- Excellent tools - gofmt, godoc etc44
- Elegant and concise like Python, fast like C40
- Awesome to Develop37
- Used for Docker26
- Flexible interface system26
- Great concurrency pattern25
- Deploy as executable24
- Open-source Integration21
- Easy to read19
- Fun to write and so many feature out of the box17
- Go is God17
- Powerful and simple14
- Easy to deploy14
- Its Simple and Heavy duty14
- Concurrency14
- Best language for concurrency13
- Safe GOTOs11
- Rich standard library11
- Clean code, high performance10
- Easy setup10
- High performance10
- Simplicity, Concurrency, Performance9
- Cross compiling8
- Single binary avoids library dependency issues8
- Hassle free deployment8
- Used by Giants of the industry7
- Simple, powerful, and great performance7
- Gofmt7
- Garbage Collection6
- WYSIWYG5
- Very sophisticated syntax5
- Excellent tooling5
- Keep it simple and stupid4
- Widely used4
- Kubernetes written on Go4
- No generics2
- Looks not fancy, but promoting pragmatic idioms1
- Operator goto1
- You waste time in plumbing code catching errors42
- Verbose25
- Packages and their path dependencies are braindead23
- Google's documentations aren't beginer friendly16
- Dependency management when working on multiple projects15
- Automatic garbage collection overheads10
- Uncommon syntax8
- Type system is lacking (no generics, etc)7
- Collection framework is lacking (list, set, map)5
- Best programming language3
- A failed experiment to combine c and python1
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
- It is a lisp117
- Persistent data structures100
- Concise syntax100
- jvm-based language90
- Concurrency89
- Interactive repl81
- Code is data76
- Open source61
- Lazy data structures61
- Macros57
- Functional49
- Simplistic23
- Immutable by default22
- Excellent collections20
- Fast-growing community19
- Multiple host languages15
- Simple (not easy!)15
- Practical Lisp15
- Because it's really fun to use10
- Addictive10
- Community9
- Web friendly9
- Rapid development9
- It creates Reusable code9
- Minimalist8
- Programmable programming language6
- Java interop6
- Regained interest in programming5
- Compiles to JavaScript4
- Share a lot of code with clojurescript/use on frontend3
- EDN3
- Clojurescript1
- Cryptic stacktraces11
- Need to wrap basically every java lib5
- Toxic community4
- Good code heavily relies on local conventions3
- Tonns of abandonware3
- Slow application startup3
- Usable only with REPL1
- Hiring issues1
- It's a lisp1
- 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.
Most of CircleCI is written in Clojure and it has been this way since almost the beginning. Early development included Rails, but by the time that CircleCI was released to the public, it was written entirely in Clojure. Clojure is still at our platform’s core. It helps having a common language across much of our stack to allow for our engineers to move between layers of the stack without much overhead.
- 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 write7
- Pattern matching6
- Also has OOP4
- Very practical4
- Easy syntax3
- Extremely powerful type inference3
- Efficient compiler1
- Small community3
- Royal pain in the neck to compile large programs1
related OCaml posts
- Guaranteed memory safety145
- Fast132
- Open source88
- Minimal runtime75
- Pattern matching72
- Type inference63
- Algebraic data types57
- Concurrent57
- Efficient C bindings47
- Practical43
- Best advances in languages in 20 years37
- Safe, fast, easy + friendly community32
- Fix for C/C++30
- Stablity25
- Zero-cost abstractions24
- Closures23
- Extensive compiler checks20
- Great community20
- Async/await18
- No NULL type18
- Completely cross platform: Windows, Linux, Android15
- No Garbage Collection15
- Great documentations14
- High-performance14
- Generics12
- Super fast12
- High performance12
- Safety no runtime crashes11
- Fearless concurrency11
- Compiler can generate Webassembly11
- Macros11
- Guaranteed thread data race safety11
- Helpful compiler10
- RLS provides great IDE support9
- Prevents data races9
- Easy Deployment9
- Real multithreading8
- Painless dependency management8
- Good package management7
- Support on Other Languages5
- Type System1
- Hard to learn28
- Ownership learning curve24
- Unfriendly, verbose syntax12
- High size of builded executable4
- Many type operations make it difficult to follow4
- No jobs4
- Variable shadowing4
- Use it only for timeoass not in production1
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 libraries603
- Widely used446
- Excellent tooling401
- Huge amount of documentation available396
- Large pool of developers available334
- Open source208
- Excellent performance203
- Great development158
- Used for android150
- Vast array of 3rd party libraries148
- Compiled Language60
- Used for Web52
- Managed memory46
- High Performance46
- Native threads45
- Statically typed43
- Easy to read35
- Great Community33
- Reliable platform29
- Sturdy garbage collection24
- JVM compatibility24
- Cross Platform Enterprise Integration22
- Good amount of APIs20
- Universal platform20
- Great Support18
- Great ecosystem14
- Backward compatible11
- Lots of boilerplate11
- Everywhere10
- Excellent SDK - JDK9
- Cross-platform7
- It's Java7
- Static typing7
- Portability6
- Mature language thus stable systems6
- Better than Ruby6
- Long term language6
- Used for Android development5
- Clojure5
- Vast Collections Library5
- Best martial for design4
- Most developers favorite4
- Old tech4
- Testable3
- History3
- Javadoc3
- Stable platform, which many new languages depend on3
- Great Structure3
- Faster than python2
- Type Safe2
- Job0
- Verbosity33
- NullpointerException27
- Nightmare to Write17
- Overcomplexity is praised in community culture16
- Boiler plate code12
- Classpath hell prior to Java 98
- No REPL6
- No property4
- Code are too long3
- Non-intuitive generic implementation2
- There is not optional parameter2
- Floating-point errors2
- Java's too statically, stronglly, and strictly typed1
- Returning Wildcard Types1
- Terrbible compared to Python/Batch Perormence1
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.