Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Elixir (2014)

theerlangelist.com

Post reply on HN
Print view View original

11–20 of 59 posts

Re: Why Elixir (2014)

#11

Post by tony612 »

tmbsundar wrote: post #9

> Elixir macros are nothing like C/C++ macros. Instead of working on strings, they are something like compile-time Elixir functions that are called in the middle of parsing, and work on the abstract syntax tree (AST), which is a code represented as Elixir data structure. Macro can work on AST, and spit out some alternative AST that represents the generated code. The description above from the article seems like close…

Yeah, it's like Lisp macros. Actually, Elixir code is AST+sugar as https://hexdocs.pm/elixir/syntax-reference.html shows.

Re: Why Elixir (2014)

#13

Post by pjmlp »

jmcgough wrote: post #7
pjmlp wrote: post #5

Earlier quoted context omitted.

Somehow I get the feeling Elixir is the new Ruby, every time I go through such presentations. Basically it looks like the escape route for Ruby developers that care about performance.

Elixir really isn't just Ruby with better performance. The two look syntactically similar (and have some similar tooling, from rubyists who've moved over to elixir), but that's about where their similarities end. Ruby really isn't designed for building complex concurrent systems. Erlang/OTP is designed specifically for that. When I need to build something that recovers from failures in Rails, it means code that is li…

As someone working across JVM, .NET, C++, Android and iOS, I don't have any use case for Elixir.

If I ever would need BEAM, Erlang would be quite ok, given that I was quite comfortable with Prolog in the past and do like the syntax.

Hence why I kind of see it as BEAM for Ruby developers, even if I am way off what is actually happening on the BEAM world.

Re: Why Elixir (2014)

#14

Post by anko »

plainOldText wrote: post #10
anko wrote: post #8

I really am in awe of Elixir. I think it's an amazing language, and it introduced me to Erlang and OTP. I've come from using scala actors, and I can do more in way less time, less memory, and similar performance if I use Elixir. That said, there are some things that suck so hard about it. The log messages suck. If I want to use them in production and actually ship them to ELK or similar, the format really sucks. Gett…

I know it's probably not the answer you're looking for, but you can learn a lot by just reading the code of popular Elixir libraries, such as Ecto, Phoenix, etc. Error messages have gotten better in Elixir 1.5 The whole ecosystem is actually getting better with each release. For shipping to production I use 'distillery'. You create a 'release' and you can even instruct it to read some arguments from the env vars. But…

I appreciate the response, at any rate.

I will read more libraries; hopefully I can find some which use flow.

I have used distillery but I find myself going down a pretty big rabbit hole just to release something which in most languages is pretty simple. I will look at it again.

Re: Why Elixir (2014)

#15

Post by Stratoscope »

pjmlp wrote: post #5
MartinMond wrote: post #2

Very relevant to this: How to sell Elixir - a talk from today's ElixirLondon https://speakerdeck.com/evadne/how-to-sell-elixir

Somehow I get the feeling Elixir is the new Ruby, every time I go through such presentations. Basically it looks like the escape route for Ruby developers that care about performance.

Back in the days of OnLive, there were several Ruby developers on the team. When Matz was in town, he stopped by to give us an informal talk and question and answer session.

I asked him, "One thing I like to do as a programmer is learn a new language every year or so, especially a language that teaches me something new about programming. Ruby was very good for this, of course, along with some of the other languages I've learned. Is there a language you've tried out lately that gives you that feeling of learning a new way to program?"

Matz said, "Elixir". He explained why; I don't remember the details but it stuck in my mind as a language to check out.

BTW, if you've ever seen the acronym MINSWAN, or "Matz Is Nice So We Are Nice", it's really true! A very nice guy.

https://www.flickr.com/photos/geary/10218307085/in/photostre...

Re: Why Elixir (2014)

#16

Post by salimmadjd »

I started learning Erlang a few months ago and after spending a week with the online class at Future Learn [0] I can understand why some people say Erlang is more readable than Elixir.

I know if you're coming form Ruby world, Erlang almost feels second nature. However, for people coming from other languages, I recommend looking into Erlang as well. It's more expressive, IMHO.

[0] https://www.futurelearn.com/courses

Re: Why Elixir (2014)

#17

Post by Southy »

pjmlp wrote: post #13
jmcgough wrote: post #7

Earlier quoted context omitted.

Elixir really isn't just Ruby with better performance. The two look syntactically similar (and have some similar tooling, from rubyists who've moved over to elixir), but that's about where their similarities end. Ruby really isn't designed for building complex concurrent systems. Erlang/OTP is designed specifically for that. When I need to build something that recovers from failures in Rails, it means code that is li…

As someone working across JVM, .NET, C++, Android and iOS, I don't have any use case for Elixir. If I ever would need BEAM, Erlang would be quite ok, given that I was quite comfortable with Prolog in the past and do like the syntax. Hence why I kind of see it as BEAM for Ruby developers, even if I am way off what is actually happening on the BEAM world.

100% This.

The use cases for OTP are actually quite narrow, despite what Erlang/Elixir evangelists tell you.

Discord is a fantastic use for OTP. Writing a CRUD app with a couple of reactive/interactive pages for comments on videos and few thousand users, OTP is overkill.

If you have an app that needs the scale and safety of OTP, then which language you pick makes no difference.

Phoenix is a really cool project, written by great developers and the community is probably the nicest and most helpful you will ever meet. But how many companies/projects need the performance and redundancy of Phoenix/OTP in their web application at the cost of not being able to hire developers?

Re: Why Elixir (2014)

#18

Post by hesarenu »

Southy wrote: post #17
pjmlp wrote: post #13

Earlier quoted context omitted.

As someone working across JVM, .NET, C++, Android and iOS, I don't have any use case for Elixir. If I ever would need BEAM, Erlang would be quite ok, given that I was quite comfortable with Prolog in the past and do like the syntax. Hence why I kind of see it as BEAM for Ruby developers, even if I am way off what is actually happening on the BEAM world.

100% This. The use cases for OTP are actually quite narrow, despite what Erlang/Elixir evangelists tell you. Discord is a fantastic use for OTP. Writing a CRUD app with a couple of reactive/interactive pages for comments on videos and few thousand users, OTP is overkill. If you have an app that needs the scale and safety of OTP, then which language you pick makes no difference. Phoenix is a really cool project, writt…

Elixir is very easy to learn. I suppose at the end of day you would be spending more time designing your architecture rather then language.

Re: Why Elixir (2014)

#19

Post by andruby »

anko wrote: post #14
plainOldText wrote: post #10

Earlier quoted context omitted.

I know it's probably not the answer you're looking for, but you can learn a lot by just reading the code of popular Elixir libraries, such as Ecto, Phoenix, etc. Error messages have gotten better in Elixir 1.5 The whole ecosystem is actually getting better with each release. For shipping to production I use 'distillery'. You create a 'release' and you can even instruct it to read some arguments from the env vars. But…

I appreciate the response, at any rate. I will read more libraries; hopefully I can find some which use flow. I have used distillery but I find myself going down a pretty big rabbit hole just to release something which in most languages is pretty simple. I will look at it again.

If it's any help: I use docker multistage to build a barebones alpine docker image. It uses distillery.

I based my dockerfile on https://gist.github.com/bsedat/16cb74ebc8ab0ed61ac598a129b0a...

Blogpost: https://zorbash.com/post/docker-multi-stage-elixir-distiller... (I'm not the author)

Re: Why Elixir (2014)

#20

Post by Southy »

hesarenu wrote: post #18
Southy wrote: post #17

Earlier quoted context omitted.

100% This. The use cases for OTP are actually quite narrow, despite what Erlang/Elixir evangelists tell you. Discord is a fantastic use for OTP. Writing a CRUD app with a couple of reactive/interactive pages for comments on videos and few thousand users, OTP is overkill. If you have an app that needs the scale and safety of OTP, then which language you pick makes no difference. Phoenix is a really cool project, writt…

Elixir is very easy to learn. I suppose at the end of day you would be spending more time designing your architecture rather then language.

I disagree that Elixir is easy to learn, the syntax ok, it's weird compared to most OO languages, but actually using OTP is a real paradigm shift that requires a totally different way of thinking about issues. I did not find that easy at all.

The other issue is that Elixir and Phoenix have become joined at the hip in the same was as Ruby and Rails, and Phoenix didn't click with me at all, coming from the JVM world I really didn't get on with it.

After reading Programming Elixir, Elixir in Action and Programming Phoenix I decided that it wasn't an easy way to make web applications that don't need OTP, and in fact I couldn't imagine a scenario where any web application I would ever write would need OTP (for the whole thing anyway, I can imagine cases where small parts of a larger system could benefit massively from fail fast architecture)

Edit: I would also argue that designing an OTP based system architecture is harder than just writing a non distributed system and then adding in load balancing or fail over.

Post reply on HN