3 ms·

you could, that is what Task.Supervisor do. But you then run into other problems. Who is supervising that supervisor? What are the strategy? What are the name?

• pmontra 10y ago
  My idea is to provide sensible defaults and write custom code to handle everything else. What we do now is to write custom code every time. My point is that the custom code we write is almost always the same for every process in the application. It hurts productivity. Let's use your list of questions as a checklist to validate the feasibility of this approach: > Who is supervising that supervisor? The supervisor of the process that spawned that process. Would that always work? Or the top supervisor of the application. Or your "high level dynamic supervisor" in the language runtime itself, which supervises only those anonymous supervisors and not every process. > What are the strategy? one-for-one should be a good default. > What are the name? Something automatically generated. A uuid. I'm not caring about that supervisor anyway. Would that work? > In which order to clean the process on shutdown? If I'm not caring about that process enough to write its supervisor explicitly maybe I don't care about its turn in the shutdown order. Anything easy to implement will do. > When in the init should we spawn it? Never, it's created only when the developer explicitly spawns the process. Well, we could reach the point when mix has a default task which spawns some processes with anonymous supervisors and there are no explicit supervisors left. This could change a little the nature of the language. I elaborate on this: Erlang/Elixir processes are already somewhat equivalent to objects: they communicate with message passing, conceptually similar to Smalltalk and many object oriented languages (Ruby has send, JS has apply, etc). The main difference is that Erlang processes have their own CPU and are naturally concurrent, which is great. If supervision can be made so easy to disappear inside the language, perhaps processes become even more conceptually like objects, created when needed (a "spawn" is a "new") instead of carefully planned entities much like system administrators plan services in upstart/systemd. This could be good or bad, I don't know, but that every object has its CPU feels right. BTW, google for Joe Armstrong Erlang is the only true object oriented language. It's not heresy :-)
  • kweinber 10y ago
    Sounds like a great case for a supervisor macro at your shop. I doubt your defaults would be common enough to be part of the library though. . . Ordering and naming tend to matter.
  • pmontra 10y ago
    I reply to myself days later. There was a language called Reia which did exactly that. Unfortunately the author dropped it in favor of Elixir even if in my opinion they are very different languages which would have had a different public. Reia could have been the language to move OO developers to functional, it's a much more difficult task for Elixir.