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

Learn Elixir with a Rubyist (IV) – Types, Data Structures and Pattern Matching

joaomdmoura.com

Post reply on HN
Print view View original

51–60 of 62 posts

Re: Learn Elixir with a Rubyist (IV) – Types, Data Structures and Pattern Matching

#51

Post by innocentoldguy »

thibaut_barrere wrote: post #18
vikingcaffiene wrote: post #14

Earlier quoted context omitted.

I'm currently working in both. If we are just talking about them in terms of their respective merits, Elixir is my preference. It has a wonderful compiler, pipes allow for composable chains of logic, the Phoenix framework is wonderful for web development. Literally every interaction with it I've had has made me think "wow that's just a great example of excellent programming taste...". In terms of scaleablilty, I've h…

I'm working on both too, and one point that I faced was the Node 1.5GB RAM limit per node process (at least on Heroku https://devcenter.heroku.com/articles/node-concurrency - I know it can be worked around though, although not on Heroku), which can force you to run multiple processes (aka clustering) depending on your use cases (e.g. thousands of client websockets connections from the process, if you need to listen t…

I would disagree with the notion that Elixir's ecosystem isn't as rich as Node's for two reasons:

1. Node has a lot of packages to be sure, but a lot of them are redundant, and a lot of them are packages that overcome some weakness in the Javascript standard library. Elixir doesn't have as many duplicates in its ecosystem, and its standard library is robust enough that you don't have to search for packaged one-liners to overcome some missing feature that should come standard with the language.

2. Node has access to Erlang's standard library and packages. It is also trivial to include external Erlang code and libraries in an Elixir application.

Re: Learn Elixir with a Rubyist (IV) – Types, Data Structures and Pattern Matching

#52

Post by innocentoldguy »

rdtsc wrote: post #16
aecorredor wrote: post #2

If you had to make a comparison, what would be the pros and cons of using elixir vs node.js?

Elixir (well I use Erlang but it is close enough). * I like the concurrency model better. Lightweight processes vs callbacks and futures. I find processes as concurrency units maps better to problems I had to solve. So there is less impedance mismatch. That makes a huge deal in a larger project. (eg.: a user request as an isolated process vs a chain of callbacks). OS design got this right years ago -- think how most…

I think it is important to note that processes are not only isolated at a high level, but also use private memory deep within the BEAM VM; unlike the JVM, for instance, which uses shared memory.

Re: Learn Elixir with a Rubyist (IV) – Types, Data Structures and Pattern Matching

#53

Post by didibus »

corysama wrote: post #32
rebelidealist wrote: post #28

As a Ruby programmer trying to take a look at Elxir, i still find it hard to read. Maybe functional languages take time to get used to but it doesn't seem as "clear" as procedure or oop style. I know the added benefit of speed and concurrency, but for most apps we build it is not needed for now. Do any Ruby programmer find Elxir easier to write or read? Im genuinely curious to hear about this because a lot of Ruby de…

When comparing programming languages, it is extremely common for people to mistake familiarity for other things like "clarity" and "simplicity". When looking at code with unfamiliar conventions, they often proclaim tremendously simple, clear code to be "complicated" because it is not what they are accustomed to --even when an equivalent implementation in their fav language would be much more obtuse. I don't claim to…

Ya, in that point, everyone should watch the Simple Made Easy talk by Rich Hickey, creator of Clojure. One of the best talk ever in my opinion.

Re: Learn Elixir with a Rubyist (IV) – Types, Data Structures and Pattern Matching

#54

Post by thibaut_barrere »

bhelx wrote: post #26
thibaut_barrere wrote: post #18

Earlier quoted context omitted.

I'm working on both too, and one point that I faced was the Node 1.5GB RAM limit per node process (at least on Heroku https://devcenter.heroku.com/articles/node-concurrency - I know it can be worked around though, although not on Heroku), which can force you to run multiple processes (aka clustering) depending on your use cases (e.g. thousands of client websockets connections from the process, if you need to listen t…

Good points! > where a single Elixir process will be able to use more RAM & all the cores, too. I think you mean a "single instance of the BEAM" here as a single Elixir process is pegged to 1 CPU core.

Sorry for the confusion ; by Elixir process I meant a "unix Elixir process" (aka one command you run), not the lightweight Elixir "Process". The unix Elixir process uses multiple CPUs.

Re: Learn Elixir with a Rubyist (IV) – Types, Data Structures and Pattern Matching

#55

Post by thibaut_barrere »

innocentoldguy wrote: post #51
thibaut_barrere wrote: post #18

Earlier quoted context omitted.

I'm working on both too, and one point that I faced was the Node 1.5GB RAM limit per node process (at least on Heroku https://devcenter.heroku.com/articles/node-concurrency - I know it can be worked around though, although not on Heroku), which can force you to run multiple processes (aka clustering) depending on your use cases (e.g. thousands of client websockets connections from the process, if you need to listen t…

I would disagree with the notion that Elixir's ecosystem isn't as rich as Node's for two reasons: 1. Node has a lot of packages to be sure, but a lot of them are redundant, and a lot of them are packages that overcome some weakness in the Javascript standard library. Elixir doesn't have as many duplicates in its ecosystem, and its standard library is robust enough that you don't have to search for packaged one-liners…

I definitely agree with 1/, yet I was more referring to more advanced functionalities (but I do agree that the "foundations" of Elixir are very strong and I think it will ultimately be a large factor of its success).

2/ Did you mean "Elixir has access to Erlang ..." rather than "Node...", I assume?

I'm well aware of that (I also use Java libraries quite a lot with JRuby etc, similarly), yet having worked with Erlang developers (in polyglot apps), I still personally find that there is more choice for me in both Node & Rubygems, compared to raw Erlang, at least for the topics we had to cover.

Well - I guess it depends on what your actual needs are, YMMV!

Re: Learn Elixir with a Rubyist (IV) – Types, Data Structures and Pattern Matching

#56

Post by jablan »

gamache wrote: post #39
rebelidealist wrote: post #28

As a Ruby programmer trying to take a look at Elxir, i still find it hard to read. Maybe functional languages take time to get used to but it doesn't seem as "clear" as procedure or oop style. I know the added benefit of speed and concurrency, but for most apps we build it is not needed for now. Do any Ruby programmer find Elxir easier to write or read? Im genuinely curious to hear about this because a lot of Ruby de…

I slung Ruby 2008-2015, and started using Elixir heavily in late 2015. Aside from simple scripts that typically involve shelling out to Unix utilities, I find Elixir easier to write in just about all cases at this point. The syntax is even more consistent than Ruby's (to the point that it's homoiconic) and the language docs rule. Once you get a few concepts like pattern-matching and pipelines under your belt, it gets…

> What have you found hard to read about it?

Not the OP, but: keeping state: Agents, GenServers etc. FP/immutable approach does offer some great advantages, but also makes some otherwise trivial stuff (say, something akin to setting an ivar in Ruby) convoluted and tough to read.

Re: Learn Elixir with a Rubyist (IV) – Types, Data Structures and Pattern Matching

#57

Post by gamache »

jablan wrote: post #56
gamache wrote: post #39

Earlier quoted context omitted.

I slung Ruby 2008-2015, and started using Elixir heavily in late 2015. Aside from simple scripts that typically involve shelling out to Unix utilities, I find Elixir easier to write in just about all cases at this point. The syntax is even more consistent than Ruby's (to the point that it's homoiconic) and the language docs rule. Once you get a few concepts like pattern-matching and pipelines under your belt, it gets…

> What have you found hard to read about it? Not the OP, but: keeping state: Agents, GenServers etc. FP/immutable approach does offer some great advantages, but also makes some otherwise trivial stuff (say, something akin to setting an ivar in Ruby) convoluted and tough to read.

Elixir does make you think hard about the global state you keep. It's an "eat your vegetables" decision, and I've acquired the taste. Keeps me out of trouble when designing things. Contrast this to Ruby, where class variables and globals are all over the place and thread safety is a pipe dream. [EDIT: it's not that Ruby-the-language forces this worldview, but Ruby-the-community adopted it and most Gems show the effects of that.]

As far as ivars, you'll have to work hard to emulate that. There are no classes or instances. Probably you want to just use a map or a struct to represent an instance and its state.

Re: Learn Elixir with a Rubyist (IV) – Types, Data Structures and Pattern Matching

#58

Post by rdtsc »

innocentoldguy wrote: post #52
rdtsc wrote: post #16

Earlier quoted context omitted.

Elixir (well I use Erlang but it is close enough). * I like the concurrency model better. Lightweight processes vs callbacks and futures. I find processes as concurrency units maps better to problems I had to solve. So there is less impedance mismatch. That makes a huge deal in a larger project. (eg.: a user request as an isolated process vs a chain of callbacks). OS design got this right years ago -- think how most…

I think it is important to note that processes are not only isolated at a high level, but also use private memory deep within the BEAM VM; unlike the JVM, for instance, which uses shared memory.

Good point. That is why the analogy with the OS processes. They really are the best of both world -- they are lightweight and also have isolated heaps.

Re: Learn Elixir with a Rubyist (IV) – Types, Data Structures and Pattern Matching

#59

Post by true_religion »

bsuh wrote: post #43
davidw wrote: post #31

Earlier quoted context omitted.

I find Erlang itself to be pretty easy to read and write, if a bit repetitive/verbose at times. There are not very many 'magical' things happening; it's all pretty clearly spelled out. Elixir is mostly an improvement on Erlang unless people are getting crazy with the macros.

While learning Elixir and Phoenix, I found Cowboy source code easier to read with no knowledge of Erlang other than what's inferred from learning Elixir than Phoenix's generated app scaffolding. In Erlang, I look at 'module_name:function_name' I can simply open the module file and look at the function definition. In Elixir, I had to ask "Was this function aliased?", "Is it imported from a module? Which module?", "Was…

Phoenix tends to do .... interesting things with macros. It's not your typical Elixir application.

I find my IDE to be helpful in this situation, since all macros are compile time and thus can be unwrapped by the IDE.

Re: Learn Elixir with a Rubyist (IV) – Types, Data Structures and Pattern Matching

#60

Post by bsuh »

true_religion wrote: post #59
bsuh wrote: post #43

Earlier quoted context omitted.

While learning Elixir and Phoenix, I found Cowboy source code easier to read with no knowledge of Erlang other than what's inferred from learning Elixir than Phoenix's generated app scaffolding. In Erlang, I look at 'module_name:function_name' I can simply open the module file and look at the function definition. In Elixir, I had to ask "Was this function aliased?", "Is it imported from a module? Which module?", "Was…

Phoenix tends to do .... interesting things with macros. It's not your typical Elixir application. I find my IDE to be helpful in this situation, since all macros are compile time and thus can be unwrapped by the IDE.

What IDE do you use for Elixir? Thanks.
Post reply on HN