<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:10pt"><div><span><br></span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;"><span>"</span><span style="font-family: monospace; font-size: 10pt;">The "OTP2" part interests me a lot more. One of my favorite ideas is to</span><span style="font-family: monospace; font-size: 10pt;"> </span></div><span style="font-family: monospace;">be able to define the whole supervision tree in a single module, and to </span><br clear="none" style="font-family: monospace;"><span style="font-family: monospace;">have it feature more complex components like pools for example. It could </span><br clear="none" style="font-family: monospace;"><span
style="font-family: monospace;">come with a default pool implementation, with a well defined interface </span><br clear="none" style="font-family: monospace;"><span style="font-family: monospace;">(from the point of view of the supervision tree) that allows it to be </span><br clear="none" style="font-family: monospace;"><span style="font-family: monospace;">replaced with whichever one you want. So instead of having 10 modules </span><br clear="none" style="font-family: monospace;"><span style="font-family: monospace;">describing your application, it could all be in a very visual format ..."</span><br clear="none" style="font-family: monospace;"><div class="yahoo_quoted" style="display: block;"> <br> <br> <div style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 10pt;"> <div style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif;
font-size: 12pt;"> <div dir="ltr"> <font size="2" face="Arial"> On Monday, February 17, 2014 3:43 PM, Loïc Hoguin <essen@ninenines.eu> wrote:<br> </font> </div> <blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; margin-top: 5px; padding-left: 5px;"> <div class="y_msg_container">Thoughts and ideas are not worth a lot until they are tested so I will <br clear="none">spare you most details for now. It's still a pretty long read.<br clear="none"><br clear="none">For the "Erlang2" part, there isn't much to say. Erlang is a language <br clear="none">that is almost perfect. My conclusions about improving it are that there <br clear="none">are very few things that can be improved, and they are mostly edge cases <br clear="none">(shadowing would be a big one, and not being able to do (<< <br clear="none">B:Len/binary, _/bits >>, Len) in a function clause would be another - <br clear="none">but the latter is going to
be solved soon as I gather). The rest of it, <br clear="none">well, I came pretty much to the same conclusions as Joe, the only thing <br clear="none">I would add is a basic form of metaprogramming. Basically you want to be <br clear="none">able to do two things: compute some data at compile time, and run tests <br clear="none">at compile time (and fail to compile if the tests fail). Optionally <br clear="none">would allow you to do some conditional builds to work around issues with <br clear="none">a specific version of Erlang. But no macros or other weird stuff that <br clear="none">just make the code more complex for no good reasons.<br clear="none"><br clear="none">I'm no language expert and I'm not too interested in this part so don't <br clear="none">expect anything from me on that point. If I ever attempt something it <br clear="none">would just be a very basic wrapper on top of the current Erlang syntax <br clear="none">to allow for compile-time
stuff to happen (meaning: outside functions, <br clear="none">and perhaps even outside modules entirely).<br clear="none"><br clear="none">The "OTP2" part interests me a lot more. One of my favorite ideas is to <br clear="none">be able to define the whole supervision tree in a single module, and to <br clear="none">have it feature more complex components like pools for example. It could <br clear="none">come with a default pool implementation, with a well defined interface <br clear="none">(from the point of view of the supervision tree) that allows it to be <br clear="none">replaced with whichever one you want. So instead of having 10 modules <br clear="none">describing your application, it could all be in a very visual format in <br clear="none">a single module.<br clear="none"><br clear="none">I'm more interested in doing an "OTP2" that targets a different use than <br clear="none">long running server applications though. As you might already know, I
<br clear="none">like video games, and I have tried a few quick prototypes of games with <br clear="none">Erlang. I think there is a lot of potential, but the barrier of entry is <br clear="none">very high. An "OTP2" geared toward games would help greatly. Games <br clear="none">typically have a main loop. There's basically no way around that today <br clear="none">because most graphic APIs aren't thread safe. SDL2 was released not too <br clear="none">long ago for example, and it still isn't thread safe. But that's not a <br clear="none">big problem, Erlang's concurrency can still play a big part. For <br clear="none">example, by making the lists module parallelize processing of the list <br clear="none">automatically past a certain threshold. Or providing efficient timer <br clear="none">capabilities (because the timer module ain't it). And the processes that <br clear="none">access the API can always be tied to scheduler 0 to avoid any issues.<br
clear="none"><br clear="none">I started playing around making an SDL2 NIF this week-end. The first <br clear="none">thing you instantly win is not having to worry about freeing resources <br clear="none">(with a few gotchas of course, you can only have so much in memory). The <br clear="none">GC does it for you! The second thing you instantly win is Erlang's <br clear="none">pattern matching. The article I wrote about matching tic tac toe <br clear="none">solutions directly instead of trying to write an algorithm is a good <br clear="none">example of that. The code becomes small and clear and you can focus on <br clear="none">actually building the game.<br clear="none"><br clear="none">Of course, for anything to come out of these experiments, I have to find <br clear="none">a way to not get bored, which may prove difficult. Time will tell.<br clear="none"><br clear="none">On 02/17/2014 01:30 PM, Pierre Fenoll wrote:<br clear="none">> Hey Loïc,<br
clear="none">><br clear="none">> I don't mean to hijack the thread.<br clear="none">> Can we have more information on "Erlang2/OTP2"? Your guidelines and<br clear="none">> back-of-a-napkin experiments interest me greatly.<br clear="none">><br clear="none">><br clear="none">> Cheers,<br clear="none">><br clear="none">><br clear="none">><br clear="none">> _______________________________________________<br clear="none">> erlang-questions mailing list<br clear="none">> <a shape="rect" ymailto="mailto:erlang-questions@erlang.org" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br clear="none">> <a shape="rect" href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br clear="none">><br clear="none"><br clear="none">-- <br clear="none">Loïc Hoguin<br clear="none"><a shape="rect" href="http://ninenines.eu/"
target="_blank">http://ninenines.eu</a><div class="yqt5349722011" id="yqtfd18177"><br clear="none">_______________________________________________<br clear="none">erlang-questions mailing list<br clear="none"><a shape="rect" ymailto="mailto:erlang-questions@erlang.org" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br clear="none"><a shape="rect" href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br clear="none"></div><br><br></div> </blockquote> </div> </div> </div> <div><span style="font-family: monospace;"><br></span></div><div><span style="font-family: monospace;">Take a look at this: https://github.com/thomasl/gen_app</span></div><div><span style="font-family: monospace;"><br></span></div><div><span style="font-family: monospace;">Here is one application I just started:</span></div><div><span style="font-family:
monospace;"><br></span></div><div><span style="font-family: monospace;"> 1> gen_app:app_sup(om, [{sup, {sup, om, [om_ets_owner, om_repository_server, om_code_server]}).</span></div><div><span style="font-family: monospace; font-size: 10pt;"><br></span></div><div><span style="font-family: monospace; font-size: 10pt;">Which starts a (dynamic) application 'om' with a supervisor 'om' handling three gen_servers on localhost.</span></div><div><span style="font-family: monospace; font-size: 10pt;"><br></span></div><div><span style="font-family: monospace; font-size: 10pt;">Caveats: Somewhat inelegant notation so far, and you still need 'application' for the more complex cases. No pool handling at the moment either. But it's pretty compact.</span></div><div><span style="font-family: monospace; font-size: 10pt;"><br></span></div><div><span style="font-family: monospace; font-size: 10pt;">Best,</span><br></div><div><font
face="monospace">Thomas</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">PS. Apologies to those I've written to recently -- Yahoo is acting up, perhaps due to THE HUGE THREADS we're having, so I'm having some trouble reading my mail at the moment. Sporadically hanging client, etc.</font></div></div></body></html>