Ten Years of Erlang
ferd.ca
Ten Years of Erlang
1–10 of 155 posts
Re: Ten Years of Erlang
#2Re: Ten Years of Erlang
#3I wish the industry was much more Erlang friendly.
Re: Ten Years of Erlang
#4As someone who loves servers and back-end work, Erlang is amazing to me. I too read that book by Joe Armstrong, but I never really got to use Erlang for much since I don't get paid to use it. Recently I was trying out Elixir and going through the documentation and was pleasantly surprised how much of it is Erlang-like. I wish the industry was much more Erlang friendly.
It is basically erlang with better tooling and still an easy use of erlang.
Re: Ten Years of Erlang
#5Interestingly enough I started using Erlang around the same time and while I've continued to use it for the project I started then on and off, I've not had a lot of reason to use it on other projects. I don't ever think it'll be as wide spread or as popular for many of the reasons listed. I do think it will continue to be a tool used to create great projects with very few hands. In the right hands and for the right p…
https://news.ycombinator.com/item?id=20357055
Elixir is just a slightly changed Erlang syntax?
Re: Ten Years of Erlang
#6Interestingly enough I started using Erlang around the same time and while I've continued to use it for the project I started then on and off, I've not had a lot of reason to use it on other projects. I don't ever think it'll be as wide spread or as popular for many of the reasons listed. I do think it will continue to be a tool used to create great projects with very few hands. In the right hands and for the right p…
If you search HN history, it appears Elixir seems to get much more buzz. Saw this from a few days ago: https://news.ycombinator.com/item?id=20357055 Elixir is just a slightly changed Erlang syntax?
Re: Ten Years of Erlang
#7My personal take is that the next major milestone for Erlang/Elixir will be a significantly more performance BEAM. Be it JIT or reworked Hipe.
Elixir (& Phoenix) brought a ton of interest from the Ruby community. The only remaining aspect that would keep a Ruby developer using Ruby is the perf vs Erlang. Today, for many raw perf task there isn’t a meaningful difference in speed (note I’m not taking scalability). As soon as the speed difference becomes meaningful, Erlang will get another wave of people.
Re: Ten Years of Erlang
#8Interestingly enough I started using Erlang around the same time and while I've continued to use it for the project I started then on and off, I've not had a lot of reason to use it on other projects. I don't ever think it'll be as wide spread or as popular for many of the reasons listed. I do think it will continue to be a tool used to create great projects with very few hands. In the right hands and for the right p…
If you search HN history, it appears Elixir seems to get much more buzz. Saw this from a few days ago: https://news.ycombinator.com/item?id=20357055 Elixir is just a slightly changed Erlang syntax?
Re: Ten Years of Erlang
#9I have found that I like Lisp-Flavoured-Erlang (LFE) a bit more, since I still find the prolog-esque syntax a bit frustrating. I've been doing this stuff for like 6 years, and I still occasionally get tripped up on when to do a comma, semicolon, or period occasionally. While I'm not a huge fan of LISP-2 semantics, overall I find the syntax for LFE to be a lot more consistent than raw Erlang.
This isn't to crap all over regular Erlang though; Erlang was the first language I had seen that fully embraced pattern-matching, and I find that kind of pattern to be incredibly elegant.
If someone reading this hasn't tried out Erlang, do yourself a favor, download and install it, and build a simple TCP chat server. I can virtually guarantee you that it will be easier than anything you've built in C/C++, and it's incredibly satisfying to have something you built in a few hours have the ability to scale correctly.
Re: Ten Years of Erlang
#10This ladder is a great blueprint, great article:
functional programming
isolated processes and concurrency
reliable concurrency (links, monitors, timeouts)
OTP behaviours and other system abstractions
How to structure OTP systems
How to build releases and handle their life cycle
How to never take the system down, and how to operate it