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.
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?
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.
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.
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'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.
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.
> 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.
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.
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 think you want the --no-assets option.
> 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