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

How I Start: Erlang

howistart.org

Post reply on HN
Print view View original

21–30 of 32 posts

Re: How I Start: Erlang

#21

Post by ffreire »

MCRed wrote: post #11
arthurcolle wrote: post #5

Earlier quoted context omitted.

Just curious, what do you use Erlang for? I can think of neural networks as a possible use case but I don't hear much in the way of that.

Any time you need to do multiple things at once, erlang (or elixir) is often the best choice. EG: If you have a website and want to serve more than one request at at time. If you have multiple people chatting or sending mail, or instant messaging, or voice communicating, erlang is a good choice. If you have a search engine with many people searching, while spiders crawl the web, erlang is a good choice. The only "dow…

What would you say about Clojure, then, where one of the big selling points is concurrency?

Re: How I Start: Erlang

#22

Post by stonemetal »

ffreire wrote: post #21
MCRed wrote: post #11

Earlier quoted context omitted.

Any time you need to do multiple things at once, erlang (or elixir) is often the best choice. EG: If you have a website and want to serve more than one request at at time. If you have multiple people chatting or sending mail, or instant messaging, or voice communicating, erlang is a good choice. If you have a search engine with many people searching, while spiders crawl the web, erlang is a good choice. The only "dow…

What would you say about Clojure, then, where one of the big selling points is concurrency?

Completely different definitions of concurrency. For Clojure what ships in the box as concurrency is multi-thread, single process concurrency(aka built around shared memory). Erlang devs knew that would never scale beyond a single box so they didn't bother going after it. They built single-thread, multi-process concurrency as the core of their concurrency model(share nothing). This means by default Erlang concurrency primitives work beyond a single node, Clojure's don't.

Re: How I Start: Erlang

#23

Post by tomwilson »

Hey this is really nice. I tried to get into Erlang from reading Armstrongs book (Programming Erlang) and just couldn't grok it. I think the later chapters of that get a bit more 'concrete' and start making real things but I lost interest by that point. Reading this has made me want to try again, though.

Re: How I Start: Erlang

#24

Post by rdtsc »

stonemetal wrote: post #22
ffreire wrote: post #21

Earlier quoted context omitted.

What would you say about Clojure, then, where one of the big selling points is concurrency?

Completely different definitions of concurrency. For Clojure what ships in the box as concurrency is multi-thread, single process concurrency(aka built around shared memory). Erlang devs knew that would never scale beyond a single box so they didn't bother going after it. They built single-thread, multi-process concurrency as the core of their concurrency model(share nothing). This means by default Erlang concurrency…

> They built single-thread, multi-process concurrency as the core of their concurrency model(share nothing). This means by default Erlang concurrency primitives work beyond a single node, Clojure's don't.

Well actually Erlang is not single-threaded it is multi-scheduler and multi-process. CPU or OS based threads are used for scheduler and processes (possibly hundreds of thousands of them) run on all of them.

Moreover processes are very small memory wise (only a few K) and _most importantly_ have isolated heaps (yes, all while running in the same OS-level process.

What you are mentioning there is called "distribution". This is what allows you to send a message to another Erlang process, running on a different machine, different continent and have it look like Pid ! Msg which is exactly how you'd send a message to a local Erlang process as well.

Re: How I Start: Erlang

#25

Post by matthiasl »

rdtsc wrote: post #24
stonemetal wrote: post #22

Earlier quoted context omitted.

Completely different definitions of concurrency. For Clojure what ships in the box as concurrency is multi-thread, single process concurrency(aka built around shared memory). Erlang devs knew that would never scale beyond a single box so they didn't bother going after it. They built single-thread, multi-process concurrency as the core of their concurrency model(share nothing). This means by default Erlang concurrency…

> They built single-thread, multi-process concurrency as the core of their concurrency model(share nothing). This means by default Erlang concurrency primitives work beyond a single node, Clojure's don't. Well actually Erlang is not single-threaded it is multi-scheduler and multi-process. CPU or OS based threads are used for scheduler and processes (possibly hundreds of thousands of them) run on all of them. Moreover…

> Well actually Erlang is not single-threaded it is multi-scheduler and multi-process.

I think the parent and you are talking about separate things.

Erlang the language is single threaded. Erlang the language has no concept of threads. That's what I think the parent was referring to, since he writes "concurrency model".

The BEAM Erlang VM, on the other hand, uses multiple schedulers and multiple threads, pretty much as you describe. Most people regard that as a characteristic of the VM _implementation_, not the concurrency _model_.

Re: How I Start: Erlang

#26

Post by lmb »

rubyrescue wrote: post #19
lmb wrote: post #16

Thanks for the write up, especially the part on relx was enlightening. I've been toying with Erlang, and have three questions I have not been able to find good answers to. Maybe someone could elaborate? 1) How well does Erlang deal with multiple VMs on a single machine? Are there any upsides to using a single VM per machine? (So, run your own code along side a RabbitMQ instance for example, if that is even feasible.)…

1. I've tended to see slightly better overall performance running multiple VMs (nodes)/server. 2. We use zookeeper and cache locally with an ETS wrapper. It's not-erlang but there are a lot of nice zookeeper tools and the ezk module for erlang is very solid. 3. we typically don't do vpn as if the vpn goes down it is a disaster. dual nics are ideal. i don't always configure that way due to limitations of the environme…

Thanks for the pointers. Regarding 3), access control was probably not what I was thinking about. More like, how do I use distributed Erlang without allowing everybody access to the node (even without knowing the cookie) and how do I prevent a MITM to snoop on my Erlang traffic. [1] seems to have some decent info on in, I should have researched some more.

[1] http://stackoverflow.com/questions/890938/howto-encrypt-erla...

Re: How I Start: Erlang

#27

Post by jlouis »

rubyrescue wrote: post #19
lmb wrote: post #16

Thanks for the write up, especially the part on relx was enlightening. I've been toying with Erlang, and have three questions I have not been able to find good answers to. Maybe someone could elaborate? 1) How well does Erlang deal with multiple VMs on a single machine? Are there any upsides to using a single VM per machine? (So, run your own code along side a RabbitMQ instance for example, if that is even feasible.)…

1. I've tended to see slightly better overall performance running multiple VMs (nodes)/server. 2. We use zookeeper and cache locally with an ETS wrapper. It's not-erlang but there are a lot of nice zookeeper tools and the ezk module for erlang is very solid. 3. we typically don't do vpn as if the vpn goes down it is a disaster. dual nics are ideal. i don't always configure that way due to limitations of the environme…

As for 1. do test! This is not always the case.

Re: How I Start: Erlang

#28

Post by rdtsc »

matthiasl wrote: post #25
rdtsc wrote: post #24

Earlier quoted context omitted.

> They built single-thread, multi-process concurrency as the core of their concurrency model(share nothing). This means by default Erlang concurrency primitives work beyond a single node, Clojure's don't. Well actually Erlang is not single-threaded it is multi-scheduler and multi-process. CPU or OS based threads are used for scheduler and processes (possibly hundreds of thousands of them) run on all of them. Moreover…

> Well actually Erlang is not single-threaded it is multi-scheduler and multi-process. I think the parent and you are talking about separate things. Erlang the language is single threaded. Erlang the language has no concept of threads. That's what I think the parent was referring to, since he writes "concurrency model". The BEAM Erlang VM, on the other hand, uses multiple schedulers and multiple threads, pretty much…

> Erlang the language is single threaded.

How so? Isn't it closer to multi-threaded with threads having isolated heaps? Can execute lots of spawn(...) statement and now there are multiple threads of execution running.

Re: How I Start: Erlang

#29

Post by MCRed »

arms wrote: post #12
MCRed wrote: post #11

Earlier quoted context omitted.

Any time you need to do multiple things at once, erlang (or elixir) is often the best choice. EG: If you have a website and want to serve more than one request at at time. If you have multiple people chatting or sending mail, or instant messaging, or voice communicating, erlang is a good choice. If you have a search engine with many people searching, while spiders crawl the web, erlang is a good choice. The only "dow…

I'm curious why you think Golang doesn't support concurrency properly.

I know go is not concurrent. It doesn't even try.

Re: How I Start: Erlang

#30

Post by MCRed »

ffreire wrote: post #21
MCRed wrote: post #11

Earlier quoted context omitted.

Any time you need to do multiple things at once, erlang (or elixir) is often the best choice. EG: If you have a website and want to serve more than one request at at time. If you have multiple people chatting or sending mail, or instant messaging, or voice communicating, erlang is a good choice. If you have a search engine with many people searching, while spiders crawl the web, erlang is a good choice. The only "dow…

What would you say about Clojure, then, where one of the big selling points is concurrency?

The JVM is not concurrent. You can't be concurrent on a VM that doesn't support concurrency.

People selling clojure as concurrent are the blind leading the blind.

Post reply on HN