<div dir="ltr"><div>Build a specific "tool" and then build another one. Repeat until finished, making sure to spend some time cleaning things up and generalizing along the way. Don't ask for advice until after you've started doing something. Make sure to provide precise information for what it needs to do, and include as much code as possible, when you ask. You don't know enough about problems you're not yet solving to ask the right questions.<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 17, 2015 at 7:31 AM, Lloyd R. Prentice <span dir="ltr"><<a href="mailto:lloyd@writersglen.com" target="_blank">lloyd@writersglen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ah Professor Smith,<br>
<br>
Once again I must confess my ignorance in hope that you can bring clarity. I've been working happily with sequential Erlang now for several years--- most recently an ambitious Nitrogen app. And I've heard from the beginning the virtues of of distributed concurrent processes happily chattering among themselves.<br>
<br>
But where the rubber meets the road, e.g. as I design my current app, I just don't get how to transform these virtues from virtual to real.<br>
<br>
Conceptually, I understand spawned processes, message passing, and supervisors. I've read and reread the Erlang canon. I've built several gen-servers and have worked my way through your e2 tutorial. It all makes good sense.<br>
<br>
But as I consider these principles in context of the architectural design of my current app, it's not at all clear how to apply them.<br>
<br>
The goal of my webapp is to deliver a set of data-based "tools" to "users" (wouldn't it be nice if we had many of these elusive critters) where each user owns his/her own data.<br>
<br>
In my case, users are non-technical author-publishers where each has a personal page for accessing tools and managing data related to project, marketing, and business management.<br>
<br>
Best I can tell, Cowboy and Nitrogen deal with "connections" and "sessions" under the hood, so I don't have to worry about them. But I struggle with such questions as:<br>
<br>
-- Should each "tool" be implemented as a gen-server?<br>
-- Should the user interface and database be further factored as separate processes?<br>
-- Should each "tool" be developed as a separate Erlang application then integrated as dependencies of a higher-level portal? Or should they be developed as a set of modules in one application?<br>
-- Or maybe each tool should be a totally independent "microservice," whatever that means.<br>
<br>
In other words, my attentive studies of Erlang have left me with very few PRACTICAL architectural techniques and tools; that is an insufficient bridge between the PRINCIPLES of concurrent Erlang and the PRACTICE of building robust Erlang systems.<br>
<br>
I'd much appreciate any guidelines to help me thrash through my confusion.<br>
<br>
But more, I wonder if others struggle with the same issues? And if so, how can I work with wizards like you to shed light on this corner of Erlang technology?<br>
<br>
All the best,<br>
<br>
Lloyd<br>
<br>
Sent from my iPad<br>
<div class="HOEnZb"><div class="h5"><br>
> On Jan 16, 2015, at 10:03 AM, Garrett Smith <<a href="mailto:g@rre.tt">g@rre.tt</a>> wrote:<br>
><br>
> I don't think Erlang has an edge over any other language in terms of<br>
> scaling across multiple servers - not at all. Other functional<br>
> languages have access to network APIs the same way Erlang does.<br>
><br>
> I suppose it's less fiddly to send Erlang terms across the wire.<br>
> Erlang has some built in facilities for building distributed<br>
> applications. Erlang's been doing this sort of thing for a long time.<br>
> But other languages can do it - particularly with the many<br>
> multi-language messaging libraries and tools available today.<br>
><br>
> What Erlang is special for IMO is it concurrency model, which is<br>
> implemented in and enforced by the *VM* - there's no shared memory<br>
> across threads of execution. One thread cannot corrupt the memory used<br>
> by another. To communicate between threads of execution, threads must<br>
> pass and receive messages (copied data).<br>
><br>
> I use the word threads generically here - in Erlang they're called processes.<br>
><br>
> This changes everything. It's completely transformative of the way you<br>
> build software. But the real payoff is in your locally running program<br>
> and less so in the ability to "distribute".<br>
><br>
> Try building software using single threaded, isolated processes (no<br>
> shared memory). How do you do it? If you use Erlang, you're forced to<br>
> do it - there's no choice.<br>
><br>
> It's the same as the operating system level. How do you build a LAMP<br>
> stack? (sorry, I'm older then 24) You install independent components<br>
> (Apache, PHP (fork exec'd), MySQL). Then you configure them to work<br>
> together. Then you start them up in a particular order. It's<br>
> coordinated communication independent functions. If one blows up, the<br>
> others keep working.<br>
><br>
> Imagine every part of your program working like this and you have an<br>
> Erlang application - actually, an Erlang *system*.<br>
><br>
> To replicate this model at the OS level, you'd write dozens of small,<br>
> independent applications that communicated with each other over pipes<br>
> or sockets. The ZeroMQ community is familiar with this approach.<br>
><br>
> The payoff for this, as I see it, is flexibility and speed of<br>
> introducing new functionality and fixing bugs.<br>
><br>
> To illustrate at a higher level, imagine a smart phone today that<br>
> didn't provide isolation across applications. What would you expect<br>
> from it? I'd expect it to not work unless the applications were all<br>
> nearly perfect. That means it will either not work, or the app<br>
> ecosystem would be very limited. But today, smart phones all have<br>
> kernels and user space where apps are isolated from one another. So I<br>
> can install some random thing from an app store and have a pretty high<br>
> confidence that it's not going to ruin my phone. The result is *huge*<br>
> app ecosystems with phones that pretty much work (shockingly well for<br>
> what they're asked to do).<br>
><br>
> When you use Erlang, your program becomes this ecosystem of "apps"<br>
> that you can add to, modify, remove very freely without concern for<br>
> the whole system. Your program will be evolvable *and stable* in the<br>
> same way your phone is evolvable and stable. It's a scalable<br>
> programming model!<br>
><br>
> It's truly fantastic - and seldom mentioned. (Folks here have heard<br>
> this line from me before - this is my particular drum that I like to<br>
> beat on :)<br>
><br>
> Use Erlang!<br>
><br>
> Garrett<br>
><br>
> P.S. I routinely run into critical memory problems in Java apps that<br>
> host ecosystems of other "apps" (plugins). It's a completely<br>
> unsolvable problem when your language/VM encourages intractable memory<br>
> graphs across threads unless you are incredibly careful about what you<br>
> run. If you want to make a system pluggable in Java (in one JVM), be<br>
> prepared for it to stop working at some point. So your either limited<br>
> in what you can do (and how fast) or in the stability of your program.<br>
><br>
> On Fri, Jan 16, 2015 at 6:29 AM, Jesper Louis Andersen<br>
> <<a href="mailto:jesper.louis.andersen@gmail.com">jesper.louis.andersen@gmail.com</a>> wrote:<br>
>> I think your observation is correct.<br>
>><br>
>> An Erlang program works by having many small processes, all isolated from<br>
>> each other. The way to communicate between processes is to send a message,<br>
>> asynchronously. This in turn leads to the key observation: when you send<br>
>> messages, you don't care about *where* the other process is. It could be<br>
>> local or on a completely different machine. The syntax and the semantics are<br>
>> the same, and you would program the system much in the same way. The<br>
>> environment is thus very homogeneous, compared to other solutions where you<br>
>> need to communicate on two levels: one for local messaging and one for<br>
>> distributed messaging.<br>
>><br>
>> I also second Bob's observation: The design feature of being functional<br>
>> forces a lot of properties which are beneficial to programs where<br>
>> correctness matters more than squeezing out the last ounces of performance<br>
>> from a tight computational kernel. But there is more to it than that. A good<br>
>> example is the choice of standard data structures which have no pathological<br>
>> problems in corner cases. Or the deep continued focus on scaling to multiple<br>
>> cores rather than looking for efficient single-core performance.<br>
>><br>
>><br>
>>> On Thu Jan 15 2015 at 11:38:52 PM Bob Ippolito <<a href="mailto:bob@redivi.com">bob@redivi.com</a>> wrote:<br>
>>><br>
>>> I'd agree with that observation. Erlang is particularly well designed for<br>
>>> reliability and ease of maintenance/debugging. I wouldn't necessarily say<br>
>>> that these properties are due to the language, it's really the environments<br>
>>> that Erlang has been deployed in that shaped the VM and libraries in this<br>
>>> way. The tooling and libraries have at least a decade head start for this<br>
>>> kind of industrial usage over just about any other functional language.<br>
>>><br>
>>>> On Fri, Jan 16, 2015 at 9:01 AM, Ken Wayne <<a href="mailto:kwayne@eastbay.com">kwayne@eastbay.com</a>> wrote:<br>
>>>><br>
>>>> I've been investigating functional languages and the concepts that lead<br>
>>>> to increased speed, reliability, and decreased maintenance.  Erlang seems to<br>
>>>> have a distinct advantage over other functional languages when you need to<br>
>>>> scale across multiple servers because it's a natural part of the language.<br>
>>>> Can anyone confirm/deny or elaborate on the observation?<br>
>>>><br>
>>>> Without wax,<br>
>>>> Ken Wayne<br>
>>>> <a href="mailto:kwayne@eastbay.com">kwayne@eastbay.com</a><br>
>>>> Desk: <a href="tel:715.261.9412" value="+17152619412">715.261.9412</a><br>
>>>> _______________________________________________<br>
>>>> erlang-questions mailing list<br>
>>>> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
>>>> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
>>><br>
>>> _______________________________________________<br>
>>> erlang-questions mailing list<br>
>>> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
>>> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> erlang-questions mailing list<br>
>> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
>> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>