Thanks fixed.

Yea I should have used excalidraw instead of mermaid, thats on me. I am trying to focus on writing good content and I try to not get stuck on the stuff I'm bad at which is making nicer charts.

Hey, getting the work out there is always better than it sitting in the drafts waiting to be perfected! Thanks for the great article.

When José first launched LiveBook I thought it was Ambitious to take on the Jupyter project, but here its getting better and more usuable every single day.

Huge props, the Livebook Project is an incredible example what is possible with Elixir.

One of the interesting bits about Fly is we have our own servers distributed globally and connected via wireguard. Which makes it is trivial to setup Elixir/Erlang distribution globally, and most importantly, close to your customers. While its not a magic bullet it is pretty amazing to type a few commands have a globally deployed and directly distributed application.

Further Fly builds its Dashboard internally with Phoenix LiveView. We want the Phoenix and Ruby and Laravel and more communities soon, to grow because we believe if they grow, we will too.

That's just internal networking isn't it? VPC on the big clouds, DigitalOcean, and Vultr. Private Services on render.com.

I remember when Fly.io used to tout Firecracker but that is just a KVM engine, along with QEMU used on a zillion hosts.

What I'd like to see are customer success stories.

Edit: looks like you have to set up your own cross-region links on DigitalOcean and Vultr. So that interests me somewhat. :)

I go into this in the article :) the rustler team has a made a DirtyNif that can work around that, or you can manually yield if you'd like.

Indeed, your (excellent) article addresses this, here's the gist for those following along:

> Change `#[rustler::nif]` to `#[rustler::nif(schedule = "DirtyCpu")]`

> This tells the Rustler and BEAM to automagically schedule this in a way that won't block the entire world while it works. Again amazing, this is called a DirtyNif and is way more difficult to work with when you are manually using this via C.

Essentially, regular NIFs have to be extremely fast (< 1ms) because the VM can't preempt them - they run on the same scheduler threads the BEAM itself uses. Dirty NIFs solve this by running jobs in a completely separate thread pool ("dirty schedulers"). Rustler's docs explain it succinctly (https://docs.rs/rustler/latest/rustler/attr.nif.html):

> For functions that may take some time to return - let’s say more than 1 millisecond - it is recommended to use the `schedule` flag. This tells the BEAM to allocate that NIF call to a special scheduler. These special schedulers are called “dirty” schedulers.

> We can have two types of “lengthy work” functions: those that are CPU intensive and those that are IO intensive. They should be flagged with “DirtyCpu” and “DirtyIo”, respectively.

(Somewhat OT, but since I'm here: excellent article @ peregrine! I really enjoyed the read. Elixir and Rust are such a perfect fit. Plus, some of the specifics will be helpful for certain image-related things I'm actively working on, which is always nice. :) )

Nif's are always a risk to deploy cause they run embedded in the Beam runtime. That said we all use many nif's to do all kinds of stuff and its fine.

I go into this in the article a little but but the ruslter team has made dirtycpu and dirtyio macro's to help reduce the risks.

Author here. The rustler team has really made a great developer experience using Rust in Elixir and I just had to share.

Once you stop drinking the hangovers get worse and worse. The pandemic removed the pressure to drink (for some) and now it’s really hard to lose an entire day to feeling like garbage in exchange for a couple hours of partying. I still drink one or two socially but anymore and my next day is a mess.

Sounds to me more like you don't eat and hydrate enough when you drink. If I simply have alcohol for a night and nothing else, of course I'm hungover; but if I stay hydrated and eat AND drink, I can get pretty intoxicated without much ill effect the next day.

> Sounds to me more like you don't eat and hydrate enough when you drink.

If he's like me, that's not the case. I've always drank tons of water after drinking booze. I used to not get hangovers, but as I got older the hangovers got worse. I took a few years break from drinking, and now when I try drinking a little the hangovers are worse than ever before, no matter how much I hydrate. Two drinks at dinner is my limit now. And no earlier than dinner, because it makes me very lethargic for the rest of the day. Three drinks and I'll be miserable for the next day too.

Sounds like you drink more often than once or twice a quarter.

Oh yeah, I am a regular consumer, but the nature of hangovers seems entirely divorced to the frequency of drinking to me.

As mentioned in my original post. I used to regularly drink. Often with food and hydrating.

You have alcohol tolerance and I no longer have that. Your experience with hangovers is entirely based on tolerance.

Hydration and food are an important aspect of not getting a terrible hangover for me still but it does not stop them entirely.

Agreed, it's got to be the hangovers. Being drunk is fun enough, but not if it means your next 1-2 days is ruined. People were shown another way by the shutdown of bars, combined with the proliferation of cannabis as a (mostly) hangover-free alternative.

Being drunk is fun enough? having had to deal with an OD'ing colleague, passing out, getting cold and blue, having to call the ER... After that I restricted my intake to only very few small drinks.

I've never thought it fun to get that drunk, but 4 or 5 beers is fun in the moment. I hate what it does to me a few hours later though, so I no longer drink like that.

raises many questions:

- what movements was this evolved to support? (sprinting? walking a different way than was studied? running?)

- Are our shoes causing us to underuse this muscle?

Just from the video and the cadence shown I suspect if you did a slightly quick jog running on your forefoot you might hit that muscle on the rebound.

What you have is resistive electric stove. It is not the same as an induction stove.

Right, but duty cycling is a common method of output control. I've seen induction cooktops (presumably cheap ones) that also has the same behavior.

Sure all inductions jobs will use duty cycling (pulse width modulation if we’re getting technical). But that doesn’t determine responsiveness.

With a resistive hob (ceramic hob is the industry name) you’re relying on a large lump of stone (hence the name ceramic hob) to be a heat store and even out the elements lumpy power output. Problem with this approach is that it takes forever for the stone to heat up and cool down, so the hob is slow to respond.

With an induction hob, your heating pan directly with a electromagnetic field, the only thermal mass in the entire system is the pan. The hob can instantly change its power output, because its not relying on a stone to store energy, and thus has zero thermal mass.

So induction hob react at the speed of your pan, you have lightweight pan, then the pan temperature will change almost instantly. You got a heavy cast iron pan, then the pan will take a little longer to shed the extra heat.

FYI: If the hob glows when heating, it’s not induction. It’s a ceramic hob. Ceramic hobs are crap and give induction hobs a really bad name because the look the same when off. You can only tell if an induction hob is, if there’s a pan on top. They’re incapable of creating heat without a pan on top.

>inductions jobs will use duty cycling (pulse width modulation if we’re getting technical). But that doesn’t determine responsiveness.

It absolutely does when the pulses are on the order of ten seconds long, as in many electric ranges. But yes, the thermal mass of the heated coil/cooktop are also a major factor.

No it doesn’t, because change the ring setting will interrupt the current duty cycle, and terminates it early if it needed. A control system that didn’t do that would be more complicated than one that did, because it would require the control system to persist internal state across duty cycles.

Sure, in the limited sense of immediacy of response to change in control input. But in the more general sense of also considering accuracy/consistency of response to a control input, not so much. If you have a low thermal mass pan on a middling heat setting on a hob with excessively wide pwm like that, you can tell when the hob is on and when it's off just by how much the contents are sizzling any given second. The pan temperature is not stable because the pulses are too wide.

I’ve personally never encountered such a poorly designed induction hob. Induction hob require proper electronic control systems to operate, it would be weird to design such a system to operate with a wide PWM, it’s costs nothing for the system to operate at 1Hz or higher.

In ceramic hobs, they usually don’t have proper power control systems. They normally rely on a set of thermal switches to disconnect the main heating element when the ceramic element gets hot enough. The entire control system is analog and relies physical phenomena like wax expansion etc. Phenomena that is well know to be unresponsive, but very cheap.

My induction hob does similar on low power settings (at the lowest it's something like 1 second on to 4 seconds off). On higher power settings it's not noticable. I suspect the main reason for this is it's often harder (and more expensive) to design power electronics to operate over a wide PWM duty cycle efficiently, so the low-speed cycling is a way to provide the low settings without a significant cost increase.