8 ms·

Ask HN: Is Erlang an albatross to Elixir adoption?

105 points by srevenant 4y ago

I pose this question in all seriousness. An observation: after being an elixir developer for a few years now, and bringing new talent into the mix (no pun intended), is that it's a friction point for new devs learning Elixir when they invariably stumble across the things in erlang — libraries and the like. I'd hoped I could avoid it myself, but it's too interdependent. The notion that to learn a language you also need to learn a second one is not great. Imagine people saying "cool, learn python, but oh, you also should brush up on cobol while you are at it, you know." It's just bizarre. And before the vocal defenders kick in I want to clarify that the following response (which is what I usually hear) is NOT a valid response to the question being posed: "Erlang is easy, it's just semantics that are different" While this statement might be true, it doesn't address my point. That something is easy to do for one person is irrelevant to the fact it causes friction for new devs and may hinder adoption. I think there are many amazing points to Elixir, and thanks to Erlang it has a lot of amazing roots. I know both communities are trying to make both co-exist well. But every time I come across an Erlang library, invariably the documentation is a nightmare (if it exists at all) and I have to read the code just to figure something out. This is true also of many system level things even in Erlang. The docs are horrific. Reading the code is NOT an answer. I don't know what a solution is, but perhaps a concerted effort to create a documentation and library ecosystem that never links back to Erlang would help. And where there are critical systems that use an Erlang library, perhaps rebuilding it in Elixir is in order? Flame away :) I ask the question because I'm curious how others feel about it, and I want to help promote more adoption of Elixir. (And hearing from ALL sides, not just defenders of the faith. What about people who've tried elixir and moved on?)

myth_drannon 4y ago
It's the same way that the Java/JVM prevents Clojure being picked up more. To figure out Clojure's errors you need to be familiar with Java/JVM (most of time). Elm is a great example of a language that doesn't suffer from being written in Haskell, you basically completely unaware of it and not required to dip your toes into Haskell's ecosystem.
- lukaszkorecki 4y ago
  In my experience (7+ years of using Clojure) this is caused by the misunderstanding of what Clojure actually is: it's a LISP designed for the JVM, you cannot escape the host and pretend it's not there. In return you get access to one of the biggest software ecosystems and pull any library from Maven Central etc. Coming from Ruby/Go/JS to Clojure was definitely harder than I expected but rather than fighting "this stupid JVM" it made more sense to buy into the idea of how Clojure is built and used.
  - ModernMech 4y ago
    > It's a LISP designed for the JVM Honestly, this should be the Clojure tagline. Would solve a lot of the confusion. To be truthful, I never pictured it that way, but to be fair I think Clojure sells itself as more than that.
    - lispm 4y ago
      But it's more than that. It has different data structures, operators and semantics from Lisp - stuff which goes beyond just a simple retargeting to the JVM. It also provides an integration into/on top of the JVM, but also stuff like persistent functional data structures, avoids OOP, ... It's opinionated. Lisp and Scheme on the JVM exist, too.
      - melony 4y ago
        I wish it would focus more on using technology provided by the underlying platform instead of its own half-baked and slow implementations. Clojure’s concurrency story is horrendous. There are multiple versions of shared memory concurrency on its JS and JVM runtimes but none of them scales to match the performance of the local APIs (Promises and Project Loom for Java). They are always playing catch-up five years after the original features have been shipped. Even today, trying to find an up to date library for features like WebWorkers or WebRTC that has seen a commit in the past year is a waste of time.
- handsaway 4y ago
fyzix 4y ago
I must say that having to learn Erlang killed my desire to learn gleam. I just wanted to explore a functional language and having to do 2 at once wasn't worth it. I chose f# in the end.
- ithrow 4y ago
  F# has the same problem, you have to learn C#.
weatherlite 4y ago
Elixir has a reputation for being relatively complicated and this (having to understand Erlang when developing in Elixir) is one of the reasons. Many CTO's don't want to touch it due to extra complexity, lack of devs etc etc. If concurrency is that important (it usually isn't but lets say it is) they can go with k8s - Node, Go etc (it doesn't really matter - k8s will quite easily scale just about any stack). There are just many easier paths of less resistance than Elixir in most cases. Also - Elixir is functional or close to functional so it is quite a big mind shift so another hurdle to onboard newcomers. Anyway, trying to increase a language's adoption is very very hard..
salawat 4y ago
I want to point something out from an information tgeoretic point of view. Can you say you know what is going on if you don't read the implementation code? I'm even fine with extending that to executable code. You must read code. Code use sans understanding is dangerous. You can do immense harm without even realizing you're doing it. Look at Log4Shell, or MCAS. The majority of your time as a computing professional should be spent reading code you'll be using. Abstraction is nice. Until it isn't. I'll never understand the I shouldn't have to read code school of thinking. It's like saying you should never have to learn arithmetic. Now there's a case to be made that in development communities that value convention, yes, you can get to a point you don't have to read as much code in that community, given everyone plays by the rules. Colors.js or node-ipc is what happens when they don't. So even then, don't read at your own peril.
JohnHaugeland 4y ago
> What about people who've tried elixir and moved on? I've tried it three times and it offered me nothing Erlang didn't. Erlang, on the other hand, offers me much that Elixir does not. In truth, I've never met anyone who likes Elixir except people who were already Ruby programmers. What's particularly weird is your attempt to dig at the Erlang docs. They're extracted the exact same way the Elixir ones are; it's just a different CSS theme. C'mon, dude. This is very much a "coffeescript is held back by javascript" post. Yes, we know, Kotlin is really burnt by its Java roots, etc, etc. The base language always lives. The descended language rarely does.
- Skinney 4y ago
  > Erlang, on the other hand, offers me much that Elixir does not. Genuinly curious. Like what?
- xzyyyz 4y ago
  Nice to meet you. I am completely un-Ruby Pythonista, and I like Elixir a lot. I felt the same way as topic starter, and I invested couple months to make several tools Elixir-native -- the project was cancelled with the layoff. I think, this is a compromise. I strongly dislike Erlang abstraction leak, but I understand the desire to deliver the language, and iterate on cleaning up toolchain & libraries later.
- srevenant 4y ago
  Although I also have issue w/the Elixir docs, they tend to have more explanations in them than the Erlang ones. Marginally :) I am one who came not from Ruby, btw. My roots come from a variety of things including Smalltalk, C, C++, Perl (dare I admit), Java, Javascript and Python, among those most influential on my life (and in that order). I'm really happy w/Elixir, finally getting back to a better true object oriented system (for those who know the roots of such).
  - devoutsalsa 4y ago
    Reminds me of this blog post: "The Most Object-Oriented Language" => https://blog.noredink.com/post/142689001488/the-most-object-oriented-language https://blog.noredink.com/post/142689001488/the-most-object-...
adamors 4y ago
I feel like this is an issue with all superset languages or however you want to call them and should be taken into account by anyone learning one of these. You can't really learn Elixir without also learning _some_ Erlang, you can't really learn TypeScript without learning some Javascript, you can't really learn Clojure without picking up some Java. The platform/base language is abstracted away to some extent but not completely. It's especially visible when trying to use libraries used in the platform language.
- ch4s3 4y ago
  > You can't really learn Elixir without also learning _some_ Erlang I'd argue that you end up learning a good bit about OTP, Erlang's standard library, and some stuff about the VM but very little Erlang in practice. Although if you know about BEAM, and some of the standard library there isn't much "Erlang" to learn after that. It doesn't seem to leak into Elixir the way Java does in Clojure, and the surface area of Erlang is smaller than Java anyway.
  - ravi-delia 4y ago
    Yeah Erlang idioms are what make Elixir so powerful, but you basically don't have to touch actual Erlang. I've messed around, just because I felt like I should have some appreciation for the work Erlang developers put in, but the Elixir wrappers are good enough it's almost never necessary. Even if you need an Erlang library, you're just calling the functions and the docs are usually pretty good.
  - adamors 4y ago
    If you use these superset languages day-to-day you will end up interfacing with the base/platform language at some point. Just recently I had to figure out why the Elixir Kafka library didn't support something and I ended up using the wrapped Erlang library at the end. Without some Erlang knowledge I would have been completely lost.
    - ch4s3 4y ago
      I don’t exactly disagree, but what I mean is that in learning Elixir you’ll learn about the BEAM and by the time you need to peek under the hood, it’s just syntax that’s different mostly.
udfalkso 4y ago
I've built quite a lot with Elixir at this point, and I love it, and I haven't written any erlang at all (other than maybe a couple of very simple function calls). I don't think this is a real problem, except for those building very complex applications.
eric4smith 4y ago
I think we are just more used to Elixir docs. The few times I've had to jump into Erlang docs, in truth, it has not been much of a problem. My main problems have always been the differences in string/binaries types between Erlang and Elixir.
jacquesm 4y ago
This is why I've always just settled for the 'root' language and try to stay away from derivatives even if those offer a lot of goodies the 'root' does not offer. So no Typescript, Clojure or Elixir for me. I also think that the main attraction of an eco system is how long term stable it is and usually the second layer is less long term stable than the foundation. And usually such a 'derivative' language only serves to fragment the eco system (community, contributions) of the 'root', not to enhance it.
- dimgl 4y ago
  One of those is not like the other. JavaScript and TypeScript are almost interoperable. You don't have to relearn the semantics of the language to use a JavaScript library in TypeScript. It's is an extremely light superset compared to Clojure, Scala, Elixir, Kotlin, etc.
  - jacquesm 4y ago
    Typescript requires an intermediate step though. We had the Typescript vs JS debate when starting out with pianojacq.com and I was pretty strongly committed to doing it in plain JS and not to have any tooling dependencies or build step. Which I think is the one thing that makes JS at least moderately interesting: that it is a language that in theory does not require any tooling beyond the browser. Of course, the day Typescript is supported natively by the browsers that argument will die. But for now that does not seem to be the case.
    - dimgl 4y ago
      I agree that just JavaScript is okay for simple applications. In fact I didn't use TypeScript for a really long time because getting the tooling going can be cumbersome at first. TypeScript shines with complex webapps. Having the typing prevents a whole class of issues and helps with refactoring quite a bit.
      - jacquesm 4y ago
        Yes, agreed. And small projects tend to grow to much larger projects over time so it may well make sense to choose Typescript even if your project is still small.
scottmessinger 4y ago
FWIW, I've been using Elixir in production since 2016 and haven't found I've needed to learn any erlang. For context, we use Elixir for our backend and serve around ~100/rps over websockets. We've integrated Elixir into Stripe, Segment, Google, and Xero and haven't found we've needed Erlang libraries for any of those integrations or any of the other parts of our code base. > Elixir when they invariably stumble across the things in erlang — libraries and the like. I'd hoped I could avoid it myself, but it's too interdependent. This hasn't been true in my experience. I'd be curious to hear which Erlang libraries the OP has been using.
- ch4s3 4y ago
  If nothing else you're likely to run into ETS, it's really nice and easy to use. But even still, the calls are pretty easy to make, and the docs are good. You don't really even need to understand any Erlang syntax, it's just built into OTP.
dimgl 4y ago
Yes, it absolutely is. The few times I did work with Elixir I came across a few instances where I had to use libraries that had not been ported over to Elixir yet so I had to deal with Erlang. It wasn't fun. That being said, I think it's only one of the issues affecting Elixir adoption. Elixir, while undoubtedly a great language, is not very easy to use. The docs have a huge focus on the language and its syntax, but don't really hold the hand of developers of imperative languages who want to understand the paradigm of functional programming. It took me an obscenely long amount of time for me to understand how a GenServer works, and how the entrypoints for an application work. This is a big pain point with learning Elixir and every time I come back to it I have to do this big mental overhead that IMO just isn't productive.
- konfusinomicon 4y ago
  did you have an aha moment that finally made it all (genservers and entry points) make sense? if so, what was it?
- alberth 4y ago
  > I had to use libraries that had not been ported over to Elixir yet so I had to deal with Erlang Why do these libraries need to be ported to Elixir at all?
  - dimgl 4y ago
    IIRC they don't, but as someone who doesn't know Erlang, the Erlang documentation was really hard to read and the APIs differed from other Elixir libraries.
    - srevenant 4y ago
      +100 — the heart of the problem
      - wink 4y ago
        Imagine it's an important lib you can't just replace and there's a bug you need fixed and can't just wait for the maintainer to do it for you. Now you suddenly need to understand that language enough to do that. To some extent this happens very often, I've had it in Clojure+Java and PHP+C libraries.
my69thaccount 4y ago
This is just a result of your own context and background. If you were an Erlang developer then Elixir would come naturally. If you started to learn Python as an Erlang developer and had to understand its C implementation details (via SciPy etc, which operations are implemented in Python or natively) you would make this same post in reverse. But you're taking that for granted because you are already coming from that position.
alberth 4y ago
Raw performance is the actual albatross. IMHO, the low raw performance of Erlang is what's holding it back from mass adoption. (Even marquee Erlang/Elixir users like Discord, still have to use Rust NIFs to overcome the slow Erlang runtime) People have a hard time understanding how Erlang can have such: high concurrency, low latency & tight standard deviations ... when people are just accustom to looking at raw performance benchmarks (where Erlang does quite poorly). While BeamASM (JIT) is very exciting, the reality is that the Erlang runtime has only speed up by ~25% over the last decade, where other languages like JS, Go, PHP have seen >150% speed ups (and Erlang was already considerably slower than these languages prior to their speed ups).
- jacquesm 4y ago
  Erlang excels at the 'hard' parts of the problem space having to do with complex distributed ultra reliable systems, the 'number crunching' bits are offloaded to specialist languages because the underlying language model that Erlang uses does not lend itself for the kind of optimization that JS, Go, PHP etc have available to them simply because their runtime model is so completely different. The biggest issue from what I know about how Erlang works internally is not so much the fact that Erlang could not in principle be made fast (and indeed, BeamASM will if it makes it to mainstream become a good step in the right direction), but that the whole way in which Erlang schedules its threads is super ineffecient in terms of cache use and besides the byte code interpreter relies on its ability to keep track of the number of reductions that it has done to determine when a thread has had enough cycles and we need to move on. This means there will always be a fairly hard upper limit as to how far you can optimize Erlang byte code, it is at its core a cooperative multi tasking operating system inside a user process. One of the more elegant ways to do such interop is to isolate your number crunching code to a separate process group working their way through a queue one unit of work at the time that way you can use all of the Erlang goodies and still get very good performance.
  - derefr 4y ago
    > One of the more elegant ways to do such interop is to isolate your number crunching code to a separate process group Or, if you want to maximize perf inside some hot section of code (say, a game-engine renderer) while also retaining Erlang semantics for how it interacts with the rest of the system, you can write your code as a "threaded NIF" — a native thread (in C or Rust or whatever) that sends messages back over to the arbitrary Erlang processes in its address-space (not just its owner process!) as it works.
malkosta 4y ago
I work in a company along with dozens of Elixir engineers. It's pretty rare that anybody needs to read/write any Erlang code. It's a bit rare that anybody has to read Erlang documentation. And when that happens, it isn't a burden.
sergiotapia 4y ago
Been using Elixir since 2016 and I don't know anything about Erlang beyond "it uses BEAM". You don't need Erlang to use Elixir.
freedomben 4y ago
I think it's important to differentiate between groups, because it is definitely possible (and normal) in some situations not to ever need to understand Erlang or know anything about it. If you are building a Phoenix web app, you can go many years and never run into non-trivial/non-obvious Erlang (excepting perhaps a small thing here or there, although many of those have Elixir wrappers now). I've also heard similar regarding Nerves apps. On the other hand if you're writing a non-trivial CLI or app that doesn't use any sort of "framework" and you have to dig into OTP more than just the standard well-documented-in-elixir functions, then you will most likely run into the problem described in the question. I don't think it's "an albatross" but it's certainly not ideal. Now that real apps/companies are using Elixir and it's not just the hobbiest/early adopters, it's an important question to ask and I'm glad to see it! I wonder how much we can solve this by improving the Elixir docs. If we better document the areas where people end up digging into Erlang, it seems like it would help. I'm hesitant to accept the "to be a Sr Elixir dev you might just need to learn a little Erlang" but that's also worth considering.
- jacquesm 4y ago
  > I don't think it's "an albatross" but it's certainly not ideal. I find the whole framing problematic. To call the foundation that you are building on and that you seek to displace an albatross is missing the option that it could easily be seen as being the other way around.
  - freedomben 4y ago
    > I find the whole framing problematic. To call the foundation that you are building on and that you seek to displace an albatross is missing the option that it could easily be seen as being the other way around. well of course, if you're coming from an Erlang perspective, Elixir is a language that solved/solves a problem that doesn't exist. This is a valid view, but OP's thread is specifically asking as an Elixir dev with the perspective that Elixir solves a problem, rather than introduces one. Recognizing that different perspectives exist isn't bad (and in many cases is very good), but it doesn't feel super constructive in a thread that precludes those perspectives. It seems a little like forum questions saying something like, "how do I do X on Windows?" and somebody replies, "Install OS X."
chrismccord 4y ago
As the creator of Phoenix, I've never written an Erlang program fwiw. That said, I frequent the Erlang docs and most seasoned Elixir developers will do the same because the standard library is a wealth of features, and the documentation while not 2022 polished, remains a remarkable resource. > I don't know what a solution is, but perhaps a concerted effort to create a documentation and library ecosystem that never links back to Erlang would help. And where there are critical systems that use an Erlang library, perhaps rebuilding it in Elixir is in order? This would not be helpful. Erlang has over three decades of features, heritage, and libraries. Elixir helped usher in first class documentation as a core language feature, but that doesn't make rock solid Erlang libraries somehow things that should be avoided. Rewriting for rewriting sake is also not a good idea. One of the benefits of bootstrapping off an already amazing platform is exactly because you don't have to invent the universe. See Clojure and Java. In fact, Elixir has helped Erlang up its documentation game, and there is already work done to help the ecosystems share documentation tools. Both ecosystems work by rising together, not masking one or the other. We see this in tools like `telemetry`, documentation generators, and recently the Erlang Ecosystem Foundation: https://erlef.org https://erlef.org
- _acco 4y ago
  Highlighting an important distinction Chris makes: there's a huge difference between needing to learn to read/understand the basic syntax of a language and needing to learn to write it. When writing Elixir, yes, you'll be exposed to Erlang syntax/docs sooner or later. But you're not writing Erlang, so you never need to learn how to: - Compile more than a couple lines of Erlang into a function - Create an Erlang module/file - Learn Erlang's build tooling - Cold recall its syntax Creating something functional from scratch in a language is 100x (1000x?) more challenging than learning how to roughly read it. I've been programming full-time in Elixir for a couple years. All told, I think I spent 3-5 hours one afternoon learning the basics of Erlang's syntax so I could better read the docs. Haven't had to think about it consciously since.
  - SOLAR_FIELDS 4y ago
    I can read C++ pretty well, I know how to build, compile, and run C++, but I probably couldn't write very good C++. I think it's like reading a book about how a machine gun is used in action and constructing one vs. given a machine gun with no hands-on training and trying to use it myself.
aeturnum 4y ago
The phenomenon you're talking about, imo, doesn't have anything to do with Erlang or Elixir. All languages have limits to what you can do natively. There will always be some tasks where you will cross a language barrier from "your" language to another. To me, the question is: "Is the area that Elixir covers big enough to recommend?" and I think the answer is yes. I do not think most programmers need to learn Erlang to use Elixir - but I think programmers will often encounter Erlang and can decide to learn it (or look for a different library that's pure Elixir). I am sure that there are individual programmers who would learn pure Elixir, but get 'scared away' by Erlang...but I doubt they are hurting the language ecosystem in a meaningful way. Focusing on this would both be optimizing something that does not, in general, matter - and would be trying to achieve an impossible goal.
pera 4y ago
> The notion that to learn a language you also need to learn a second one is not great It depends on how far you're trying to go maybe? You could argue that, for any given programming language, there is always a point where you will have to learn some intermediate representation language to achieve certain tasks; I personally don't think this is unique to Elixir.
dogleash 4y ago
> "cool, learn python, but oh, you also should brush up on cobol while you are at it, you know." It's just bizarre. It's more like learning python and also c. Depending on the library, python can smell a lot like the c underneath. Sometimes you'd never know a python library is written in c, sometimes it's a manageable leak like the socket module, and sometimes it's opencv. Write enough python and you'll find C library wrappers so atrocious and/or badly documented that you just whip out ctypes and hack out a replacement wrapper yourself. The reason you're hearing the answer you preemptively dismissed in the OP is that the distance between erlang and elixer is thin, much smaller than python and c. That's sorta the bed that elixir made itself. If people believe elixir is held back by erlang, and that elixir should do it's best to hide erlang, then the the albatross is probably elixir around erlang's neck. Mindshare and time spent contributing (e.g. to documentation) should be further split between two very similar ecosystems? For what? Because it doesn't look enough like Ruby?
atonse 4y ago
I've used Elixir in production since 2016 and I have only had to deeply introspect erlang code exactly once, when I had to implement OIDC using Ueberauth and it used the underlying oidcc erlang library (which was extremely cryptic and wasted days of my life with absolutely useless error messages). And then I remembered why erlang never picked up. It was a huge pain in the butt to try to read the erlang. Didn't like it at all. Apart from that, we've done tons and tons of work in elixir and never had to touch Erlang, and for that I'm eternally grateful.
dpeck 4y ago
https://en.m.wikipedia.org/wiki/Betteridge's_law_of_headlines https://en.m.wikipedia.org/wiki/Betteridge's_law_of_headline...
Communitivity 4y ago
I learned Elixir early on, and then had other tasks and languages I needed to devote my time to. So I haven't kept up with it. I remember though that learning Erlang first well (including how BEAM worked) was a huge help to me in learning Elixir. It lets you understand what is going on under the hood. That said, I've used the analogy of Elixir is to Erlang the way Java is to JVM byte code. That means you can master Elixir without ever coding Erlang, but I think you'll have a harder time of it.
sa1 4y ago
> "Erlang is easy, it's just semantics that are different" The opposite: syntax's different, similar semantics.
yumraj 4y ago
Perhaps. My parallel example would be the Play Framework. Play 1.x was written in Java, but supported both Java and Scala, and was fantastic, easy to use and one of the most productive and performant full-stack framework for web development. Then, they created Play 2.x, where the core was written in Scala and if I remember correctly even used Scala for its HTML template. Even though it supported Java, and obviously Scala, there was a definite drop in its usage and I believe it majorly impacted its adoption. Personally I think if they'd stayed with the Play 1.x model, it would have been extremely successful.
throwaway81523 4y ago
I've used Erlang and have been interested in Elixir but haven't used it. After a little getting used to, I've generally liked the Erlang docs. I have the impression that Elixir is just Erlang with different surface syntax so the main real differences are in the library culture (Elixir's are more Ruby-inspired, with Rails's inanities mostly cleaned up). From a Lisp background, all these languages are pretty much the same. Erlang/Elixir's concurrency story is far better than say Python's, but that's not really about the language per se. I'd actually like a statically typed BEAM language. A few of these have been attempted, but I don't think any have gotten traction.
omgmajk 4y ago
The analogy ~"learning python but also cobol" is not quite correct. It's more "learning kotlin but you also have to learn a bit of java".
johnisgood 4y ago
I love Erlang. Elixir seems to go away from the philosophy of Erlang, and they are pushy about it, they try to make Erlang worse in that regard. Leave Erlang alone, and stick to Elixir, please.
elesbao 4y ago
Tackling a new language over BEAM and integrating with Erlang is as big as Clojure with JVM - The thing is that Elixir used to be more erlang-y than it is now and does a decent job hiding the hardcore functional/process comm/OTP plumbing. I don't see our team writing too much Erlang but we know that a full distributed Elixir production setup will incur the same operational load as in Erlang. W.r.t documentation, I found Francesco Cesare book (and the original Erlang programming book by Joe Armstrong) pretty good to help where the doc was too terse. Maybe you are looking for documentation on frameworks ? My main block was to be used to read http or database framework docs and jump straight into functional programming and pure language documentation... just an idea.
travisgriggs 4y ago
My N00b take on Elixir in general (were N00B = Have my first app, an MQTT/API bridge written and deployed running on Ubuntu employing Bandit, Finch, Tortoise, OpenAPISpex, and Jason). The immediate answer would be no. I would say 5%-15% of my questions asked on the Slack channel have ended up in Erlang land. The first time someone answered with "you want :binary.bin_to_list()", I was completely confused. "What is :binary?" It took me a minute for the lightbulbs to say "remember, you read Erlang syntax is upside down from Elixir and maybe that'a an Erlang thing?" The erlang docs are not bad, but they are structured and navigated very differently than the Elixir ones. And the notation differs. It can look almost like BNF some times. I find it inconvenient and annoying that this is so, but never felt like it was an albatross. It's a weird split, because many common things ARE in both systems. But then, some things don't make the cut. And experienced people just "know". Hopefully, you're around one of those people either directly or virtually. I've asked why not just transcode the entire erlang library over. If the languages are nearly associative, just make a process that (mostly) automates a conversion. I asked about this in the Slack channel, but the sentiment seemed to be "decent idea, but not worth the work." I wish I had opportunity to do more Elixir/Erlang. I have a goal to see if I can't learn some LiveView stuff. In my short journey I've worked up my list of "love this/wish this were better." This issue would be a cool thing to improve, but it wouldn't make my top 10. My loves? * I love the straightforward simplicity of the language, it reminds me of Smalltalk that way * I really like pattern matching, and recursion. I realized how much time I spend in other languages writing code that describes where the code goes next. Pattern matching and recursion I really like * The Slack community is great. Better than just about any other "open source" community I've gotten help from in the past few years. * The key players (José, Chris, etc) are accessible and really nice guys. Submitting a documentation clarification PR was super nice because of José. * I love piping. I'm told newbies overdo this. I'm still loving overdoing it. I wish the syntax were a little less difficult to type; I should figure out how to do some hotkey thing I guess. * Binary. Wow. Parsing binary data streams in Elixir just rocks. * I like OTP more and more; often the community seems at odds with it. It's not "purely functional". This may be the area the author was originally barking at. Things that disappoint me (so far, but I am open/hopeful to coming round in some cases): * VSCode is OK. But a language like this really wants a decent IDE. I want to work on functions, not files. * I love/hate the formatter. I love that there is one and I get consistency. But it's not associative. A formatter should format my code, not just kind of format it. If it made a 3 lines out of one of my long lines, but then I shorten the code, so that it can now fit on one line, it should do that. It can't because it doesn't know the difference between extra new lines I put in and one's it added. The reality is, I want it to format the whole file, not just the horizontal space. The fact that newlines are part of the syntax in some cases makes this even more of a problem. IMO syntax either own newlines completely (python) or leave it as a presentation character and design the syntax so the whole program could go on one line if it needed to. * To date, I have found the defstruct story unfulfilling. The syntax is a bit weighty to type %SomeStruct{foo: 1, bar: 13} requires me to do a lot of slow reaching shifts and it always feels like it slows me down. One defstruct per module hasn't scaled well for me. When I switch back to Python/Kotlin/Swift, the struct/dataclass just works better for "modelling" up data. * "Namespaces are a honking good idea - we should do more of them!" Elixir looks like it has namespaces with Dotted.Module.Names. But only barely. In fact, since there are edge cases where nesting modules creates issues, I took to never nesting them, even when using Similiar.Dotted.Prefixes to "group" them. Eventually, you realize you could just use _ or pretty much any separator. The dot's have very little value. I wish the namespace story was more like Python's (but not the shadow binding nonsense). * Macros are awesome. BUT, sometimes it can get really confusing what's going on. I don't love the quote/unquote thing. What I have sorely missed with some macro heavy libraries is the ability in the IDE to see what the code turns into. Kind of like running just the C Preprocessor on macro heavy C code to see what's really going on. * I do not love do/end. We have punctuating characters in romanized languages for a reason. They structure and organize the words and phrases we use inside of them. When we use alphabetic words to do this, the brain has to parse more to separate the structuring elements from the content. * I think I've come to appreciate the "batteries included" language approach more. There's a balance of course. Python has some stuff in it that just seems silly to be in the base library. But a lot of things is just there ready to be used. In Elixir, I'm left guessing what extra modules to use. It's hard to know what's being actively supported. And discovery is yuck. I wish for more ItDoesThis boring names rather than cute/clever plays on words for package names. For example, would the lay reader be able to guess what my Bandit, Tortoise, and Finch modules actually do?
rkallos 4y ago
Chiming in with 6 years of professional Erlang experience. I'm somewhat familiar with Elixir, having worked on some Elixir codebases for a few months. > The notion that to learn a language you also need to learn a second one is not great. [...] It's just bizarre. I disagree. I don't think it's bizarre. I expect to sometimes have to poke around in C code when writing Erlang or Python. It's also fairly common for C/C++ developers to look at the assembly output of some piece of code using https://godbolt.org/ https://godbolt.org/. > Reading the code is NOT an answer. Again, I disagree, and I think this perspective is harmful to career development. Knowing how things work on a deep(er) level is a superpower. When you're writing Elixir, do you never open up a .ex file in the standard library to see how something is implemented? Are you not at all interested in what powers things like Phoenix.PubSub? > I don't know what a solution is, but perhaps a concerted effort to create a documentation and library ecosystem that never links back to Erlang would help. I suspect that a library ecosystem that doesn't require Erlang would be a huge effort to implement and test, and would wind up pulling in all of the ideas from Erlang that you haven't learned/mastered yet. A better alternative would be to accept the fact that Elixir builds on top of Erlang, and understand that a deeper knowledge of Erlang is going to help you improve as an Elixir developer. > And where there are critical systems that use an Erlang library, perhaps rebuilding it in Elixir is in order? I'm definitely biased, but I would be much less trusting of an Elixir copy of a 'critical' Erlang library. Many of the selling points of Elixir that lead to very concise code (read: macros, 'using', and others) are things that make it difficult for me to develop a deep understanding of a library. It's cool to use DSLs like Ecto and Plug, but I have a much harder time understanding those libraries as a result. Erlang's unambiguous syntax and its basic text-substitution-based macro system are much easier for me to understand, and while it takes more effort to write APIs and code that are as concise as what's available in Elixir, I know that I can open up an Erlang file and trust that much less is hidden from me.
rramadass 4y ago
Absolutely not! Elixir is to Erlang AS C++ is to C; you cannot understand the former without understanding the latter.
adolfont 4y ago
You are right. However I believe that, after some time, beginner Elixir developers become intermediate Elixir developers and they get to used to having a little bit of Erlang here and there.

derefr 4y ago

> While BeamASM (JIT) is very exciting, the reality is that the Erlang runtime has only speed up by ~25% over the last decade Yes... because perf hasn't really been a focus for Erlang until about 1.5 years ago. Various (usually academic) third parties have contributed big performance-enhancing patchsets (the earlier JIT; Dialyzer and then HiPE based on Dialyzer analysis; etc.) but these have then languished, with attempts to further development on them slowing to a crawl over time. The patchsets were just "too big to be digested properly"† by a team of core maintainers who 1. didn't write the code, and don't fully understand it, and 2. who aren't CS academics themselves. Each of these indigestible patchsets was eventually dropped, throwing away any follow-on in-tree work done to it, and dropping perf back to where it was before said patchset was introduced. The new work is in-tree, done ground-up by the core maintainers themselves, and so is actually showing linear improvements in speed. This not only includes runtime speed, but also the batteries-included addition of long-ignored performance-oriented features, like atomic counters and fast global readonly modules (and the runtime itself being gradually rewritten in terms of these!) † This is exactly why, in the Linux kernel, big patchsets aren't accepted as-is, but rather are required to be broken down into small changes that 1. can add value on their own, and 2. can be molded to fit the design philosophy of the kernel on their own. This is why e.g. the "containers" patch from OpenVZ was never pulled in; but instead, each bit of it was gradually reworked into the cgroups + namespaces code that powers Linux containers today.

alberth 4y ago
> perf hasn't really been a focus for Erlang until about 1.5 years ago. The core maintainers have been working on JIT/perf for 10-years. You can see Lukas own described 10-year journey documented below. https://drive.google.com/file/d/1hHCs90kDX_wJ9AbLzGNu5bZKdIVWsLsg/view https://drive.google.com/file/d/1hHCs90kDX_wJ9AbLzGNu5bZKdIV...
- derefr 4y ago
  I've had this conversation on HN three times now, and I'm misunderstood each time I say it. It's getting a bit frustrating. I'm not saying that the Erlang maintainers haven't been trying to work on perf. I'm saying that their approach to working on perf has, until recently, been to focus on building on top of large blobs of relatively-opaque third-party code — either in-tree code, like HiPE; or library code, like LLVM. These approaches haven't been maintainable, and have eventually been dropped. The difference in the last 1.5 years is that the perf enhancement this time is purely due to optimizations to the emulator and runtime — and improvements to the way the compiler works enabling better runtime insight into the code — with no big blobs of opaque code being relied upon. There's nothing extra to maintain; no big experimental perf-hack to enable with a feature flag. It's just the runtime itself being improved. With previous attempts, the perf improvement was a sigmoid sawtooth: perf increased, levelled off, and then dropped back down. This time, the perf improvement is a linear ratchet function. --- My other point, is that until fairly recently, most of Erlang's biggest users were "enterprise" customers with embedded use-cases, whose #1 concern was stability — they didn't care about perf-enhancing new language features, because they weren't about to rewrite their working+tested+certified code just to get better perf. They were only interested in "transparent" perf enhancements. More recently, though, large non-"enterprise" corporate users of the Erlang runtime, like WhatsApp and Discord, have been migrating their work developing third-party perf-enhancing feature modules upstream as language features, because they are interested in rewriting code to increase perf — as long as that rewritten code is also just as maintainable (if not moreso.)
  - alberth 4y ago
    > I'm saying that their approach to working on perf has, until recently, been to focus on building on top of large blobs Totally agree. Off topic: I really love Erlang/Elixir - but I'm beginning to losing hope in being able to see a path where it can 3x improve performance. There has be a lot of people for a very long time been hoping this major improvement will come "soon". I'm unfortunately just not seeing it happening or a path to it ever happening. I hope I'm wrong.
MrWiffles 4y ago
As an Elixir noob, I'm reading these comments about performance and coming to some conclusions that I'd like to ask ya'll to idiot-check me on. First, let me establish that there are at least two ways of thinking about performance in the context of a server-side HTTP application: 1) Per-request speed ("from receiving the request to response, single-threaded, X ms") 2) Throughput-based metrics ("We can serve X requests per second with Y cores spread across Z nodes") I think both ways of measurement have value, but in this context I'm operating under the assumption that we're focused on option 2. Correct me if I'm wrong. Now, with that understanding in place, it sounds to me like Elixir/Erlang performs "pretty good" in terms of that overall throughput if you leverage the multithreading capabilities in building your apps and thread scheduling isn't terribly contentious (hopefully not a lot of other processes/threads competing for execution time on the same machine as your Elixir app), but measured on a raw per-operation speed metric it doesn't quite stack up to other non-compiled languages like PHP or maybe even Ruby (which would shock me but let's just poke that bear anyway, see what kinda growl we get...). So if indeed my understanding is right, my next question is: "how much of a performance reduction would we realistically see with an Elixir app that's otherwise well built and doing the same thing?" Issues of misconfiguration, bad deployment architecture, etc. withstanding. And if that question is indeed valid/not-batshit-crazy, my next would be: "does that degredation matter or scale in a multi-node/clustered deployment context?" In other words, if you have a say 50-node (be they VMs or containers) Elixir app, built well, properly configured and deployed, load balanced etc., is it going to have significantly/noticeably slower throughput than an equivalent PHP/Java/Ruby/$OTHERLANG app when compared as close to apples-to-apples as you can get that sort of thing? (Maybe take Ruby out of the equation here with issues of GIL/threading being what they are over there. Haven't had the chance to work with recent Ruby though so if threading is a valid comparison nowadays, by all means keep it in mind!) I'm just trying to get a sense for whether or not I'm barkin' up the wrong tree with my recent interest in Elixir. Am I wasting my time right now and maybe should wait a few years before really tearing into it, or is it effectively in a real-world, non-academic scenario, going to perform "close enough" in the real world in a multi-core, multi-node load balanced context?

mgdev 4y ago

Devil's advocate: What would it take to programmatically port/transpile the core of Erlang's ecosystem to Elixir? Pick the killer app to serve as the root node (Phoenix?) and walk back to the leaves (OTP, popular libraries, etc). Do a 1-time cutover of literally everything. Fork/port ERTS (incl BEAM) to make Elixir-native and rebrand it. Etc. While I generally agree that "rewriting as bad" there is something to be said about the importance of _ease_ when bootstrapping and scaling an ecosystem. You're either stealing mindshare from an established ecosystem, or you're capturing new minds as they come in. IMO Elixir/OTP is too radically different from other very-large ecosystems to benefit from transfer learning for junior/mid-level people (great similarity w/other smaller fringe ones, like Ruby, Clojure, etc, but that won't get us there), and the most senior people fall into the "it's all the same at the end of the day" trap and don't put in the energy absent some strong business driver. So you really need to reduce even the shallowest cognitive bumps to get escape velocity.

srevenant 4y ago
This is what I too have wondered. I'm curious if there are more devs in elixir or erlang. I'm also curious if it'd be easy enough to have elixir->erlang transpiling, so those wanting from elixir could pull it.
hauleth 4y ago
But what would be a point of doing that?
jolux 4y ago
I had this same thought because I think Elixir and Erlang are actually similar enough that translating between them directly may be feasible and have decent results. I don’t really think forking is a good idea though. As I understand it most BEAM maintenance is actually done by Ericsson, and I’m not sure the Elixir community has the resources to sustain a project like that. It seems like it would also create bad blood with the Erlang community and risk breaking compatibility eventually, which would be a huge loss for users of libraries like Ranch and Hackney.
- wink 4y ago
  As someone coming from erlang (but not a huge ton of experience in it) my only gripe is the difference in string/binary handling, everything else is quite smooth, totally comparable to Clojure+Java libs.

josevalim 4y ago
This is fantastic feedback. I always love reading posts like yours. Three quick notes to complement what you said: * The formatter is always a balancing act. The behaviour you see is because people get really upset when we don't respect their line breaks (and, as you correctly said, we can't later know which newlines were introduced by us). You can try formatting more frequently to get feedback sooner (that's what I do: I usually type code with no indentation whatsoever and "collaborate" with the formatter as I go). * I am thinking really hard about the struct problem and trying to find a balance between getting some of the guarantees of structs without having to hijack a whole module. * Re namespaces, agreed they are not as powerful as namespaces in other languages, because they are not actual entities. However, you shouldn't run into issues. If you do recall what it was, feel free to reach out or post something in the forum. The dot notation can be useful in aliases (which a different separator would not help). Have a good week!
- travisgriggs 4y ago
  People like José are why I like the Elixir community. So many others would have taken offense and become defensive.
  - bluehatbrit 4y ago
    To be fair to you, I think you phrased your feedback much better than many on this site do. You listed a lot of pros, gave context for where you are in your journey with the platform, admitted you don't know everything yet, and focused your constructive criticism on the language and not the contributors. I just wanted to call that out as I often see the opposite here, but I do agree that José, Chris, and co do rock and lead the community really well!
- sbrother 4y ago
  +1 to the struct thing and very interested in your thoughts! I've personally taken to using protobufs instead with the excellent https://github.com/elixir-protobuf/protobuf https://github.com/elixir-protobuf/protobuf library. They work beautifully but are obviously a lot more heavy weight. It would be nice to have more ergonomic native structs.