Elixir concepts for Go developers | Hacker News Reader

Elixir concepts for Go developers

texlution.com

72 pointsjaxondu16 comments

Something this article misses a bit (which is fair, because it's about the language) is that the Elixir community has already put together a very impressive amount of tooling for such a young language. For package management, hex seems mature and well-designed, and I've found their task / compilation management tool, mix, to be a dream to work with. José Valim spent a lot of time talking about the entire ecosystem in his recent keynote at ElixirConf 2015[0].

[0]: https://www.youtube.com/watch?v=9RB1JCKe3GY

Looking forward to the forthcoming "NextTrendyNewLang concepts for Elixir developers" article.

In all seriousness, if you want to learn Elixir, learn Erlang.

People kept saying the same kind of things when I started using Ruby (2004) then Rails (2005/2006) rather than C#/Java which I had been using previously for a living. I'm glad I didn't listen to them at that time, since I've been earning most of my income due to this "gut choice" for the last 10 years.

I looked at Erlang a while back but passed (didn't "click" for me), yet I'm now learning Elixir (which totally "clicks") to complement Ruby in polyglot apps.

I can safely state that I'll very soon use Elixir in production (ETL first, then web/API).

A very useful skill to have if you do consulting on the long run (like I do) is being able to evaluate what to invest in and what to pass on. My own evaluation is that Elixir is going to work very, very well on the long run.

Just another opinion :-)

I looked at Erlang a while back but passed (didn't "click" for me), yet I'm now learning Elixir (which totally "clicks") to complement Ruby in polyglot apps.

Sounds like you didn't really invest much time in the former, or that post-hoc experience made it easier for you to understand, but you instead flocked over to Elixir.

I spent roughly the same time evaluating Erlang and Elixir, fwiw, but didn't do it at the same time (hence not at the same level of experience, either).

I certainly consider that Elixir will lead me to love Erlang, but with a reduced initial friction (like CoffeeScript did for me with JavaScript, which I'm now confortable with).

The only real way to learn Erlang is to spend 3 months reading the documentation from start to finish multiple times (not each API doc, just the guides), failing to figure out why your program won't compile, fixing that missing comma or extra semicolon, screaming, then finally, one day, it will all click. Along the way, you'll also learn by experience why to never implement your own "process" but always use gen_servers (hint: multiple code reloads blow processes away).

There is no easy path to Erlang. When you learn a new programming language, what you are doing is creating an implementation of that programming language in your brain (including a tokenizer, parser, and interpreter).

The reason people go EWWW at Erlang is they don't want to struggle to implement a new tokenizer and parser in their brains. They just want to learn one tokenizer and syntax forever then pretend that's all they ever need, all while basking in the superiority of their ignorance.

You've hit on a great point here: learning a programming language requires you to be able to interpret it in your head if you want to be really productive on it. I think that that bears repeating.

In all seriousness, if you want to learn Elixir, learn Erlang.

Couldn't we have said the same thing about Objective-C with regard to C? I'm not trying to be confrontational, just trying to understand why anyone would say that one should learn the foundation instead of the abstraction? It would be nice to have some concrete reasons delineated or even referenced. I have been searching to find them because I've more than once come across the above criticism, but I've never been able to find anything besides gut reactions. If there are any real obstacles the smarter among you perceive then I'd like to know to avoid them.

> Couldn't we have said the same thing about Objective-C with regard to C?

You do, in fact, have to learn enough C before you can learn Objective-C though. The smalltalk part of the language is completely bolted on top of C and you work with C APIs all the time in Cocoa development (even when you use Swift).

why anyone would say that one should learn the foundation instead of the abstraction?

Again just one data point (not trying to generalize!), but since I started programming (circa 1985), this has always been a common confrontation point in the various (diverse) communities I've been part of.

In the demo-making world for instance, some people considered that Assembler was the only way to implement something "properly" ("real programmers use asm"), vs people picking C, C++ or even TurboPascal which could still optimize a given loop with Assembler when needed only.

It happens that some (but not all!) programmers with a long experience (15y+) end up considering that without knowing exactly how things work underneath in detail, you won't be able to ship anything.

I think it's a mixture of "fear to be obsolete" and other psychological factors. Despite this I've personally seen a couple of people with 1 to 2y of programming experience ship viable products.

Not everybody needs to know Ralf Brown's interrupt list by heart today :-)

> if you want to learn Elixir, learn Erlang.

After spending a few months with Elixir (at least in my case), you pretty much DO know Erlang. You just don't prefer to work in it. ;) I mean, the easy interop is right there, the semantics are (especially with OTP) nearly identical, you often call into Erlang, the data structures are almost the same, but you just get a heck of a lot more out of the box, even simple design decisions like "the first argument to a function is always the main thing being acted upon" have tremendous repercussions such as enabling the lovely |> transformation operator (from F# and OCaml). You get a more sane treatment of strings, you get "true" macros, you get great tooling (while still being able to take advantage of FABULOUS Erlang tooling like :observer.start() )...

Elixir complements Erlang quite nicely IMHO. And if my best guess is correct, Elixir will take Erlang into more places than it can currently imagine...

Personal anecdote: I have worked in about many C-family languages such as C, C++, Java, JS, Scala and others. I had looked at Erlang a few times but felt that the syntax was not very approachable. However, I found Elixir to be extremely approachable even though I have no experience with Ruby/Python.

Now that I have some exposure to Elixir and various FP concepts as implemented in Erlang/BEAM I can grok Erlang code without much effort even though I have no formally read its syntax.

So, long story short: Everyone is different, if you're interested in Erlang/BEAM it doesn't matter whether you start with Elixir or Erlang.

> In all seriousness, if you want to learn Elixir, learn Erlang.

Or learn both! They're both great languages.

I'm also looking forward to that NextTrendyNewLang article, because that language (which, by definition I don't know anything about yet) will likely have some techniques and ideas that build upon or recombine the existing status quo in interesting ways, just like Elixir has done.

Are those of us who enjoy reading, thinking, and learning about new languages burdening you in some way?

> in proper functional languages data is immutable. Once you have set a variable you can not change it.

Immutability != single assignment. Two separate concepts, often confused. Elixir is immutable but allows variable shadowing, in which a new variable with the same name is created and the old variable is tossed.

Although I have nothing against Erlang, I regularly see claims such as "Erlang is powering around 50% of telecom networks.", also stated in this article. Is this correct, though? Or was this the case only many years ago?

Not sure where 50% is pulled from, however, Erlang is currently used in some of Ericsson's flagship telco. products (along with other programming languges). About 50% of Ericsson SGSN-MME is written in Erlang (control plane), the rest being C++. Also Erlang is extensively used by the Ericsson RAN products (RBS 6000 family). This is for GSM, WCDMA, and LTE. People sometimes bring into discussion the AXE (AXD301) and how this was the only Ericsson product that used Erlang (I have seen "stillbirth" associated with Erlang due to this), however, this is not true and Ericsson still use Erlang today in a lot of products, both in production and for testing purposes. I believe the main distinction was that AXE was (almost) entirely programmed with Erlang as opposed to the products above which use Erlang for what it shines at and other languages for drivers, etc.

All the information above is public information that I have collected from various sources around the web. First source that comes to mind is this: https://www.youtube.com/watch?v=HyiSYHfESX4

Reply on news.ycombinator.com