9 ms·

Tell HN: I'm writing an Erlang recipes book, are you interested?

126 points by yrashk 15y ago

rayboyd 15y ago
From the point of view of someone who likes to tinker with languages, yes. Recipe books are usually extremely helpful and massive timesavers.
patrickaljord 15y ago
I know Yurii is very passionate about erlang and he's really good at it so this book should be great.
hanszeir 15y ago
Yes please I can't wait.
pstevens 15y ago
This sounds great. I have an introductory book to the Erlang language, and would love a recipe book on the language. I got into Perl via Programming Perl, and still refer to my Perl Cookbook to see how to use the language in certain scenarios.
wladimir 15y ago
Yes. I'd certainly value recipes that follow from using Erlang in real life. Especially if it contains succinct ways of solving common problems like the Python Cookbook, which is by far my favorite technical book.
asymptotic 15y ago
Yes, I'm interested! I'm particularly interested in recipe books that are both task-oriented and language-oriented. For exaple, Doug Hellman's PyMOTW is a phenomenal guide to using libaries that are part of the Python standard distribution and would be a key part of the library. However, some aspects of the recipe book should be task oriented: - Web server hosting static files using the standard inets server, and 3rd party libraries like webmachine, nitrogen, and yaws. - How to log - How to enable tracing etc.
- yrashk 15y ago
  Yes, this is quite close to what I am working on, both language and task-oriented. Also as a maintainer of erlagner.org index I know quite a lot of good libraries to use.
elliot42 15y ago
I don't know if this is antithetical to these recipe/cookbooks, but please consider teaching coherent themes or design principles via these recipes, rather than simply providing an assortment of useful tidbits. Erlang has such a unique foundation (functional programming + event-driven awesomeness) and so few books that there is a great opportunity to teach the Erlang mindset/perspective and not just a bunch of tips and tricks.
- yrashk 15y ago
  Very good and valid point, and it is pretty much at the foundation of the book approach (short guides ondesign principles when applied to real tasks, not just the theory)
RichClaxton 15y ago
I have just stared learning Erlang after more or less leaving Java, and the heavy weight world of J2EE. I was surprised how easy I have found learning Erlang maybe it just seemed to make sense, or it feels like the right way of doing things. I would be really interested in the book.
jeromec 15y ago
Hey, I see you're gaging potential reader interest by asking what they might pay. You might consider using StoryFunded (http://www.storyfunded.com http://www.storyfunded.com) for this. Our site lets authors raise funds for promising book projects. Like Kickstarter it's all-or-nothing where contributors only pay once the goal is met. If the goal is met authors receive the raised funds, minus 5% and processing fees. We've just went live, and our biggest challenge now is finding book projects people would be interested in funding. This may be such a project :) </plug> (sorry! :) )
scraplab 15y ago
Yes please!
deleted 15y ago
[deleted]
regularfry 15y ago
Yes! Especially if you can cover mutual supervision - that sort of arrangement seems to get glossed over in the "tree of supervisors" world.
- mononcqc 15y ago
  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.
  - regularfry 15y ago
    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.
    - mononcqc 15y ago
      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.
gabi38 15y ago
Very 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)
- mononcqc 15y ago
  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.
  - gabi38 15y ago
    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
    - mononcqc 15y ago
      No, this doesn't break the async philosophy. The synchronous sequence of calls is done by a question/reply made out of 2 asynchronous calls. It's just that simple to make something synchronous, as opposed to turning something synchronous asynchronous (by using a queue). By doing this you are not limiting the queue to the size of 1. If you have N producers, you can have more than N elements in the queue, but the idea is that each producer can only enter them one by one, with the agreement of the consumer. Nothing would stop the consumer from accepting a thousand of them before waiting before replying, therefore slowing down the producer. The idea is just to limit the rate at which you accept queries by tying it to the speed of the consumer. If this is not enough, you can look at things like the jobs tool (https://github.com/esl/jobs https://github.com/esl/jobs) to work with scheduling. By the way, you're mistaken on the idea of message sending always succeeding. The idea is that you will never error out because of trying to send a message (send and pray), not that the message will make it to destination. If you want any guarantee that the message made it, then you need that acknowledgement async message being sent back to you.
aw3c2 15y ago
Nope, never used Erlang and probably will never do so. Good luck though.
buntar 15y ago
excuse me for not answering your question, but I have a different suggestion (goes in a similar direction though): "Erlang in the Real World" From the top of my head: - portraits of companies and products who are using erlang - what does erlang do for them, that is not available in mainstream stacks - discussing their infrastructure and design desiscions as detailed as possible - what did they learn - how are they involved in opensource projects - numbers and figures of their running systems This could be a win-win situation. Companies can show their cool stuff. We can learn in what cases Erlang is a good solution. Anyway - Good luck with your book.
- yrashk 15y ago
  I think this kind of things is well covered in presentations given at any Erlang Factory. Slides and videos are available at erlang-factory.com I know for a fact there were some really good talks on development & deployment experiences. Hope this helps.
Xixi 15y ago
Erlang 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 Erlang in the past (a large one ~3 years ago, and a small one ~6 months ago). And for me the hardest was (and still is) to figure out how to use the OTP behaviors in an optimal way. How to make a nice, working supervision tree. I managed to pull working stuff out of the ground, but somehow it never fell OTPish. I couldn't tell if I did it right or wrong.
- yrashk 15y ago
  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.
- rdtsc 15y ago
  Have you taken a look at "Erlang and OTP in Action" (http://www.manning.com/logan/ http://www.manning.com/logan/) ?
  - Xixi 15y ago
    Thanks for the link, this book seems to be what I was looking for !
    - rdtsc 15y ago
      I got it and I like it quite a bit. It is a good introduction book for practical Erlang use, since you learn to do things the "OTP way" right off the bat. It has examples on how to build network servers (TCP RPC server, HTTP server, a caching service, setting up a distributed system with multiple nodes, resource discovery, logging, release managing, interfacing with C code and many other useful things).
rubyrescue 15y ago
i like it. i was thinking about the same thing just last week... http://news.ycombinator.com/item?id=2501387 http://news.ycombinator.com/item?id=2501387 - let me know if you want a collaborator...
showerst 15y ago
For 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. =)
- spatten 15y ago
  Good point. I'll take care of it. Thanks for letting us know!
- yrashk 15y ago
  I am not the author of leanpub.com :)
spatten 15y ago
For everyone who's interested in Yurii's book: if you go to http://leanpub.com/erlang-recipes http://leanpub.com/erlang-recipes and enter an email address, you'll get automatically notified when the book is first published. Thanks!

126 points by yrashk 15y ago

From the point of view of someone who likes to tinker with languages, yes. Recipe books are usually extremely helpful and massive timesavers.

patrickaljord 15y ago

I know Yurii is very passionate about erlang and he's really good at it so this book should be great.

hanszeir 15y ago

Yes please I can't wait.

pstevens 15y ago

This sounds great. I have an introductory book to the Erlang language, and would love a recipe book on the language. I got into Perl via Programming Perl, and still refer to my Perl Cookbook to see how to use the language in certain scenarios.

wladimir 15y ago

Yes. I'd certainly value recipes that follow from using Erlang in real life. Especially if it contains succinct ways of solving common problems like the Python Cookbook, which is by far my favorite technical book.

asymptotic 15y ago

Yes, I'm interested! I'm particularly interested in recipe books that are both task-oriented and language-oriented. For exaple, Doug Hellman's PyMOTW is a phenomenal guide to using libaries that are part of the Python standard distribution and would be a key part of the library. However, some aspects of the recipe book should be task oriented: - Web server hosting static files using the standard inets server, and 3rd party libraries like webmachine, nitrogen, and yaws. - How to log - How to enable tracing etc.

yrashk 15y ago
Yes, this is quite close to what I am working on, both language and task-oriented. Also as a maintainer of erlagner.org index I know quite a lot of good libraries to use.

elliot42 15y ago

I don't know if this is antithetical to these recipe/cookbooks, but please consider teaching coherent themes or design principles via these recipes, rather than simply providing an assortment of useful tidbits. Erlang has such a unique foundation (functional programming + event-driven awesomeness) and so few books that there is a great opportunity to teach the Erlang mindset/perspective and not just a bunch of tips and tricks.

yrashk 15y ago
Very good and valid point, and it is pretty much at the foundation of the book approach (short guides ondesign principles when applied to real tasks, not just the theory)

RichClaxton 15y ago

I have just stared learning Erlang after more or less leaving Java, and the heavy weight world of J2EE. I was surprised how easy I have found learning Erlang maybe it just seemed to make sense, or it feels like the right way of doing things. I would be really interested in the book.

jeromec 15y ago

Hey, I see you're gaging potential reader interest by asking what they might pay. You might consider using StoryFunded (http://www.storyfunded.com http://www.storyfunded.com) for this. Our site lets authors raise funds for promising book projects. Like Kickstarter it's all-or-nothing where contributors only pay once the goal is met. If the goal is met authors receive the raised funds, minus 5% and processing fees. We've just went live, and our biggest challenge now is finding book projects people would be interested in funding. This may be such a project :) </plug> (sorry! :) )

scraplab 15y ago

Yes please!

deleted 15y ago

[deleted]

regularfry 15y ago

Yes! Especially if you can cover mutual supervision - that sort of arrangement seems to get glossed over in the "tree of supervisors" world.

mononcqc 15y ago
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.
- regularfry 15y ago
  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.
  - mononcqc 15y ago
    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.

gabi38 15y ago

Very 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)

mononcqc 15y ago
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.
- gabi38 15y ago
  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
  - mononcqc 15y ago
    No, this doesn't break the async philosophy. The synchronous sequence of calls is done by a question/reply made out of 2 asynchronous calls. It's just that simple to make something synchronous, as opposed to turning something synchronous asynchronous (by using a queue). By doing this you are not limiting the queue to the size of 1. If you have N producers, you can have more than N elements in the queue, but the idea is that each producer can only enter them one by one, with the agreement of the consumer. Nothing would stop the consumer from accepting a thousand of them before waiting before replying, therefore slowing down the producer. The idea is just to limit the rate at which you accept queries by tying it to the speed of the consumer. If this is not enough, you can look at things like the jobs tool (https://github.com/esl/jobs https://github.com/esl/jobs) to work with scheduling. By the way, you're mistaken on the idea of message sending always succeeding. The idea is that you will never error out because of trying to send a message (send and pray), not that the message will make it to destination. If you want any guarantee that the message made it, then you need that acknowledgement async message being sent back to you.

aw3c2 15y ago

Nope, never used Erlang and probably will never do so. Good luck though.

buntar 15y ago

excuse me for not answering your question, but I have a different suggestion (goes in a similar direction though): "Erlang in the Real World" From the top of my head: - portraits of companies and products who are using erlang - what does erlang do for them, that is not available in mainstream stacks - discussing their infrastructure and design desiscions as detailed as possible - what did they learn - how are they involved in opensource projects - numbers and figures of their running systems This could be a win-win situation. Companies can show their cool stuff. We can learn in what cases Erlang is a good solution. Anyway - Good luck with your book.

yrashk 15y ago
I think this kind of things is well covered in presentations given at any Erlang Factory. Slides and videos are available at erlang-factory.com I know for a fact there were some really good talks on development & deployment experiences. Hope this helps.

Xixi 15y ago

Erlang 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 Erlang in the past (a large one ~3 years ago, and a small one ~6 months ago). And for me the hardest was (and still is) to figure out how to use the OTP behaviors in an optimal way. How to make a nice, working supervision tree. I managed to pull working stuff out of the ground, but somehow it never fell OTPish. I couldn't tell if I did it right or wrong.

yrashk 15y ago
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.
rdtsc 15y ago
Have you taken a look at "Erlang and OTP in Action" (http://www.manning.com/logan/ http://www.manning.com/logan/) ?
- Xixi 15y ago
  Thanks for the link, this book seems to be what I was looking for !
  - rdtsc 15y ago
    I got it and I like it quite a bit. It is a good introduction book for practical Erlang use, since you learn to do things the "OTP way" right off the bat. It has examples on how to build network servers (TCP RPC server, HTTP server, a caching service, setting up a distributed system with multiple nodes, resource discovery, logging, release managing, interfacing with C code and many other useful things).

rubyrescue 15y ago

i like it. i was thinking about the same thing just last week... http://news.ycombinator.com/item?id=2501387 http://news.ycombinator.com/item?id=2501387 - let me know if you want a collaborator...

showerst 15y ago

For 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. =)

spatten 15y ago
Good point. I'll take care of it. Thanks for letting us know!
yrashk 15y ago
I am not the author of leanpub.com :)

spatten 15y ago

For everyone who's interested in Yurii's book: if you go to http://leanpub.com/erlang-recipes http://leanpub.com/erlang-recipes and enter an email address, you'll get automatically notified when the book is first published. Thanks!