Indeed, if someone else has done the work for you, there is probably no need to know the details.
However, if there is a need to integrate either your private Rust library or one that nobody has worked on providing Elixir bindings, then there is clear motivation.
Of course, I cannot anticipate the popularity of such a course. Moreover, I do acknowledge that it has a high barrier both for the trainer/teacher and the trainees/students.
Thank you for responding! I hope that I will find useful any course you will decide to prepare (and subscribe to it 
)!
bdarla
2
Hisako1337
real world example I had in multiple companies now:
you have a database that contains your portfolio of stuff you do/sell/market on you web platform. This grows in size and complexity and accumulates business rules when to show what. So the pages start to get slower because they have to crunch through all of that one way or the other on request, and quite often also caching is not the answer for very dynamic stuff. Solution: spawn a GenServer during application boot supervised by phoenix, which crunches through all needed entities/rules and holds an protected ETS table (or multiple) with precalculated indices of records by filter/businessrule, with concurrent read enabled. Queries then are ETS specs/matches at runtime that don’t even hit the DB anymore and are lightning fast. Then wire up PubSub for database changes so that the ETS tables always stay synced and writes to them only happen through the owning GenServer. Then (if needed) cache the table on disk so its fast on next application boot and implement a green/blue-hotswap of tables when its re-created in the background.
I think thats basically touching most OTP concepts at once: Servers, Supervision, ETS (and their modes) + PubSub. For me its easy and natural to think in these concepts, but I have doubts these optimization techniques are widely known and understood. And its awesome, it allows under certain circumstances to end up with an absolutely clean domain model and “add runtime performance” afterwards, quite often with constant-time lookups when done well. Not to mention I store native Elixir language constructs in there, not some stuff that needs (de-)serialization into strings somehow which is much more slow and clunky and limited.
For the general resources out there: I think there is quite a bit, but it almost always starts with what OTP is and what the basic building blocks are and “let it crash” supervision stuff. But I think much more impact would be a list of common problems when scaling up apps, and why specifically Elixir/OTP has quite unfair advantages here natively.
edit: site note to Rustler: my mentioned approach above leads to runtime speed of the app, but the initial crunching/data-prep still needs to be done and takes time/memory. If this becomes uncomfortable, the crunching can be done by a handwritten rust lib to speed it up dramatically, I’ve done this in the past and would totally do it again!
6
axelson
Scenic Core Team
Personally I’d love to see more resources for Scenic (GitHub - ScenicFramework/scenic: Core Scenic library · GitHub), although I admit to being a little biased 
5
germsvel
Got it, so it sounds like you wouldn’t like a general resource but more advanced OTP use cases for scaling apps. Is that right? That sounds interesting. I’d have to think how to make that applicable across multiple cases for the course to be relevant for several people.
0
germsvel
Ah yeah, a Scenic course would be interesting! I haven’t worked with it, and unfortunately, I don’t know how much demand there would be for a course. Unfortunately, I think courses that sell better are tied to stuff people use during work. Do you know if Scenic is used in production in certain places? I don’t think I’d be the right author for the course, but maybe there’s demand there for someone else to create one, and I’m just unaware of it?
0
Hisako1337
Sort of. I think whats missing is a mapping from: Typical Problems when Scaling Up => This is how OTP makes this straighforward. Not really some cookbook, but even with the OTP basics which kinds of problems they help to solve in a lightweight way. What I’ve found mostly is more like “this is how OTP works and why its great”, not the signs to look for when to reach out to OTP and how, y know what I mean?
Most phx apps/developers I’ve seen so far basically use the tech as a cooler RubyOnRails but immediately spin up stuff like redis for sync without even knowing what they already have at their fingertips… the knowledge and capabilities are often not there. Even if many know that there is stuff like a supervision tree, they think “this is how the framework works internally” and I see untouched application.ex files in multi-year projects
2
germsvel
Oh… I see. That is an important distinction! Thanks for clarifying. It’s taking that knowledge to the next step – from knowing that OTP is there and perhaps how it works to knowing when to reach for it and use it effectively.
I like that idea. I wonder how to best communicate that aspect – maybe with examples throughout the course of how and when we can apply a given tech.
2
JEG2
Author of Designing Elixir Systems with OTP
I’m trying to decide what kind of “documentation” is needed for this. It feels like primarily Explanation with some How-to Guides thrown in.
I love this point! I’m thinking a lot lately about better ways to train fluency in programmers.
4
axelson
Scenic Core Team
I do know that Scenic is used in production in a few places, but truthfully it is only used in a very few places right now so it probably isn’t a great target for a course at the moment (although it would be great to see!). I do hope that the developer audience for Scenic will grow in the future to the point where a course would make sense 
1