i like it. i was thinking about the same thing just last week... http://news.ycombinator.com/item?id=2501387 - let me know if you want a collaborator...
Tell HN: I'm writing an Erlang recipes book, are you interested?
21–30 of 42 posts
Re: Tell HN: I'm writing an Erlang recipes book, are you interested?
#22Erlang recipes, not that much. Make that Erlang/OTP recipes with a strong emphasis on the OTP side of it, and a million times yes ! Or to say it slightly differently : I'm not that much interested in recipes about the Erlang language itself, but I'm very very interested in recipes/examples of architectures of actual Erlang/OTP softwares. I'm doing mostly Python these days, but I worked on a couple of side projects in…
I guess I wasn't clear enough. It will be very much skewed towards OTP, and not about the language as there are already good books on the language itself.
Re: Tell HN: I'm writing an Erlang recipes book, are you interested?
#23Very needed book. In particular I am interested in limiting message queues in Erlang. I still don't get it - How one should deal with situations where messages are produced constantly in higher rate than consumed.. There is no protection in Erlang for this common scenario (I think)
You have to make the producer synchronous to the consumer so the consumer is slowed down. Ask for an acknowledgement on reception of any task/event. This will instantly limit the rate at which data can come in the final worker.
Re: Tell HN: I'm writing an Erlang recipes book, are you interested?
#24Yes! Especially if you can cover mutual supervision - that sort of arrangement seems to get glossed over in the "tree of supervisors" world.
I'm intrigued by the idea of mutual supervision. This implies that both process dynamically become the supervisor of each other. By default, OTP supervisors are more architectural in nature -- they will always give you a top-down tree rather than a cyclic graph.
Who restarts who? That's a bit tougher to do when everything becomes cyclic.
Links are bidirectional though, so when one of the workers die, the other can know about it, die, propagate the error or react to it. Monitors are unidirectional and won't propagate the errors, but only report it. I guess you could write your own mutual supervision that way, but it would be a bit weird, still.
Re: Tell HN: I'm writing an Erlang recipes book, are you interested?
#25For reference I tried to put a range of $ into your form (30 - 50), and it gave me an unfriendly error and cleared all of the fields.
You might throw some client-side validation on those fields to help rebels like me who can't follow simple directions. =)
Re: Tell HN: I'm writing an Erlang recipes book, are you interested?
#26Yes! Especially if you can cover mutual supervision - that sort of arrangement seems to get glossed over in the "tree of supervisors" world.
I'm intrigued by the idea of mutual supervision. This implies that both process dynamically become the supervisor of each other. By default, OTP supervisors are more architectural in nature -- they will always give you a top-down tree rather than a cyclic graph. Who restarts who? That's a bit tougher to do when everything becomes cyclic. Links are bidirectional though, so when one of the workers die, the other can kn…
My problem with having a tree is that it implies that at every level - including at the root - there's a single point of failure. I get the error kernel concept, I just don't necessarily trust the hardware.
Re: Tell HN: I'm writing an Erlang recipes book, are you interested?
#27Earlier quoted context omitted.
I'm intrigued by the idea of mutual supervision. This implies that both process dynamically become the supervisor of each other. By default, OTP supervisors are more architectural in nature -- they will always give you a top-down tree rather than a cyclic graph. Who restarts who? That's a bit tougher to do when everything becomes cyclic. Links are bidirectional though, so when one of the workers die, the other can kn…
My problem with having a tree is that it implies that at every level - including at the root - there's a single point of failure. I get the error kernel concept, I just don't necessarily trust the hardware.
What you need to do then is look into a few different options.
The first one is distributed Applications. This is part of the standard OTP stuff. What this does is declare a node as a master, and then failover nodes for your OTP application. When your master goes down, the other nodes take over it. Whenever the master is back, the failover nodes drop their applications and restarts it on the master. This loses all of the state if it hasn't been kept in a safe place.
Another one is to look at gen_leader. gen_leader is not part of OTP, but has been written by Ulf Wiger and is available on github or through agner. A quick description of it would simply be to say that it's a boosted gen_server that will find a master of itself somewhere and automatically replicate its data everywhere else. If the master dies, a leader election occurs and a new one takes over.
A third option is to have a masterless concept. This is what happens in Riak. Data has to be shared in clever ways and code organized to support such a design. Nobody's a master, everyone's a follower. You add redundancy here and there, push important state to a safe spot, etc. In the standard library, modules such as 'global' handles this kind of thing.
Supervisors are not exactly made to cross node boundaries. They protect your local processes. If you need something more complex to keep your state alive, this usually happens at a higher level for OTP.
Re: Tell HN: I'm writing an Erlang recipes book, are you interested?
#28Erlang recipes, not that much. Make that Erlang/OTP recipes with a strong emphasis on the OTP side of it, and a million times yes ! Or to say it slightly differently : I'm not that much interested in recipes about the Erlang language itself, but I'm very very interested in recipes/examples of architectures of actual Erlang/OTP softwares. I'm doing mostly Python these days, but I worked on a couple of side projects in…
Have you taken a look at "Erlang and OTP in Action" (http://www.manning.com/logan/) ?
Re: Tell HN: I'm writing an Erlang recipes book, are you interested?
#29Very needed book. In particular I am interested in limiting message queues in Erlang. I still don't get it - How one should deal with situations where messages are produced constantly in higher rate than consumed.. There is no protection in Erlang for this common scenario (I think)
You have to make the producer synchronous to the consumer so the consumer is slowed down. Ask for an acknowledgement on reception of any task/event. This will instantly limit the rate at which data can come in the final worker.
Well, that breaks the whole philosophy of async message passing in Erlang, where sending message always succeeds and is not dependent on the receiver. What you are suggesting is in fact limit the queue to be of size of 1 (if only one producer, or to the number of producers). This is not what queue is all about
Re: Tell HN: I'm writing an Erlang recipes book, are you interested?
#30For reference I tried to put a range of $ into your form (30 - 50), and it gave me an unfriendly error and cleared all of the fields. You might throw some client-side validation on those fields to help rebels like me who can't follow simple directions. =)
I am not the author of leanpub.com :)