I love Erlang, and am one of the very few people who (in the past) managed to find work doing it full time. The actor paradigm it provides is surprisingly simple and elegant to write an app, even on a single node, and of course making distributed apps is fairly straightforward as a result of it.
I have found that I like Lisp-Flavoured-Erlang (LFE) a bit more, since I still find the prolog-esque syntax a bit frustrating. I've been doing this stuff for like 6 years, and I still occasionally get tripped up on when to do a comma, semicolon, or period occasionally. While I'm not a huge fan of LISP-2 semantics, overall I find the syntax for LFE to be a lot more consistent than raw Erlang.
This isn't to crap all over regular Erlang though; Erlang was the first language I had seen that fully embraced pattern-matching, and I find that kind of pattern to be incredibly elegant.
If someone reading this hasn't tried out Erlang, do yourself a favor, download and install it, and build a simple TCP chat server. I can virtually guarantee you that it will be easier than anything you've built in C/C++, and it's incredibly satisfying to have something you built in a few hours have the ability to scale correctly.
> I still occasionally get tripped up on when to do a comma, semicolon, or period occasionally
Those are affectionately called "ant turd tokens", because they're kind of small and it's easy to miss which one is which, especially when moving code around.
I got to work with Erlang professionally a few years back, and miss it in a lot of ways.
I'm not super familiar with Ruby (had a bad initial experience with some awful Rails code and never went back), but maybe?
From what I've read in blog posts, it feels like the coolness of Ruby comes from the feeling of "holy crap, something that would have taken me two days in Java/C/C++ took me an hour with Ruby" (hopefully I'm summarizing this more or less correctly).
Erlang has definitely given that feeling to me. Distributed programming can be really, really hard, and gluing things together with sockets and whatnot can lead to a lot of really difficult bugs. Since Erlang embraces distribution and concurrency as part of its paradigm, it sometimes kind of feels like outright magic. Sometimes things feel like they went a bit...too perfect, like you missed something, when you really haven't.
I'm not going to say that it fixes every issue with concurrency; you can still have race conditions and Mnesia and ets can be a bit finnickey if you're not careful, but I think I can honestly say that, for distributed apps, I can accomplish 20x as much as I could with most other platforms.
If I understand you and OP correctly, it’s a kind of joy derived from doing something for a while, being acutely aware of the limitations and frustrations that come with it, and then discovering a brand new way of working that doesn’t involve any of the slog you’d grown accustomed to.
Speaking purely personally, mathematics has consistently been the discipline that’s delivered the most bang for my buck in that regard - learning a new branch can let you solve problems that are just impossible to solve, or take pages and pages of computation, in a few lines.
I agree with mathematics; I came to the same conclusion about five years ago; I realized understanding some basic type theory made a whole lot of programming easier for me.
It's kind of dry reading, but I've been trying to get into different process calculi lately; specifically the Pi Calculus and Join Calculus, since these things feel like a cool hybrid of computer-science and mathematics.
I'm still learning, but I've really enjoyed this book [1]. It's pretty theory-heavy, especially at first, but overall I have found it fairly approachable.
Also, Tony Hoare's book on CSP is actually a fairly interesting read; certainly interesting if you like Go. You can actually download it legally free here: [2]
In regards to type theory, I'd recommend starting by learning Haskell, just to make the terminology a little less scary, then picking up the book "Basic Simple Type Theory" by J Roger Hindley. Don't let the name fool you, it's still pretty heavy stuff; there's no way I would have been able to get through it if I hadn't learned Haskell beforehand. [3]
I worked with Ruby for about 10 years before diving into Erlang. I liked a lot about the Erlang ecosystem, but the syntax was a bit challenging. About a year later, I found Elixir. It provided all the joys of Ruby for me combined with all the things I loved about Erlang. This is completely subjective, obviously, but I've worked with a lot of languages over the past 30 years and Elixir has been by far my favorite. I hope to finish out my career doing Elixir.
> I don't get why people think Elixir is like Ruby. Other than some syntactic similarities, I can't think of any substantial similarities.
The creators of elixir were rubyists. As someone who used to Ruby and now Elixirs, a lot of the joy of the platform (relevant to gp's comment) has made it over. Elixir is legitimately as fun to program in as Ruby, if not more so. I think that the developers of elixir care about the user experience in a way that basically no other language seems to.
I could of course be biased because before Ruby I used to program in an actor-like C++ framework, so everything just feels like I'm coming home to a home I never knew existed to me.
Phoenix is similar to Rails superficially, I’m so far as they both have some MVCish structure and some generators. The similarities really stop there though.
Phoenix doesn’t have a magical asset pipeline, it doesn’t have a whole library of language extensions a la ActiveSupport, it doesn’t represent dB rows as objects. Those are just a few things off the top of my head.
Additionally all requests to an app running Phoenix/Cowboy/Plug are separate processes and can happen in parallel without having to stand up multiple app instances.
It's a gem of an observation that newcomers to an environment often only make it to the first few rungs of the system complexity / actualization ladder. Once you look, you see this everywhere, and not just in IT but with any sort of design exercise or institutional process, any complex system that's full of Chesterton's fences, and people will either evolve to debate their rationale from a position of experience, or be selected (or self-selected) away into fresh environments where the novelty and discovery-until-discouragement can begin again.
It also shows that the first few rungs matter a lot; this is the territory of easy answers, where following a few simple rules leads to rapid productivity, and there will always be people for whom that level is good enough, either through carefully weighed decisions from limited information, or ignorance and deferment of future problems and their solutions. You can't solve everyone's problems for them, but you can try to evangelize, and you can try to build your system in a way that best practices can be incrementally adopted from existing fumblings. Anticipate that most of it will stay mediocre.
History is littered with systems that, in hindsight, seem to have offered sensible solutions to complex problems, yet didn't survive in the end. Much knowledge and wisdom is lost, and others independently discover it when trying to ascend an unrelated stack. Erlang/OTP is truly the sort of environment that masquerades as a programming language yet asks questions at a much higher conceptual level: what do we want systems as a whole to look like if we have to maintain them indefinitely? Its architectural innovations have been copied elsewhere, where they rarely form part of a coherent stack, but at least expose people to the advantages of its model. This may also be the most viable source of adopters of Erlang at higher levels: people who've sought out similar model for its benefits, and could thrive with an offering that pays attention to these concerns throughout.
> people who've sought out similar model for its benefits, and could thrive with an offering that pays attention to these concerns throughout.
I discovered BEAM while looking into a way to run concurrent, distributed Golang/gRPC services in a supervisor-worker set up. I've continued tinkering with OTP ever since.
Re: those infrastructure components written in Erlang not attracting Erlang users in any permanent way—it’s not so much that they have more users than contributors, but rather just the bare fact of them being infrastructure components. A black-box infrastructure component can’t be a “killer app” for a language.
Rails is a killer-app for Ruby because it’s a framework; a developer who uses Rails in their project is inherently a Ruby developer. People learned Ruby to use Rails.
But you don’t need to write a single line of Erlang to use CouchDB or Riak or Ejabberd. They’re self-contained. (And, in fact, scriptable in not-Erlang languages; CouchDB for example spawns and manages a JavaScript engine to run its “design documents” on.)
Thus, these infra components becoming popular doesn’t cause there to be any more Erlang programmers than there were before.
In that sense, I would say that Erlang has never had a true “killer app” yet. (Outside of a few specialized domains, like telecom and fintech, where the OTP platform itself is Erlang’s killer app.)
And even in the places where Erlang itself is a “killer app”, it’s also not so much a viral thing that the whole industry gets excited about; rather, Erlang is more of a “secret sauce.” Nobody’s learning Erlang in their basement because their friend told them it’d be the next big thing in their industry.
How does anyone learn Erlang, then? Well, usually, engineers are forced to learn Erlang at one job (where the system architect there decided on it); they get to liking it; and then, when they later become a system architect themselves in another job, and choose a stack, they choose Erlang, thus forcing a new wave of engineers to learn it.
Agreed. This is actually why I think the killer apps for the BEAM are 2 Elixir based ones.
Nerves, which is already being heavily used for embedded systems and only getting stronger thanks to the likes of Scenic.
And Phoenix LiveView (not released yet), which I personally think pulls the strengths of Phoenix together in a way that can truly disrupt web development. It’s very difficult to do what LiveView is doing on other tech stacks.
The combination of those two will likely fuel things long term.
> Phoenix LiveView (not released yet), which I personally think pulls the strengths of Phoenix together in a way that can truly disrupt web development. It’s very difficult to do what LiveView is doing on other tech stacks.
LiveView still needs more work to be really ergonomic, wouldn't work for all use cases, but I'm personally holding my breath here in excitement to adopt it in my Elixir projects.
Still, I find it ironic that the next server side web technology leap, after the famous Rails demo referenced in the article, comes from another Ruby-inspired language.
I have also written Elixir in the last years, after 10 years of Ruby, and the syntactic similarities are obvious to me. Luckily you don't have to take my word for it, as the author of Elixir said multiple times that, while Elixir is not about syntax, its syntax was inspired by Ruby.
That is what I was getting at. Having people who came from the Ruby world and some very mild surface level bits is all that's there.
The issue I have with the statement is that it pulls all of the negative connotations that some people have with Ruby onto Elixir...and Elixir is not at all like Ruby.
It’s hard to say it’s not inspired by Ruby when Jose and many of the core contributors came from the Ruby world.
It’s not at all the same thing as Ruby on Beam though - it’s a very different language, but it does borrow a lot of good ideas from the Ruby ecosystem while improving on them in many ways.
Not quite. Elixir code isn't set to the client as Blazor does with .Net IL. LiveView leverages a small runtime loaded onto the client which uses websockets to load deltas.
While it sounds expensive at first, the template engine has been extended to support delta tracking and the process model that Elixir inherits fits well for a heavily interactive system with thousands or millions of users. The end result is that it's a very lightweight client setup and outside of using the template system properly, there are no gotchas with learning which code runs where.
There's two distinct Blazor development models: Client side Blazor uses Mono (running as WebAssembly) to run C# code on the client side, but server side Blazor only updates the DOM via SignalR (like WebSockets), which works like LiveView.
I didn't use Blazor yet, but that's what I understand from the documentation.
I don't think that's correct. Blazor supports both client-side (what you are describing, sending IL to the client and running it as an app) and server-side (what LiveView is doing). More details here: https://docs.microsoft.com/en-us/aspnet/core/blazor/hosting-...
I was going to go as far as saying that elixir itself is the ‘killer app’. It doesn’t make you an Erlang developer but it is also arguable that knowing Rails isn’t necessarily sufficient to fully grok Ruby. You’ll still make some headway though.
I’ve interviewed plenty of people who cut their teeth on Rails and fall apart as soon as you present them, say, Sinatra. Or a gem that provides an API client. Once it comes to writing non-Rails code (with all the helpers and the magic), it’s as good as learning a new language that happens to look exactly the same.
> And Phoenix LiveView (not released yet), which I personally think pulls the strengths of Phoenix together in a way that can truly disrupt web development. It’s very difficult to do what LiveView is doing on other tech stacks.
LiveView cannot avoid latency. When I've experimented it's great for something running on my local network; less good when it's in a datacentre in another country. It's laggy.
And unless you replicate to many locations, or can deploy it to edge compute nodes (no idea) then this will always be a problem compared to 'true' client-side development.
I want it to work but I don't see how it can beat the laws of physics.
> LiveView cannot avoid latency. When I've experimented it's great for something running on my local network; less good when it's in a datacentre in another country. It's laggy.
If you built a traditional SPA, aren't you still making loads of calls to your server?
I don't see how LiveView would be more laggy than that. In both cases you're making network calls from the user's machine, to your server, getting a response from the server and then rendering output on the client when it's received.
Of course you can cheat and do optimistic rendering on the client (like outputting what you wrote instantly in some DOM element instead of waiting for a response and validating it after the fact) but I believe that enhancement could be done with both techs.
The only place where LiveView falls short is a true offline / fully client side app, but those are such a rare breed and way out of the norm for a typical web app. In 20 years of web dev as a freelancer, I've been asked 0 times to build an offline / client side JS app.
> If you built a traditional SPA, aren't you still making loads of calls to your server?
For data loading, yes. But here's a few random thoughts:
* I can pre-emptively load data in a SPA (think: 3 screens-worth of a datagrid) and keep fetching in advance, so the user rarely feels the lag.
* Much of my investigation has been around adaptive forms, wizards, validation and keeping logic in a single place. Having to define models and logic once, rather than client-side and server-side would save so much time.
My testing suggested that client-side validation still gave better results, because it was instant. Moving forward & back through a wizard was better if client-side rather than each screen rendered server-side.
I experimented early May so am a little hazy on details (and can't find which PIM I put my notes in, sigh) and look forward to seeing other people's experiments. Particularly when not run on their local machine.
> My testing suggested that client-side validation still gave better results, because it was instant.
In some cases yes, but I don't think you can get away with client side validation for a lot of things because they depend on the state of your database to return the correct result.
For example, how would you validate an email or username on the client when the availability of the name depends on you making a database call to see if a user exists already? You have to make a network call, get the result and then update your validation errors on the client based on that server side result.
But for validating something like a phone number or twitter handle, sure, client side works all the way but I don't think having even 200ms of delay for that validation is going to make for a bad user experience. 200ms is a lot too. That's about what it takes to ping a server in Tokyo from New York.
Your other points are valid tho. I guess we'll see where LiveView ends up going.
> LiveView was always going to have this limitation. Its design makes it suitable for low latency links - such as local network. [...] I’m looking forward to building some admin tools with it
All our tools are now hosted in the cloud - we don't run any servers on the local network. With a 20-30ms RTT perhaps it will feel smooth - or the micro-delays will be noticeable.
That's a fair point, but it does seem like a solvable problem. There are multiple companies offering gaming services where the game is running on a remote system. I haven't tried any of these services, but from what I hear they are very useable for casual games, but still have some work to do for FPS type games where milliseconds count. That would indicate to me that getting a web UI to work with this type of setup should be very possible with geographically distributed servers.
Honest question: if liveView does catch on in a big way, what will the front end developers do? I can't see the huge FED community going back to writing HTML and CSS templates. I wonder if that resistance will hurt adoption.
They'll have to start thinking of themselves as "developers", not just "frontend developers". Boxing yourself into one specific type of software development is a bad idea given how the industry changes so rapidly and dramatically. Flexibility is key to long term success.
LiveView is great for writing form validations or simple admin stuff. Even though the examples show that you can do 60fps animations, it is not the intended use case, you're not going to write anything that needs small latency or that needs a ton of processing using LiveView, front end developers are fine.
Even in very simple CRUD projects I have to write a few hundred lines of Javascript to enhance the UI. Stuff like: if you check this box 4 more options appear. Or here is an autocomplete field/dropdown that autofills in 4 other form fields. A lot of basic stuff that cannot be done with raw HTML alone. I can see how something like LiveView would replace the need for mucking around with jQuery when your project doesn't need a big and heavy SPA framework.
I've recently adopted two libraries for my server-side backend app:
1. unpoly to handle common JS behaviours (such as show this div when this checkbox is selected)
2. Web components to handle more complex pieces of UI while maintaining compatibility with LiveView: rendering a functional jQuery carousel via LiveView/Websockets is much harder than just pushing a <carousel> element through the socket. Admittedly I haven't tested if the DOM diffing library LiveView uses plays nice with web components.
It actually might. You can write Elixir for years without learning Erlang syntax, but if you’re a perfectionist, you’re gonna notice bugs in your Erlang deps just as much as in your Elixir deps, and you’re gonna want to submit PRs for them, and that leads you to learning Erlang.
Also, IMHO, if you want to have a solid foundation when learning Elixir, it’s simpler to learn Erlang/OTP as a cohesive whole (from e.g. ferd’s Learn You Some Erlang book) and then “chase it” with an Elixir book; rather than trying to understand OTP through the lens of how it’s exposed in Elixir. Everyone in the elixir-lang Slack that asks how to get started learning Elixir, I tell them to learn Erlang first. So “being a simpler jumping-off point to Elixir knowledge” is also kind of a killer app.
I would guess that this is only true in cases where there are killer apps for a secondary language on a runtime, but no killer apps for the primary language. Like, I wouldn’t say that Clojure is a killer app for Java. But then, is that because Java is already popular? Or is that because Clojure developers don’t necessarily end up knowing Java as well as Elixir developers end up knowing Erlang?
There's a lot in the Erlang stdlib that is not available in a wrapped form from Elixir's. As of now I think you need to know at least a bit of Erlang (e.g. to understand the stdlib docs) to be able to use Elixir more productively.
I'm not sure if Elixir developers plan on providing complete wrappers for Erlang's stdlib in the future. This is in fact one criticism I have of the language, because even for simple things like serialization you have to drop to Erlang and call :erlang.term_to_binary(), which feels a bit second-class.
> you have to drop to Erlang and call :erlang.term_to_binary(), which feels a bit second-class.
Well, to be honest, :erlang module has many functions, many of which have literally nothing in common with each other. That's because that module is imported by default in Erlang - it's like `__builtins__` in Python. Exposing it as `Erlang.term_to_binary/1` module/wrapper wouldn't really fit well with the rest of the Elixir stdlib, which is (commendably) very neatly organized, with each module doing just what its name suggests.
On the other hand, wrapping just `erlang:term_to_binary/1` and `erlang:binary_to_term/1` in a `Serializer` module would be probably ok, but then there are tens of such modules you'd be pressed to implement for `:erlang` alone, and it gets worse with a rather extensive Erlang stdlib and OTP apps.
One of the Elixir selling points was (and probably is) the simplest possible FFI to (and back from) other BEAM languages (like Erlang or LFE). Calling an Erlang function is exactly the same operation as calling Elixir one - literally, the only difference is that, syntactically, most Elixir functions live in CapitalizedModules. That's it - there's no runtime overhead, no difference in handling arities, arguments, guards, exceptions or return values. The feeling of second-classiness is definitely there - the argument order and naming conventions (for args and functions both) differ, and the Erlang/OTP docs (used to - not sure it's still the case) look less than appealing in comparison with Elixir. But, realistically, Erlang's stdlib is a result of 30 years of accretion of tools and it's not small by any means. Wrapping entirety of it would take many years at least and it would consume a lot of developers' time, possibly hindering the development of the language itself. Elixir is still a young language, without a very large following and secure position in the industry - it's dangerous to divide your forces and pursue to many goals at once in a situation like that.
To summarize: in my opinion, the feeling of second-classiness is not a serious enough problem to invest resources in making it go away, at least at this point. While they may look less than pretty, Erlang/OTP docs are very well written and the functionalities tend to be rock solid. The stdlib is... not the prettiest in terms of organization, owing to decades of evolution, but with the FFI as trivial as it is, it's more than usable from Elixir. I think that was the original plan: the stdlib of Elixir was intentionally kept small and very clean, which was supposed to be Elixir's appeal, but it's only possible if reaching for the functionality missing from stdlib is simple. Just a hunch of mine, we'd need to ask Jose to know for sure :)
I agree, but my point wasn't about the erlang module specifically. Maybe :ets would have been a better example.
At one point I suggested in the forums that, inspired by how Elixir understands [foo: bar] as equivalent to [{:foo, bar}], maybe it could allow foo:bar() as equivalent to :foo.bar(). That would make the syntax exactly like Erlang's, which would be pretty nice to signal "I'm calling an Erlang function here".
I still think it's a good idea, but it wasn't met with a lot of enthusiasm :)
IIRC the main one is that it could be confusing inside a list, e.g. [foo: bar] vs [foo:bar()]. Someone also mentioned that `foo. bar()` (with a space after the dot) is legal syntax, but `foo: bar()` wouldn't be.
I find the key point to language adoption is that self-selection that occurs. What type of person and their personality does an ecosystem attract and what is that type of person good at?
The BEAM ecosystem is all about fault-tolerance, distribution, and concurrency. These BEAM concepts could be described as "upper ladder" ideas: they require more prerequisite understanding of systems engineering to appreciate. Despite being a fallacy of composition, to compare a given Erlang vs Ruby/Rails developer may be useful to consider.
A person who invests in learning Ruby/Rails might be motivated to do so because of that bootstrapping mindset of MVP's and failing fast. Our average Rails developer might be rolling the dice for that "killer app" opportunity more often than our Erlang developer prioritizing concurrency and reliability. This may be because those BEAM features are more useful at a later stage of product development. So while the BEAM features are uniquely powerful if they require an upper-ladder understanding our MVP-developer doesn't yet have - they're unlikely to pick Erlang as tool-set to invest in.
If we accept that the BEAM is good at infrastructure and that doesn't result in as many opportunities for these hype-cycle-causing-killer-apps, than what could be changed in the ecosystem to support this goal? Can we get both the later stage benefits of reliability and concurrency in addition to the early-stage productivity benefits? Maybe this early-stage development focus is where Elixir will break out of the infrastructure-niche Erlang seems to be in. Can Elixir's tooling reach a short enough new-product feedback loop more potential killer-apps get deployed into production? I think as Elixir brings in some different personalities to the ecosystem we could see more killer apps but that idea -> production feedback loop seems to be the key component.
> what could be changed in the ecosystem to support this goal?
1. Change the syntax. Elixir wasn't far enough. Not at all and BEAM doesn't need to know, so we have a chicken-egg problem of people entrenched don't want to spend time that will help the language and underlying strategies become more widely adopted. Perhaps this was the production feedback loop you were referencing. We still don't have a good methodology for measuring all sorts of things in software dev. 10 years, 20 years, the language may just never do more than incremental changes (like elixir).
2. Handling text is still awful in these languages.
You can do really cool stuff with SNOBOL[1] or TRAC. Really any homoiconic Lang or lisp will do great things with text. But I think Elixir handles text just fine if it’s UTF-8.
Here's to another 10 years of Erlang/Elixir. The programming stack for the boring software developer that wants to clock out at 5 sharp. It's fantastic I tell ya. I have been blessed with opportunities to work with Elixir fulltime and it's hands down the best experience I've had. Compared to C#, Rails, Nodejs, it's miles ahead. (Although C# with dotnet is coming up fast and _crazy_ compared to what it was 9 years ago).
This ladder is a great blueprint, great article:
functional programming
isolated processes and concurrency
reliable concurrency (links, monitors, timeouts)
OTP behaviours and other system abstractions
How to structure OTP systems
How to build releases and handle their life cycle
How to never take the system down, and how to operate it
I think you should add to this comment "in my opinion."
Because in my opinion C# is miles ahead of Erlang. If I want to create an application, back-end, front-end, running on a wide variety of platforms, Mac, Linux, PC, IOS, etc, I would use C# 1000 times over versus Erlang.
The tools available, documentation, huge amount of libraries and support mean that developer efficiency in C# land is light-years ahead of Erlang. I could make a website + backend + IOS/Android app with all shared code while using tons of pre-existing OSS frameworks / packages and get it all up and running and prod/enterprise ready in no time at all and have it ready for enterprise load and scalability. Try that with Erlang!
> create an application, back-end, front-end, running on a wide variety of platforms, Mac, Linux, PC, IOS, etc,
You might not believe it, but that is a fairly niche desire. There a tons of use cases for server software running only on server OSes (which these days, is some flavor unix 90+% of use cases)
And gee, Erlang is/was made to excel at server based software. Not desktop frontends.
My point C# can do 10 things. Erlang can do 1. If all you care about is the 1, then the other 9 C# can do are moot. If Erlang does that 1 better, then it is best (for that use case). C# is best for others.
Comparing Erlang to C# is a bit unfair.
The latter is a general purpose language that can be used to build software on every layer of every platform.
The former is a distributed programming DSL (an awesome one granted).
There is 0 Erlang-native GUI libraries, there is no documented Erlang pipeline for iOS apps etc.
> The former is a distributed programming DSL (an awesome one granted)
I mean, that's a completely incorrect characterization of Erlang, regardless of how you feel about the comparison to C#.
Erlang is just as much a general purpose language as C#, it is just a different paradigm, i.e. functional programming rather than (mostly) object-oriented.
> There is 0 Erlang-native GUI libraries
This isn't true at all. There is a tight integration with the wxWidgets framework (in fact, one of Erlang's handiest tools is built with it, Observer). Scenic, as mentioned elsewhere in the comments, is for Elixir (perhaps there is an Erlang-native API for it, not sure), but provides a native framework for OpenGL, and a UI paradigm that meshes nicely with processes and supervision.
Of course, Erlang is not perfectly suited for all environments (e.g. iOS apps), but that is true of essentially all general purpose languages - there are some places where they aren't well suited or have flaky support. I wouldn't build an iOS app in C# either, it makes little sense to use anything other than Swift/Obj-C in that environment. Likewise if I'm primarily building Windows-based apps, I would use C# before I would reach for Erlang. But for backend services, infrastructure, networking, etc., it is extremely well suited, and I think the domains that it can provide a compelling solution for will continue to grow (e.g. embedded).
Have you seen ex11? [1], it's Erlang native, and at least 0.1 of a GUI library. X11 and Erlang actually go together really well, although a lot of important functionality for a real application is missing; I used this to display images generated by an Erlang application, and it felt a lot nicer to me than using wxWidgets; I added a few bits of functionality to the library while I was in there, and it wasn't that hard to turn the X11 protocol docs into Erlang code for the things I needed.
I imagine if someone had a real need here, it wouldn't be that hard to get it into shape. Caveat: X11 is dying, etc.
[1] The most active fork appears to be here https://github.com/skvamme/ex11 -- it's been somewhat retargeted to mobile, but the examples for desktop should still work as well as they did.
'Getting' OTP, and especially how to structure an application the right way is definitely tough, because there's not a lot out there like it if you come from the world of C or scripting languages. It's not just code organization, but thinking about how to structure all the processes so that things fail in a 'good' way, and you have everything talking in the right way.
A big thanks to Fred for his book, and the many hours he has spent helping people on the mailing list, IRC and elsewhere.
I miss my time working with Erlang. I think it's still an indicator of an environment willing to try new things, but like he writes, you have to be wary of the places that are 'serial early adopters' too; I've encountered a few of those in my Erlang career.
Fantastic article; it paints a great picture of the journey taken & accomplished achieved.
My personal take is that the next major milestone for Erlang/Elixir will be a significantly more performance BEAM. Be it JIT or reworked Hipe.
Elixir (& Phoenix) brought a ton of interest from the Ruby community. The only remaining aspect that would keep a Ruby developer using Ruby is the perf vs Erlang. Today, for many raw perf task there isn’t a meaningful difference in speed (note I’m not taking scalability). As soon as the speed difference becomes meaningful, Erlang will get another wave of people.
I work with Ruby and Elixir daily and Elixir is 10x faster. Phoenix recently added functionality to display response times in microseconds, partially as a showcase for its good performance. I dont doubt you can get more performance in C++ or something but its still lighting compared to Ruby.
> Phoenix is faster than Rails, however Ruby is faster than Elixir when doing CPU intensive tasks. Like parsing text.
What is your definition of slow or fast?
For example with Elixir it was possible to generate 5,000x random 19 character codes in 3ms on a 5 year old i5 3.2ghz desktop workstation. I don't know how long it would take with Ruby but for such a text / CPU intensive task, I'm quite happy with the performance.
Also parsing templates with EEx is ridiculously fast, because it's not treated as a string.
It would be interesting if you wanted to come up with a Ruby version that adheres to the random code spec which should be able to be determined from looking at the first 2 versions. It's basically only a subset of characters that can be used and the code should be output as XXXX-XXXX-XXXX-XXXX.
I personally use the 25ms version because I find it to be the best one if you factor in both speed and readability. I'm sure there's better ways but I'm only an Elixir beginner.
Also for the record I didn't write the 2nd or 3rd versions of that gist. I asked around in the community and that's what others have put together.
I think this is a valid observation but the reason isn't necessarily that the Ruby language can't be used in a similar way, it's more so a death by 1000 cuts where Ruby encourages very small costs to be paid everywhere in return for a nicer programming experience.
The issue becomes hard to fix because all of these small costs add up but none will show as up a single bottleneck in practice, making profiling a blunt tool for this kind of performance problem. Elixir isn't immune to this either but the functional aspects of design do help keep some of these choices local to the code that chooses to trade some time or memory away for other conveniences.
An example I saw recently of this sort of adoption is map access, which is entirely okay if the trade-off is understood. I put in some time to show that much of the understanding of performance profile of the Access behavior gets colored by these expectations that the small things don't matter: https://lobste.rs/s/bctcke/performance_elixir_s_access_behav...
As someone who loves servers and back-end work, Erlang is amazing to me. I too read that book by Joe Armstrong, but I never really got to use Erlang for much since I don't get paid to use it. Recently I was trying out Elixir and going through the documentation and was pleasantly surprised how much of it is Erlang-like.
I wish the industry was much more Erlang friendly.
Well elixir explicitly try to not move away from the erlang paradigm and to be fully and "naturally" inter-operable with it. It is far more integrated with erlang than Scala is with Java as an example.
It is basically erlang with better tooling and still an easy use of erlang.
We probably had our discussions about this before, tooling definitions diverge at times, and I have a vested interest in some of them, but I will just state my disagreement on the better tooling side of things ;)
To say a few things that Fred isn't saying here (these are my opinions not his):
- Early Erlang tools had a lot of issues when Elixir showed up but rebar3 made quick progress and is a very good set of tools integrated into one command-line interface
- rebar3 has supported creating releases for a very long time which Elixir's mix tool is just catching up to (sure distillery supported things but so did relx and half a dozen other Erlang tools)
- rebar3 has built-in support for things like dialyzer which still require extra work to use from mix
- rebar3's _checkouts feature is very nice and has no good mix equivalent
- rebar3 offers a declarative configuration setup which makes it easier for other tools to integrate their data and read other data w/o requiring plugins to be loaded everywhere (and this is to say it still supports scripting where needed, which will still result in a declarative output)
- rebar3's version resolution system is more practical and puts the final control of version selection in the developer's hands rather than strictly package manager metadata which can lag or suffer unfortunate problems from version operators and unfortunate problems that come up from blind-semver adoption (this is a longer topic so I apologize for the poor summary here but I do think there is a good argument for rebar3's approach)
- rebar3 works and upgrades independently from Erlang/OTP releases allowing more fluid iteration whereas mix is very much locked to Elixir
I participate in the Elixir community and every time I hear the tooling story I think about all of the things I miss from Erlang tools when using Elixir. It'd be more accurate to say that Elixir has revitalized Erlang with a bit of competition and some diversity in background.
Either way, there is room for improvements in both camps. I hope Elixir's mix catches up with rebar3 in some of these areas and I hope Erlang doesn't ignore some of the caveats that are still around as given facts of life (perhaps getting better support for the wider set of BEAM languages would be a start so each doesn't need its own tool).
One quick correction: the equivalent to _checkouts in Mix is to use path dependencies. I often use environment variables to control when to use one or the other and I like the fine grained control more. Here is an example: https://github.com/elixir-ecto/ecto_sql/blob/master/mix.exs#...
But in general yes, we are glad to borrow ideas from each other and we should continue doing it!
Thanks for this tip. I find myself a little more reluctant to rely on environment variables for this sort of thing but it'd be fair to say the same about filesystem state.
My only problem with this solution is that it changes the mix configuration itself (which is version controlled) which is fine if others are in need of similar overrides when working on the project. For one-off/local things, it can be a bit heavy for temporary overrides.
Still, it's a fair trade-off since it's a lot easier to code up logic like this with mix compared to rebar3.
I agree with the rest of his statement of how integrated Elixir seems with Erlang. I originally avoided Elixir cause I thought it was a hassle to install, but nowadays I can brew install on macOS, and on Linux I can leverage a sane package manager.
I am not entirely sure about tooling myself. I would love to see a serious IDE for Erlang, I wonder what the tooling looks like. I've mostly just used the Erlang terminal to learn.
Interestingly enough I started using Erlang around the same time and while I've continued to use it for the project I started then on and off, I've not had a lot of reason to use it on other projects. I don't ever think it'll be as wide spread or as popular for many of the reasons listed. I do think it will continue to be a tool used to create great projects with very few hands. In the right hands and for the right projects it is an incredibly productive tool.
Elixir has a homoiconic syntax and hygienic macros, like a Lisp. In fact much of the user-facing syntax of Elixir is just macro definitions. You can do a lot of things with it at compile time, and people take advantage of it to do really cool things like compile Phoenix routes down into a single static dispatching function so that requests can be routed quickly.
Syntax is a subjective concern for sure. My experience has been that Erlang takes a little more effort and time to read fluidly, but only when first learning. I think this is because Erlang uses visually subtle tokens for important language distinctions (upper vs lower caps and periods being the primary culprits). Now that I've spent enough time in the ecosystem reading Erlang isn't really a problem, but Elixir's syntax felt like it took less mental effort to read when starting out.
I think Elixir making different token choices for these distinct ideas is the main reason for readability improvements. Especially since Erlang has less different tokens overall which you'd think would help reduce the noise.
...see where that leads us? Please actually voice reasons how it's not cleaner, as it's most definitely less verbose,
And having less clutter is generally seen as cleaner
The original claim is just as pointless. The implication that Elixir fixes Erlang's syntax is so commonly repeated without much discussion that it has many folks dismissing the entire language before they learn it.
I think both languages have issues with Syntax but in the cleaner department, I am baffled at the insistence that Erlang is hard. Inconvenient, maybe but most of the features in Erlang are so primitive that there is little to no ambiguity of what something can mean.
Verbosity strikes both (records and binaries in Erlang vs the sigil and keyword heavy Elixir code) and certainly some folks prefer rebinding variables and colon syntax on atoms but it's certainly not without real trade-offs in common idioms (tagged tuples, special casing required for atoms like true, false, nil, interop with Erlang becomes uglier, etc).
It’s more verbose when defining functions, calling anonymous functions, and referencing atoms.
Calling functions with and without parens makes for a less clean syntax. Less consistency (plus mandates the dot notation for calling anonymous functions).
> It’s more verbose when defining functions, calling anonymous functions, and referencing atoms.
and we're finally finding out how both opinions are correct
when people say that elixir code is cleaner, they're normally talking about the significantly reduced amount of code they have to write because of the macros. its not specifically about how they're defining a function or calling them anonymously
while i cant say that i agree with atom reference, (its 1 char in elixir, two in erlang), you're definitely correct about that annoying idea they've had about dropping parenthesis on functions without parameters... that was just misguided i think.
Using an atom doesn’t require any extra characters in Erlang. Update: just realized you mean the single quotes when you need an arbitrary atom name. Understood.
I definitely wish Erlang had the same macro capability. I just find the overall syntax sufficiently unpleasant that I can’t get into Elixir.
> I just find the overall syntax sufficiently unpleasant that I can’t get into Elixir.
Please, don't use such an excuse for not trying out a language. :(
The unpleasantness you speak about is akin to motion/sea sickness - the signals your brain receives disagree with the brain's predictions of what they should be. The discrepancy manifests as a feeling of unease at the very least, or you may throw up non-stop for 3 days on the deep end, but, eventually, the sea sickness disappears completely.
I believe I experienced something very similar to this many times while learning many strange, exotic languages as a hobby. When the syntax or semantics were completely outside of what I already learned, I was irritated that "I don't even know how to ...something...". When the new language was close to what I already learned, I was irritated that "it doesn't work as it should" due to the differences. Basically, I experienced some kind of rejection reaction from my brain every time. But then, after a few days to a few weeks, that feeling faded and disappeared.
There's a technique I thought up and used a few times which helped me with especially hard, complex, or simply exotic syntaxes. I'm not sure if it will work for everyone, but it helped me with Lisp and Prolog when I first learned them. What I did was to print several tens of pages of (syntax-highlighted and preferably heavily commented) example code and scatter them around the house at spots I was likely to look at. Next to the mirror in the bathroom, on the fridge doors, on my desk, and so on. I wasn't trying to actively read that code very much, just glanced at it from time to time, and sometimes tried to read a bit more when I was bored. When I returned to actually learning the language the next weekend (I think), it went much easier than before. I still wasn't able to write in the language, obviously, but reading - even if I didn't really understand more of it than before - stopped being a hassle, the feelings of rejection disappeared, and I was able to learn quickly from that point on.
Well, that's just my theory based on personal experience, so it may be utterly stupid or just my imagination, so take it with a grain of salt. Still, I believe the feeling of unpleasantness from the syntax should be very easy to neutralize and as such it's not, IMHO, a good reason for "not getting into" a language which is otherwise interesting (whether Elixir is such for you is another matter).
As someone who already knows and loves Erlang, I’m already quite familiar with the advantages Elixir offers, other than macros.
I like Erlang’s syntax. I like the concision. I like the clear differentiation between variables and atoms that capitalization offers. Erlang’s syntax and underlying model are firmly entwined in my head.
"But the vast majority of them will be a continuous flow of serial early adopters who surf from tech to tech, sniffing the best opportunity to gain a competitive advantage by being first to use a type of framework, language, or toolkit." - Oh god, that hit me so hard.
I was there. Had a full time Erlang job even before the line numbers in stack traces. Later migrated to more enterprise-y languages... and for me, the big missing thing in Erlang is the IDE. And a company (or a big community) that is dedicated to catering to the developers. This was never a thing in Erlang.
Riak convinced me that any language pretending that it could magically create better products was full of shit.
Riak is not great. It performs well, but doesn't scale well. It has tons of operational overhead, a lot of bugs (and it didn't help that a slowly disintegrating company left less time to fix those bugs "until next release"), and any changes to the cluster while it's being used heavily leads to instability/unavailability. And many of its features were not implemented great; the SOLR functionality is a pig, for example, and "enterprise" replication is flaky.
On our team, we had a few engineers who could write Erlang, but they slowly moved to other teams, so troubleshooting production issues became a black box of pain. I'm so glad the product we had using it was sunset.
Agreed, mostly. Riak was used in one of the first implementations of AT&T Messages (Web) as a secondary-index and key-value store. It performed so horribly that the whole thing ended up being rewritten using Oracle. The truth is, Riak was designed for basic key-value storage. Everything else they added on worked pretty badly, especially their javascript integration.
All that being said, I do not blame Erlang for Riak. I blame Basho. Their support was clueless, and their platform simply didn't perform as advertised.
Was a bit more than 10 years for me. I had coworkers struggling with netsnmp to build out a mock control plane for a new and exciting data center management platform. I whipped up a mocked out version with OTP in a really short time and eventually the mocked version was good enough to plug into the real backend so we shipped it.
I have never written a single line of Erlang, but I run my own ejabberd. However, looking at the package build scripts and build instruction, I have the impression that compiling a project like ejabberd can be complicated.
Does someone know if this is an inherent Erlang problem or just due to some weird project setup in this case?
Ejabberd runs with a lot of legacy. Essentially the first build tool that could pull deps in Erlang dates from 2007-2009, and it took another few years before more modern tools came to be in what their current form is.
All these bigger projects tend to have a bit weirder idiomatic build setups because they had to haphazardly reimplement bits of (at the time) yet non-existing build systems by hand.
Okay, but if I would start a project today, there would be better tools? Are those documented in the Erlang documentation or are there any recommendations on which tool I should use?
I started learning erlang and was stuck at 2nd rung, problem with erlang is(at-least for me) that there are not enough projects/use cases to learn/build for practice.
Functional programming has too long of a learning curve to the average programmer. A language should be judged by how long it takes average programmers to become proficient in it, not the "Sheldon Cooper" types. In typical medium and large organizations, it's difficult keep being selective about programmer hiring. (There are org structural/political reasons that would take several paragraphs to explain.)
This problem existed since Lisp was invented. The benefits would have to be large to overcome the downsides of this learning curve, and so far they are not, except in certain niches.
I hate the rain the functional parade, but it's been tried and retried for many decades, but will just not fly in the majority of the real world. I'm just the messenger. The jet-powered chainsaw works wonderful in the lab, but actual lumberjacks either can't figure out how to start it or blow their arms off.
If you disagree, please reply instead of negativate me. I would greatly appreciate that.
I'm hardly smart. The only thing I have going is I'm determined.
I have no CS degree, never went to university but have been doing freelance web dev work for ~20 years.
Been through a lot over the years but never took a shot with a functional language until I met Elixir recently.
It really didn't take that long to get to the point with Elixir where things somewhat started to click. I'm still very much a beginner and am learning multiple new things for every few hours I'm coding but I am able to make progress without feeling like I'm in way over my head. Of course I still have so much to learn about Elixir / Phoenix, Erlang and OTP but it'll come in due time. You don't need to take in all of the complexity at once.
I'm multiple thousands of lines of code into developing my first Elixir / Phoenix web app and there has been stumbling along the way but also great strides of progress.
The blog post is not actually about making FP accessible to the masses nor a how to guide about it, and if you read through the post, it’s even stated in there that it’s not important for the language to gain widespread use.
That’s why I downvoted you. It’s not because of your opinion, it’s because it’s probably not in the right thread.
Actually, I'm not fully sure what the author's main point is. If I had to write a short summary based on my best guess, it would be: "I'm disappointed Erlang didn't catch on more, but the general programming & architectural lessons I learned from using it were still worth the effort". Is that clearly a wrong interpretation?
My post relates to measuring "worth" here, and to the reasons why it probably didn't catch on.
I'm not really disappointed Erlang didn't catch on more. As I said in the post, I wanted to take a bit of time to reflect over most of that decade, the ladder of ideas, and things that changed.
I suppose I was looking for a few key ideas/themes as a summary the way we are taught to create and seek out in college writing courses, typically "essay style" you could say. Habit. Instead, it's more of a collection of relatively indendent notes.
I sometimes try to help normals relate to me by asking, "You know Sheldon Cooper from Big Bang Theory? I'm like a stupid, slighty-less-social-idiot Sheldon Cooper."
I identify with Dr. Cooper. (BTW it sucks being like that. Don't ever think we do it because we like it. There are a few perks but it mostly sucks. Also, it's like living in "Idiocracy". I can't watch that movie because it's too painful. That's my life. From my point of view y'all are running around pouring Gatorade on the plants talkin bout "It's got lectrolites!" It's getting seriously scary now IRL too: where the fuck are all the fucking insects!? We should all be fucking terrified right now.)
Anyhow, from my POV the "average" programmers should GTFO and stop peeing in the pool. I would fire 90% of working programmers. They're not needed and actively counter-productive.
Also, FP is coming on stronger today than ever before. You are in actual fact just wrong.
Re: "Anyhow, from my POV the "average" programmers should GTFO and stop peeing in the pool. I would fire 90% of working programmers. They're not needed and actively counter-productive."
This is the theory that the elite are so productive that they can replace say 10 non-elites. The main problem with this is that most problems to be automated (or upgraded) are not well-defined. It takes iterative interaction with analysts, users, testers etc., and this is where probably 2/3 of the effort takes place. Communication and teamwork is more of a bottleneck than raw coding, and the Sheldon Cooper types rarely do well on that.
If the requirements were clearly defined, the 10x-Elite Theory would possibly work in practice. But it's a rare day in May one gets a clearly-defined specification that doesn't shift around a lot.
If you could find a domain having clearly-defined specs, then you could implement that 10x Elite Theory and crush the competition by cranking out software for a fraction of the traditional competitions' price. For example, make an office suite fully compatible with MS-Office, and charge 1/2 of what Microsoft does. You'd be a billionaire. (Past attempts were not sufficiently compatible, which may be a tall order because one has to mirror bugs in MS's software to be so.)
I upvoted you because you're making good points, and graciously. Well met, sorry for being cranky.
> This is the theory that the elite are so productive that they can replace say 10 non-elites.
No no no, I'm saying that the non-elites are counter-productive, that they contribute negative productivity.
(FWIW, I've met at least one "10x" in real life. He made his mark out of Uni by co-founding a company that made their own self-configuring ("Autonomous OS") box that really worked. Sold to IBM.)
> If you could find a domain having clearly-defined specs, then you could implement that 10x Elite Theory and crush the competition by cranking out software for a fraction of the traditional competitions' price.
> I'm saying that the non-elites are counter-productive, that they contribute negative productivity.
You may have concrete examples of that, but I couldn't agree based on my own perspective/experience. I've worked on a team with an elite programmer (in terms of actual 10x productivity) for nearly 3 years now. I know they're not all the same, but this guy isn't particularly sophisticated or cerebral in his approach; in fact, he wouldn't want to take on architectural concerns, refactoring, or really complex problems - I and another dev take care of that. He's just incredibly productive, by any measure you'd like to use -- LOC contributed, modules written, features implemented, issues closed. I've sometimes wondered if he's a front for an entire team behind him.
That doesn't mean the rest of us aren't worth having on the team. We are definitely contributing positively. In fact, he couldn't work anywhere close to the rate he does if he had to take care of the stuff the rest of us do.
Ridiculously sharp guy, and his work has enabled so much other stuff and so many other people, eh?
- - - -
No team of ten people could do what arcfide does, eh? It would all get bogged down in intercommunication, etc. We pay a price for programming with sub-elite programmers. Metaphorically, I'm trying to say that teams dragging stone blocks are hindering the adoption of the wheel. (I'm not trying to make stone-block-draggers feel bad, FWIW.)
Can you please not post like this so we don't have to ban you? If instead you'd read the guidelines and take the spirit of this site to heart, we'd be grateful.
I think the current research on learnability doesn't come out quite this way. People are quite ok with declarative formulas, consider eg the popularity of spreadsheet programs among non-programmers. But people who learned imperative programming first need mental work to switch.
There are lots of things that were tried and retried for decades before they caught on, which are now standard. For example look at the 90s when Java and Python came around - GC and memory safety were radical ideas for the industry where C/C++ were standard, even though they had been around in various languages for decades.
I have found that I like Lisp-Flavoured-Erlang (LFE) a bit more, since I still find the prolog-esque syntax a bit frustrating. I've been doing this stuff for like 6 years, and I still occasionally get tripped up on when to do a comma, semicolon, or period occasionally. While I'm not a huge fan of LISP-2 semantics, overall I find the syntax for LFE to be a lot more consistent than raw Erlang.
This isn't to crap all over regular Erlang though; Erlang was the first language I had seen that fully embraced pattern-matching, and I find that kind of pattern to be incredibly elegant.
If someone reading this hasn't tried out Erlang, do yourself a favor, download and install it, and build a simple TCP chat server. I can virtually guarantee you that it will be easier than anything you've built in C/C++, and it's incredibly satisfying to have something you built in a few hours have the ability to scale correctly.