Ask HN: Is Erlang an albatross to Elixir adoption?
108 comments
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
> 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
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:
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.
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
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.
This.
I was able to read Erlang before knowing the name of the language. I discovered this language by looking at the source code of RabbitMQ, and I was surprised at how I could read it, knowing nothing about the language.
At first I thought atoms were variables defined somewhere (and I did not care where it was defined, the names were explicit). When I learned that they are in fact values, it blew my mind.
It's only 6 months later I started coding in Erlang. Then 3 years ago I started writing Elixir. I did not have to learn Elixir in fact, it was just another syntax for what I already knew.
I always recommend learning Erlang first with https://learnyousomeerlang.com/ and then learning Elixir. Simply because this book does a far better job at explaining OTP than the Elixir docs.
Maybe there is some value in writing learnyousomeelixir.com?
I was able to read Erlang before knowing the name of the language. I discovered this language by looking at the source code of RabbitMQ, and I was surprised at how I could read it, knowing nothing about the language.
At first I thought atoms were variables defined somewhere (and I did not care where it was defined, the names were explicit). When I learned that they are in fact values, it blew my mind.
It's only 6 months later I started coding in Erlang. Then 3 years ago I started writing Elixir. I did not have to learn Elixir in fact, it was just another syntax for what I already knew.
I always recommend learning Erlang first with https://learnyousomeerlang.com/ and then learning Elixir. Simply because this book does a far better job at explaining OTP than the Elixir docs.
Maybe there is some value in writing learnyousomeelixir.com?
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.
Is it a bit of extra complexity? Yes.
Does it cause friction for new devs? No - I can't think of any mainstream Elixir use cases that require Erlang libraries, with the exception of math operators like `:math.sqrt/1`. Chris' comment here is the golden example of this.
And anyway, what does the user get in exchange for that extra layer of complexity? A unique high-concurrency VM with easy-to-use primitives that would require huge gobs of code and lots of added dependencies in other languages.
It's a small tradeoff. My own experience is that the benefits far outweigh the complexity cost.
It sounds like OP mostly objects to the oldschool textfile documentation aesthetic of a lot of Erlang core and libraries, which is fine, but the overwhelming majority of new Elixir devs doing web applications and data processing will never encounter this.
Does it cause friction for new devs? No - I can't think of any mainstream Elixir use cases that require Erlang libraries, with the exception of math operators like `:math.sqrt/1`. Chris' comment here is the golden example of this.
And anyway, what does the user get in exchange for that extra layer of complexity? A unique high-concurrency VM with easy-to-use primitives that would require huge gobs of code and lots of added dependencies in other languages.
It's a small tradeoff. My own experience is that the benefits far outweigh the complexity cost.
It sounds like OP mostly objects to the oldschool textfile documentation aesthetic of a lot of Erlang core and libraries, which is fine, but the overwhelming majority of new Elixir devs doing web applications and data processing will never encounter this.
> A unique high-concurrency VM with easy-to-use primitives that would require huge gobs of code and lots of added dependencies in other languages.
Truth is most web devs don't care about concurrency - it's a thing left for the ops team and with today's tools (k8s) its getting more and more trivial by the minute and it's only gonna get simpler and cheaper.
I'm not saying there aren't any use cases for Elixir, I'm just saying they're not that obvious or common.
Truth is most web devs don't care about concurrency - it's a thing left for the ops team and with today's tools (k8s) its getting more and more trivial by the minute and it's only gonna get simpler and cheaper.
I'm not saying there aren't any use cases for Elixir, I'm just saying they're not that obvious or common.
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.
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.
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.
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.
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.
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.
But what would be a point of doing that?
Phoenix seems quite bloated. Is there any way to make it work without JavaScript, or do I have to rely on it? I really wanted a web framework where I can have routers, templates, sessions, and the usual stuff and no JavaScript, only if I write it myself into the template. :(
There’s no JavaScript unless you write it into the template. If you want to use LiveView that needs JavaScript but plain old templates do not.
As for bloat I don’t really agree but I can see how it might appear that way. Phoenix is actually not monolithic, it is sort of just a set of conventions and macros (batteries) that make using Plug and Ecto and some other libraries together more cohesive and more like programming in Rails. If you don’t like that approach you can also just use Plug and Plug.Router directly, which is more of a microframework feel like Flask or Sinatra.
As for bloat I don’t really agree but I can see how it might appear that way. Phoenix is actually not monolithic, it is sort of just a set of conventions and macros (batteries) that make using Plug and Ecto and some other libraries together more cohesive and more like programming in Rails. If you don’t like that approach you can also just use Plug and Plug.Router directly, which is more of a microframework feel like Flask or Sinatra.
Got any resources for simple usages of Phoenix? Most of them are all about LiveView and a lot of stuff that uses JavaScript.
> There’s no JavaScript unless you write it into the template.
I want this. How do I achieve this? "mix phx.new" is not it, as there are JavaScript files in "assets/", for example.
> There’s no JavaScript unless you write it into the template.
I want this. How do I achieve this? "mix phx.new" is not it, as there are JavaScript files in "assets/", for example.
You pass the `--no-assets` flag when using `mix phx.new`[1]
Also ime, there's not many good blog posts or guides around Phoenix that I've seen. The sort of de facto resource would be the Programming Phoenix book. It's well worth the $25 considering the amount of effort Chris and co. seems to have put into it.
[1]https://hexdocs.pm/phoenix/Mix.Tasks.Phx.New.html
Also ime, there's not many good blog posts or guides around Phoenix that I've seen. The sort of de facto resource would be the Programming Phoenix book. It's well worth the $25 considering the amount of effort Chris and co. seems to have put into it.
[1]https://hexdocs.pm/phoenix/Mix.Tasks.Phx.New.html
Thank you! Will give it a go. :)
[deleted]
`mix phx.new foo --no-live` does that. LiveView is completely optional. Node/npm has been completely replaced by esbuild and even that is optional if you want to rip it out and handle assets another way.
Yeah, I suppose that is why I thought it required JavaScript (the book instructed me to type --live). I was following the instructions of some books and there was JavaScript such as utils.js and whatnot.
I typed what you told me, but it does have "foo/assets/vendor/topbar.js" and "foo/assets/js/app.js". Not sure what those are though or if they are a necessity. It ends up being "deps/phoenix_html/priv/static/phoenix_html.js" on localhost:4000. Any ideas as to how to COMPLETELY avoid JavaScript? Are there any sources for that perhaps?
I typed what you told me, but it does have "foo/assets/vendor/topbar.js" and "foo/assets/js/app.js". Not sure what those are though or if they are a necessity. It ends up being "deps/phoenix_html/priv/static/phoenix_html.js" on localhost:4000. Any ideas as to how to COMPLETELY avoid JavaScript? Are there any sources for that perhaps?
https://hexdocs.pm/phoenix/Mix.Tasks.Phx.New.html
I think you want the --no-assets option.
I think you want the --no-assets option.
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.
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.
> 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.
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.
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.
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.
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.
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.
I've been happily using Clojure for about 9 years and hardly ever have I needed to dip into any Java code. That's not to say I can't grok Java if I need to. Compared with the monstrosity that is Gradle deps.edn is a breath of fresh air.
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.
> 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.
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.
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).
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).
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.
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.
> 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.
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.
What concerns me is I see people talk about using NIFs like no big deal.
BUT, they come at the cost of potentially bringing down the entire Erlang runtime. People use Erlang, more times than not, because they want a fail-safe runtime ... so recommending NIFs shouldn't be taken lightly.
Just my 2 cents.
BUT, they come at the cost of potentially bringing down the entire Erlang runtime. People use Erlang, more times than not, because they want a fail-safe runtime ... so recommending NIFs shouldn't be taken lightly.
Just my 2 cents.
> People use Erlang, more times than not, because they want a fail-safe runtime
I disagree; 99% of people running Erlang runtimes are running them in use-cases where it'd be fine if any individual node crashed and got restarted.
(E.g. running a Phoenix web-app as a K8s replicated Deployment, with no durable internal state, only the mesh-replicated Phoenix.Presence data that can be recovered from peers after node restart; where, for users, even having a long-running websocket is just an optimization over long-polling, and so it's no skin off the clients' backs if said connection gets dropped once in a blue moon, requiring them to reconnect to another node in the cluster.)
I agree that you should only be using NIFs after you've exhausted the other options — "C nodes" being my favorite of those, personally.
But downplaying NIFs ignores a whole other segment of use-cases, where you're not adding native code to Erlang, but rather you're starting with a "core" of native code (e.g. an HFT trading engine), and then building an app by wrapping that native code in Erlang, where the code presents itself to Erlang as a NIF.
If efficient shared-address-space high-throughput interaction between your native "core" and your higher-level "glue" is the whole point, then Erlang+NIFs is a pretty great way to get a bunch of advantages without losing much. It's a lot better than what you get from the alternatives — where those alternatives are "loading the native core as an FFI module in some other dynamic language runtime."
I disagree; 99% of people running Erlang runtimes are running them in use-cases where it'd be fine if any individual node crashed and got restarted.
(E.g. running a Phoenix web-app as a K8s replicated Deployment, with no durable internal state, only the mesh-replicated Phoenix.Presence data that can be recovered from peers after node restart; where, for users, even having a long-running websocket is just an optimization over long-polling, and so it's no skin off the clients' backs if said connection gets dropped once in a blue moon, requiring them to reconnect to another node in the cluster.)
I agree that you should only be using NIFs after you've exhausted the other options — "C nodes" being my favorite of those, personally.
But downplaying NIFs ignores a whole other segment of use-cases, where you're not adding native code to Erlang, but rather you're starting with a "core" of native code (e.g. an HFT trading engine), and then building an app by wrapping that native code in Erlang, where the code presents itself to Erlang as a NIF.
If efficient shared-address-space high-throughput interaction between your native "core" and your higher-level "glue" is the whole point, then Erlang+NIFs is a pretty great way to get a bunch of advantages without losing much. It's a lot better than what you get from the alternatives — where those alternatives are "loading the native core as an FFI module in some other dynamic language runtime."
> 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.
Yeah I love Erlang, but often reach for something else when I need to be able to express and optimize compute bound problems.
Yeah I love Erlang, but often reach for something else when I need to be able to express and optimize compute bound problems.
In a way it makes perfect sense. When I look into my toolbox I see a whole pile of different saws, each of which has a specific usecase, metal, wood, living wood, trees, joinery, figure work, glass+ etc. The one-tool-to-fit-all-usecases programming language hasn't been invented yet as far as I can see.
+ technically, probably more of a grinder because the blade is covered with diamond dust, but you use it like a saw.
+ technically, probably more of a grinder because the blade is covered with diamond dust, but you use it like a saw.
> The one-tool-to-fit-all-usecases programming language hasn't been invented yet as far as I can see.
Well, just like you can use a screwdriver to pound a nail into the wall (flip it handle-first), you could use C or Rust or Go or Java or...nearly anything to build...nearly anything if you really _forced_ it hard enough, had infinite time, expert labor and budget, but...
...there are better tools for the job of pounding a nail into the wall than a screwdriver! ;-)
In other words, I totally agree with you. Sure, you could build, oh I dunno, say a compute-intensive application entirely in, say, Ruby, but you'd need to throw some ungodly expensive hardware at it. Makes a lot more sense to use the right tool for the job!
Well, just like you can use a screwdriver to pound a nail into the wall (flip it handle-first), you could use C or Rust or Go or Java or...nearly anything to build...nearly anything if you really _forced_ it hard enough, had infinite time, expert labor and budget, but...
...there are better tools for the job of pounding a nail into the wall than a screwdriver! ;-)
In other words, I totally agree with you. Sure, you could build, oh I dunno, say a compute-intensive application entirely in, say, Ruby, but you'd need to throw some ungodly expensive hardware at it. Makes a lot more sense to use the right tool for the job!
> 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.
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.
> 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_wJ9AbLzGNu5bZKdIV...
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_wJ9AbLzGNu5bZKdIV...
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.)
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.)
> 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.
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.
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?
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?
I am dubious it's the performance of Erlang that's the albatross, considering the performance of RabbitMQ messaging system and Process One's XMPP server ejabberd. However, at the end of the day Erlang is a VM language, so I'd think it's not going to be as fast in many cases as Rust. Performance in a distributed system is good, because of the design, but that's still not the #1 priority of Erlang. I think Erlang's #1 priority is robustness.
Then what is the albatross?
I think it is complexity. Erlang, and OTP, is not simple to understand. There are a lot of footguns. It is beautifully designed and fit for purpose, given it's history and heritage. However, the learning time for creating a real app in Erlang is high. To flip it around, I think the reason Ruby caught on so fast was that it was so easy to learn Rails and create a web app with it.
You could perhaps convert Elixir to be based on top of Rust, but there are many concepts that don't map, or don't map well.
Then what is the albatross?
I think it is complexity. Erlang, and OTP, is not simple to understand. There are a lot of footguns. It is beautifully designed and fit for purpose, given it's history and heritage. However, the learning time for creating a real app in Erlang is high. To flip it around, I think the reason Ruby caught on so fast was that it was so easy to learn Rails and create a web app with it.
You could perhaps convert Elixir to be based on top of Rust, but there are many concepts that don't map, or don't map well.
FWIW I have ported Json APIs from JS & PHP to Elixir and the Elixir ones were the fastest (on the same server). And it was before even leveraging ETS to cache DB data (which is faster than Redis by design).
> "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?
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?
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.
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.
> 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.
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.
> Erlang, on the other hand, offers me much that Elixir does not.
Genuinly curious. Like what?
Genuinly curious. Like what?
> In truth, I've never met anyone who likes Elixir except people who were already Ruby programmers.
This was the purpose of the language (or if not an explicit purpose, the primary effect.) Elixir created an environment that attracted Rails people (and other people repulsed by languages that don't look like C/Algol), and behind the Rails people (Rails been long established as a safe choice but aging and scaling badly) comes management of safe companies and consultancies, and with that comes a sure way of making a living for people who love Erlang and are willing to play the Elixir game.
Elixir is the same as Erlang, except with bad syntax and loaded with various ways to make your programs indecipherable, and with a cleaned up standard library and lots of nice little affordances/templates to help with processes and OTP. While Elixir (in my experience) takes a lot more debugging due to the weird javascripty syntax and pseudo-mutable variables, it's the same thing in my book (and the error messages are great.)
Happy to do the one that provides the most work, and thankful that they created it.
This was the purpose of the language (or if not an explicit purpose, the primary effect.) Elixir created an environment that attracted Rails people (and other people repulsed by languages that don't look like C/Algol), and behind the Rails people (Rails been long established as a safe choice but aging and scaling badly) comes management of safe companies and consultancies, and with that comes a sure way of making a living for people who love Erlang and are willing to play the Elixir game.
Elixir is the same as Erlang, except with bad syntax and loaded with various ways to make your programs indecipherable, and with a cleaned up standard library and lots of nice little affordances/templates to help with processes and OTP. While Elixir (in my experience) takes a lot more debugging due to the weird javascripty syntax and pseudo-mutable variables, it's the same thing in my book (and the error messages are great.)
Happy to do the one that provides the most work, and thankful that they created it.
It was not the purpose of the language nor I believe it is its primary effect. It was the immediate effect though.
At last ElixirConf, I remember asking for a show of hands on people's backgrounds, and I would say Ruby was 40-50%. It is impossible to know how it applies to the community as a whole, but I think the idea that Elixir is "Erlang for Ruby" is several years dated at this point.
At last ElixirConf, I remember asking for a show of hands on people's backgrounds, and I would say Ruby was 40-50%. It is impossible to know how it applies to the community as a whole, but I think the idea that Elixir is "Erlang for Ruby" is several years dated at this point.
Macros in Elixir are very nice, so you only have to implement a few functions to get a GenServer instead of the whole protocol.
Also, I'm not a Ruby developer but still found Elixir to be nicer than Erlang in small but important ways. The documentation part does hold true IMO, as the official Elixir docs are fantastic, which goes beyond just a different CSS theme.
Also, I'm not a Ruby developer but still found Elixir to be nicer than Erlang in small but important ways. The documentation part does hold true IMO, as the official Elixir docs are fantastic, which goes beyond just a different CSS theme.
Elixir was a gateway to Erlang for me. I hadn't heard of Erlang before I started writing in Elixir, but all the discussion of why Elixir was so great revolved around Erlang and the BEAM. This lead me to Joe's distributed systems thesis and really changed how I approach writing code.
The syntax takes a bit of getting used to, but I generally prefer the language. I haven't found anything that's a nice to work with for web app development in Erlang, though; I do think the tooling around Phoenix is nicely polished.
The syntax takes a bit of getting used to, but I generally prefer the language. I haven't found anything that's a nice to work with for web app development in Erlang, though; I do think the tooling around Phoenix is nicely polished.
Is this the "Joe's distributed systems thesis" you refer to? https://erlang.org/download/armstrong_thesis_2003.pdf
Edit: After reading the first bit of that I'm pretty confident that is was GP was referring to. It's a really good paper and worth reading to understand why Erlang/Elixir do many of the things they do.
Edit: After reading the first bit of that I'm pretty confident that is was GP was referring to. It's a really good paper and worth reading to understand why Erlang/Elixir do many of the things they do.
For web development for Erlang check out https://github.com/novaframework/nova
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).
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).
Reminds me of this blog post:
"The Most Object-Oriented Language" => https://blog.noredink.com/post/142689001488/the-most-object-...
"The Most Object-Oriented Language" => https://blog.noredink.com/post/142689001488/the-most-object-...
Yep :) Anybody familiar with the roots of OO will understand how wildly Java/C++ and their ilk went off the rails. It wasn't intended as a code organizational system. It's about encapsulation of needs, actors, and sending messages back and forth.
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.
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.
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.
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.
> 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?
Why do these libraries need to be ported to Elixir at all?
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.
+100 — the heart of the problem
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.
Exactly the problem I've run into on more than one occasion. And the erlang libs I'm referencing have almost zero documentation, so it really means "RTFC" which then is painful :D
This last part is really important. If you don't already know what GenServer or Application or Supervisor are/do, finding out from just the docs or internet posts is extremely hard.
did you have an aha moment that finally made it all (genservers and entry points) make sense? if so, what was it?
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/.
> 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.
> 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/.
> 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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
Lisp and Scheme on the JVM exist, too.
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.
Well to be fair Elm runs on a completely different platform, it's just the compiler is written in Haskell. "Leveraging the Haskell ecosystem" isn't part of Elm's value prop.
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.
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.
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.
> "Erlang is easy, it's just semantics that are different"
The opposite: syntax's different, similar semantics.
The opposite: syntax's different, similar semantics.
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.
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.
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.
And usually such a 'derivative' language only serves to fragment the eco system (community, contributions) of the 'root', not to enhance it.
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.
True, though I think part of this is also recognizing that the more the semantics diverge, the more potential upside there is.
Not that JavaScript-with-types isn't a compelling pitch for TypeScript— it totally is. But that's a benefit that is primarily geared toward scale and safety, whereas Clojure is a completely different kind of language from Java. Maybe I'm just arguing essentially the same point here, that Clojure is always going to be a niche, but the core of it is that if your problem domain demands using a Lisp, and you have other reasons to want to be on the JVM, then it's likely that the cost of having to pick up some Java is going to be well worth it.
Not that JavaScript-with-types isn't a compelling pitch for TypeScript— it totally is. But that's a benefit that is primarily geared toward scale and safety, whereas Clojure is a completely different kind of language from Java. Maybe I'm just arguing essentially the same point here, that Clojure is always going to be a niche, but the core of it is that if your problem domain demands using a Lisp, and you have other reasons to want to be on the JVM, then it's likely that the cost of having to pick up some Java is going to be well worth it.
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.
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.
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.
TypeScript shines with complex webapps. Having the typing prevents a whole class of issues and helps with refactoring quite a bit.
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.
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.
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.
> 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.
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.
> 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."
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."
Except nobody is asking how to do anything, so every answer is equally unproductive.
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".
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.
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.
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.
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..
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..
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
Absolutely not!
Elixir is to Erlang AS C++ is to C; you cannot understand the former without understanding the latter.
Elixir is to Erlang AS C++ is to C; you cannot understand the former without understanding the latter.
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?
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?
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!
* 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!
People like José are why I like the Elixir community. So many others would have taken offense and become defensive.
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!
+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 library. They work beautifully but are obviously a lot more heavy weight. It would be nice to have more ergonomic native structs.
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?)