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

31–40 of 62 posts

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

#31

Post by davidw »

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 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.

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

#32

Post by corysama »

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 know about your personal situation. Just throwing out a relevant observation.

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

#33

Post by sillypog »

vikingcaffiene wrote: post #14
aecorredor wrote: post #2

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

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…

You mention setting up a Phoenix app in Docker so I'll link to a couple of posts I wrote describing how I do that: https://dev.bleacherreport.com/starting-a-phoenix-project-wi..., https://dev.bleacherreport.com/brunch-in-a-container-phoenix.... I almost always start new Elixir projects in Docker for local development now, and deploy the images to Elastic Beanstalk. If you're not setting up a cluster it's not a bad option.

At Bleacher Report, we've definitely reduced operating costs on some of our services by switching to Elixir and running on fewer/smaller machines, and we routinely pick Elixir for new services now. But we also recently launched a Node service which could handle all frontend traffic on a single server, so in some ways it's hard to say whether the gains are more due to the technology or improvements in the service design.

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

#34

Post by akeating »

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.

It's useful to think of the work of m Elixir processes being distributed to n cpu cores by the BEAM scheduler. An Elixir process is not a system process in the way we usually think of the word process if coming from a non-BEAM world.

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

#35

Post by udfalkso »

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've been working full time on a rails app for the last 2+ years.

About 3 weeks ago I dove into Elixir for a big rewrite of a side project as a learning exercise. In the beginning it feels strange, mostly because of the functional way of thinking required and some new types to get used to (structs, keyword lists, etc.). Once you get the hang of it however it feels really, really nice. I dread going back to my rails app now... Others in the thread have stated most of the reasons why so I won't go into that.

I'm looking forward to launching this re-written side project in a few weeks and seeing what the performance is like. (This is currently a stale Django app). Running locally in dev mode the performance (Phoenix) seems like it will be excellent.

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

#36

Post by gamache »

raarts wrote: post #30

Can the Ruby people please stop blogging about Elixir and explain things relative to Ruby? There are way too many 'Elixir-for-Ruby-programmers' tutorials on the net already. Elixir is pretty great and enthusiasm is good but I feel this leaves a large group of people in the dark.

If you think there are too many Elixir-for-Rubyists tutorials around, wait until you look for Ruby-for-Rubyists blogs.

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

#38

Post by perishabledave »

brightball wrote: post #25
aecorredor wrote: post #2

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

There's a lot of replies to you here but I'm going to touch on the big one. Node.js's biggest concurrency perk is non-blocking I/O thanks to a cooperative scheduler. When I/O is about to happen, the scheduler relinquishes control. Elixir has non-blocking everything. Each process is prescheduled making it impossible for a runaway method to completely takeover the process. The a comparative example server with millions…

This and the actor model for concurrency goes hand in hand. Not only do you have an pleasant way for writing concurrent software, but you have a foundation (BEAM and OTP) that is built for the concurrency model.

From what I've seen, people investigate Elixir for the functional programming but stay for the concurrency.

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

#39

Post by gamache »

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 easy.

It was helpful that I wrote a bunch of Scala from 2013-2015, so I was familiar with working in an immutable FP style -- that made it a gentler transition for sure.

What have you found hard to read about it? The community is still settling on what code style "should" look like, so maybe you saw some funky Elixir, or maybe it's something deeper.

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

#40

Post by sotojuan »

raarts wrote: post #30

Can the Ruby people please stop blogging about Elixir and explain things relative to Ruby? There are way too many 'Elixir-for-Ruby-programmers' tutorials on the net already. Elixir is pretty great and enthusiasm is good but I feel this leaves a large group of people in the dark.

The last thing I want Elixir to be is shoehorned into the web app space and community of Ruby, but it seems inevitable. Oh well.
Post reply on HN