EMPEX NYC is a regional technical conference focusing on Elixir, Erlang, and all things BEAM. Held annually in New York City, we’re a premier conference for the curious programmer.
I love people/talks that think outside of the box, look at thing in a different way and challenge commonly held beliefs, even if you don't agree I think it's enlightening, most of this went over my head but whilst it went over it, it also expanded it.
I think this approach is worth the effort. Especially since the core team is embarking on incorporating releases into mix. Looks like this subject is getting a lot of attention by the core team though, which is good.
Similar to part of Node's philosophy. Seems like it would work, but it would require the entire culture of Elixir to shift massively, which seems unlikely, unless jvalim sells it.
Agree with most things *except* not putting code into its own subdirectory. Putting application code in the top level is a recipe for disaster as it means that it is impossible to reserve names in the future for new files; consider if mix.exs had not been introduced yet ... the (imaginary) application called "mix" would be a confusing mess. No, for frameworks that include framework scaffolding, the application code must be in a well-known directory. It is also not desirable to put the scaffolding into a well-known dir, though this at least also "works", as that limits name choices for all applications. There are also complications arising from erlang code being in src/, and c code in c_src/ ... The configuration / node setup concepts are also non-starters as it attempts to put the the run-time variability of deployment with the invariant application code. In an era of kubernetes and similar, that makes absolutely zero sense except for the most trivial of applications. For exactly zero of our applications, nearly none of which are web apps, would this even possibly work. Cluster and application configuration really needs to be as dynamic and run-time as the modern deployment mechanisms in common use are. So while I agree we need something new for configuration and cluster definitions, what Dave suggests here is not it. GenServer rework: yes please. The rest, I hope the core team thinks about the current shortcomings Dave points out but ignores his suggested remedies.
Michael Terry The IP address of a node, how many nodes are in the cluster, which nodes are assigned which tasks, where the nodes are physically spun up ... Noddy would need to achieve the flexibility and a similar approach to service management as seen in systems like kubernetes which map services to resources based on demand. There are various ways to go about this, the kubernetes model is not the only one, but the concept remains. But putting IP addresses and by-hand defining cluster arrangement is just taking another misfeature from historical Erlang. (I manage some BEAM clusters at work which run our applications, and they are "autoconfiguring" rather than explicitly defined, and I can't imagine going back at this point.)
Yeah, agree, if Noddy required pre-specifying the IP addresses, that won't be dynamic enough. I have been assuming if it got fleshed out it'd become more flexible than that. At some point, you're just reimplementing Kubernetes, though. OTOH, the erlang VM has already reimplemented many features of an OS. :) I'm curious to know if Noddy is supposed to work well with Kubernetes or replace it.
agreed. I loved all the ideas, except by the code in the root folder, which should be in /src folder... and also, I'm a little skeptical about the Noddy tool, sounds like it's a replacement for all the Ops automation with advanced tools well stressed like Kubernetes, Terraform etc. Unless Noddy works well with the current deployment tools, that would make sense.
What a trainwreck of an introduction, complaining about younger generations caring more about eachothers well beings. No thanks, I'll watch something else.
I love people/talks that think outside of the box, look at thing in a different way and challenge commonly held beliefs, even if you don't agree I think it's enlightening, most of this went over my head but whilst it went over it, it also expanded it.
I think this approach is worth the effort. Especially since the core team is embarking on incorporating releases into mix. Looks like this subject is getting a lot of attention by the core team though, which is good.
+1
OMG so good.
This is so right
Similar to part of Node's philosophy. Seems like it would work, but it would require the entire culture of Elixir to shift massively, which seems unlikely, unless jvalim sells it.
its kinda weird right? the whole language and community revolves around 1 guy and 1 framework
2 Frameworks and like 4 people but pretty close.
hmmm,
1 framework is phoenix
1 person is jose valim
id like to know more! :)
I would chastise all Elixir developers for succumbing to herd mentality, but I can’t find either of them.
Shanene Larissa nerves is the other large framework for embedded software
So... will Noddy work if you deploy in docker containers?
Hot video empex
Agree with most things *except* not putting code into its own subdirectory. Putting application code in the top level is a recipe for disaster as it means that it is impossible to reserve names in the future for new files; consider if mix.exs had not been introduced yet ... the (imaginary) application called "mix" would be a confusing mess. No, for frameworks that include framework scaffolding, the application code must be in a well-known directory. It is also not desirable to put the scaffolding into a well-known dir, though this at least also "works", as that limits name choices for all applications. There are also complications arising from erlang code being in src/, and c code in c_src/ ...
The configuration / node setup concepts are also non-starters as it attempts to put the the run-time variability of deployment with the invariant application code. In an era of kubernetes and similar, that makes absolutely zero sense except for the most trivial of applications. For exactly zero of our applications, nearly none of which are web apps, would this even possibly work. Cluster and application configuration really needs to be as dynamic and run-time as the modern deployment mechanisms in common use are. So while I agree we need something new for configuration and cluster definitions, what Dave suggests here is not it.
GenServer rework: yes please. The rest, I hope the core team thinks about the current shortcomings Dave points out but ignores his suggested remedies.
You're talking about Noddy? Could you give an example of run-time variability that it's obvious the system couldn't handle?
Michael Terry The IP address of a node, how many nodes are in the cluster, which nodes are assigned which tasks, where the nodes are physically spun up ... Noddy would need to achieve the flexibility and a similar approach to service management as seen in systems like kubernetes which map services to resources based on demand. There are various ways to go about this, the kubernetes model is not the only one, but the concept remains. But putting IP addresses and by-hand defining cluster arrangement is just taking another misfeature from historical Erlang. (I manage some BEAM clusters at work which run our applications, and they are "autoconfiguring" rather than explicitly defined, and I can't imagine going back at this point.)
Yeah, agree, if Noddy required pre-specifying the IP addresses, that won't be dynamic enough. I have been assuming if it got fleshed out it'd become more flexible than that. At some point, you're just reimplementing Kubernetes, though. OTOH, the erlang VM has already reimplemented many features of an OS. :) I'm curious to know if Noddy is supposed to work well with Kubernetes or replace it.
Aaron, you used the A-word. I think you meant to say putting "component" code in the top level. ;-)
agreed. I loved all the ideas, except by the code in the root folder, which should be in /src folder... and also, I'm a little skeptical about the Noddy tool, sounds like it's a replacement for all the Ops automation with advanced tools well stressed like Kubernetes, Terraform etc. Unless Noddy works well with the current deployment tools, that would make sense.
Oh well, it’s actually not the Wendy’s guy. I’m out.
Cynic.
What a trainwreck of an introduction, complaining about younger generations caring more about eachothers well beings. No thanks, I'll watch something else.