On December 9th I returned to the Trolley Barn to DJ again for my friend Valerie Young. This time around my goal was to have a better mix of high energy and lower energy “groovy” tunes, and I wanted to be better prepared for tying in endings at any time, no matter how many times through the caller requested.

Prep

While I still prepped by marking each time through the dance with whether it looped cleanly or not, this time I (mostly) marked it with a cue instead of a 64 beat loop. I also named the cue based on what other cues I could jump to cleanly from it. For example, if I were on the last time through the dance I would mark if it looped cleanly itself, but also that I could jump backwards 3 times to cue 6 (or whatever the case may be). This way if I’m nearing the end of the dance but the caller is running it a bit longer I can reset without a single 32 bar phrase starting to get repetitive. I can also plan ahead by seeing that cue 6 lets me jump back to cue 8 or 9 afterwards (let’s assume these are the last two cues), which means that if the caller immediately calls 2 more times through I know that I can cleanly jump back to 2 more times without incident. I also mark a handful of things in the music such as if this time through the dance is a big recognizable build up (which I might not want to repeat even if technically it sounds okay), or if I shouldn’t jump back before a cue because the energy is significantly lower and we don’t want to kill the energy that had already been built up on the dance floor. This made it much easier to always follow the callers instructions and not have to scramble to wrap up the song or ask if we can do 4 times through the dance instead of 2 or what not.

The Set

I started out the set with a slowed down mix of “ Whelan’s ”, “ Baghad Gus ”, and “ Congress Reel ” all by Wild Asparagus. This was a medley that I had planned for my previous set but hadn’t managed to use, but it worked quite well to “ Whoever is Right is Right ” by Jim Hemphill. The only iffy moment I had in this medley was in one of the transitions where I thought I executed it perfectly, only to have the tune I was introducing jump half a beat ahead, breaking the rhythm. I had left the Quantize option on (which locks the two beat grids together even if you’re a little bit off) and unfortunately the beat grid on the song in question was about half a beat off at the point I was doing the intro.

Lesson learned: pay more attention to what options you’ve got selected (and reset them between songs, this would be a problem several times during the evening) and in a song where the beat grid can’t be right through the entire song (ie. because of tempo changes), make sure it’s correct at the point you’re going to mix in.

Whelan's / Baghad Gus / Congress Reel by Wild Asparagus, DJ mix

For the second dance Valerie picked “ Made Up Tonight ” by Erik Hoffman. This dance is relatively easy and in some ways similar to the previous dance so I decided the dancers could handle a little bit higher tempo and energy level. I did a mix of “ Bus Stop! ” by The Free Raisins and “ Rec Hall ” by Kingfisher. This is another mix I had prepared for my previous set and one of the ones I was most excited about performing. Unfortunately I completely broke the transition by just forgetting to bring the volume up on Rec Hall, so I ended up killing the music entirely for a few beats before I realized what was happening and brought it back in. It sounded terrible, and this one the dancers couldn’t help but notice, but Valerie kept calling so they were on beat still when I finally realized what was happening.

Lesson learned: go ahead and beat match and mix in a few bars early, then do the transition by bringing the volume up instead of just hitting play, or just remember to have the volume up first.

Bus Stop! / Rec Hall by The Free Raisins and Kingfisher, DJ mix

At this point Valerie decided to take the evening in a different direction from the modern, improper and becket contras that the Trolley Barn normally asks callers to stick to. She called “ The Steps of Waterloo ”, a traditional Sicilian circle, which I’ve never seen done at the Trolley Barn before. Since this one is both easy and a bit silly I used “[Flying Ice Cream]” by Giant Robot Dance which starts out very slow and groovy, then ramps up dramatically in the second half. Once the dance ramped up I mixed it with “ The Randomainians ” by The Great Bear Trio to make it last a little longer. This was the one mix and dance combo of the night that I was mostly extremely pleased with, when the tempo and energy ramped up half way through the song the dancers cheered and started frantically rushing to try and get to the basket swing in the limited time the (normally too fast) music allowed which was a lot of fun.

Lesson learned: prepare about twice as much music as you think you’ll need for the evening (to be fair, I already knew this, I was just struggling with the preparation for this set and didn’t end up with enough time to finish the other mixes I was considering).

Flying Ice Cream / The Randomanians by Giant Robot Dance and The Great Bear Trio, DJ mix

Continuing Valerie’s theme of not doing modern contras she picked “The Hand Jive”, a proper ceilidh, by Colin Towns next. Because this dance is a bit more “fun” and contains some patty-cake like hand games I decided to do a simple but fun mix of “ Raccoon ” by Wake Up Robin and Disco Snails by Vulfmon and Zachary Barker.

Unfortunately I hadn’t considered that, easy as the hand clapping is, it required Valerie to do a significant amount more calling than she normally would do and never drop out, so picking a song with lyrics was a bad idea. A few people still got a chuckle out of the “Disco Snails” cameo though.

Lesson learned: make sure to pay attention to how much the caller will have to talk and ask if they plan on dropping out before introducing something with lyrics.

Racoon / Disco Snails by Wake Up Robin and Vulfmon and Zachary Barker, DJ mix

We took our mid-dance waltz break at this point for which I played “ Waiting for Landfall ” by Julie Vallimont, “ Indifference ” by the String Beings, and “ Norwegian Reinlender / Schottis From Idre ” by Wild Asparagus. I’d hoped that some of the dancers would know the schottische for the second part of the medley, but mostly it just confused everybody who kept trying to waltz even though it was no longer a waltz.

Coming back we were running a bit late so I decided to drop the show-stopper for the evening, a mix of “ Rainy Night ” by The Dam Beavers, “ Tween Spirit ” by Giant Robot Dance, and “ Smells Like Teen Spirit ” (which, of course, the previous tune is a cover of) by Nirvana. This was paired with “ Birminghams ” by Gary Nelson.

I played the first two tunes as a normal medley, then when Valerie indicated that she was ready for three times left through the dance I mixed in the actual Nirvana version just for the ending. I was worried this crowd wouldn’t care for it, but when the tune first came in (as “Tween Spirit”) a lot of the dancers started singing along, and when actual Nirvana came in at the end the energy really ramped up and there was a lot of cheering and stomping, so apparently even the younger members of the crowd were still excited about 90s grunge!

The only real problem with this dance is that I had one moment where I had a clean loop that I wanted to repeat but as I did so some of the dancers, knowing what came next in the song, started singing the next verse and then had to stop when the music wasn’t what they expected.

Lesson learned: when doing a pop song don’t do transitions that would break the progression of the song that people are already used to, even if they sound okay.

Rainy Night / Tween Spirit / Smells Like Teen Spirit by The Dam Beavers, Giant Robot Dance, and Nirvana, DJ mix

At this point I realized that I hadn’t prepared enough mixes for the dance and I was more or less out of material. For the next one Valerie asked to do a very short square dance, the “ Cumberland Square Eight ”. Since it was going to be so short and timing didn’t matter I played “ Heather’s Concussion ” by The Great Bear Trio without mixing it into a medley.

This tune is itself very short (only three times through) and far too fast for a normal contra, so I slowed it down (though still keeping it too fast) and sped it up slowly through the dance to mess with the dancers. They looked like they had a good time!

Heather's Concussion by The Great Bear Trio, DJ mix

This left us with just enough time for a no-walk-through contra. I had nothing else prepared but wanted to send us out on an easy-tempo dance after the various fast shenanigans from the rest of the night, but still have some good energy. I dug around in my library and ended up playing “ Apple Blossom ” by Great Bear. Since I didn’t have anything to mix this with I just played it through and looped once or twice near the end to keep the high-energy ending going. The dance Valerie picked was an easy ending dance that is unfortunately called “Unnamed Contra” and she didn’t know who wrote it.

Apple Blossom by Great Bear, DJ mix

We then closed down the evening (very late, much to the chagrin of the organizers) with “ Mending ” by “The Little Mercies”.

Stuff I Learned

A recap of the things I need to take away from the evening:

• Be thoughtful about resetting all controls, levels, mixing, effects, etc. between tunes. Possibly write down the initial state for each song so that you can re-set the board at a glance.
• Beat match early then use the volume sliders for transitions, don’t just start playing immediately at the entry point (or just remember to turn up the volume as you approach the mix point).
• Consider how much the caller will have to talk in any given dance and how soon they’re dropping out before mixing in vocals.
• For pop songs, don’t violate the order of the verses or breaks that people expect, even if the final result sounds okay. It’s jarring for the dancers who are used to it being a certain way.

And finally: relax and enjoy it! While I spend the entire evening worrying about how the sound dropped out for a moment, or my transition was a beat off and I saw the dancers stumble and catch back up, or whatever other disaster might have befallen, no one remembers any of that. I got a very nice message from the organizer the next day telling me how excited everyone was and how many conversations she’d had with people telling her how much they enjoyed the music!

Other Links

• The set list on MusicBrainz
• Recordings of the evening can be found on the Internet Archive

As we close out our “Meet the Team” series for 2025, we’re delighted to introduce Camjar Djoweini, Business Development Manager, Nordics, at Erlang Solutions. Camjar shares what drew him into his new role, the excitement of working within Trifork’s global ecosystem, and the ambitions driving him into 2026. He also reflects on his favourite winter traditions and the personal routines that help him stay energised and focused throughout the year.

Can you tell us about your new role at ESL?

I’ve joined ESL Nordics Fjällräven as Business Development Manager, Nordics, where my focus is expanding our market presence into new greenfield areas alongside Erik. The mission is clear and energising: outbound, outbound, outbound.

Which part of your new role has sparked the most curiosity or excitement so far?

It’s a mix of working with exceptionally talented and experienced people and having access to the opportunities that come with being part of Trifork globally. I love that I’m within one of 71 companies in the group yet still feel connected as if we’re operating as one large organisation. We’re agile like a startup but strong like a Fortune 500. That breadth of access and innovation keeps my curiosity alive every day.

Looking ahead to 2026, what are you most looking forward to achieving?

I’m a high pressure performer and set ambitious expectations for myself. My goal is not only to hit the targets we’ve set but to exceed them, to make the whole team proud. I want to help shape our future, open new doors within the organisation and contribute meaningfully to our long term vision.

Ahead of the holiday season, are there any traditions you’re particularly looking forward to?

This might be an unpopular opinion, but I love the darkness and the cold. There’s something beautiful about how snow lights up the darkest hours. Winter helps me focus with routines, deadlines and structure, all leading to one of the cosiest traditions of the year. Good food, warm decorations, time with friends and family and the chance to unwind for a week. Christmas is my favourite tradition and we go all in.

When you’re away from the office, what brings you the most energy and joy?

I really value being able to structure my own productivity. I can work out during lunch without feeling like I need to rush home, and if something is better done at 7 pm, I can do that and still be productive at 8 am the next morning. Having the freedom to optimise my hours while maintaining strong internal connections with colleagues is incredibly energising.

Final Thoughts

And that brings our 2025 Meet the Team series to a close. A big shoutout to Camjar for sharing his energy and perspective, and to all the fantastic colleagues who took part this year. Their stories, passions and quirks are what make our team such a great place to be.We’ve got plenty more to share in the new year, so keep an eye out for fresh profiles, behind the scenes insights and more of the people who make Erlang Solutions what it is. And if you’d like to chat with our team or get involved, please get in touch .

The post Meet the Team: Camjar Djoweini appeared first on Erlang Solutions .

Erlang Solutions launched SAFE, a Security Audit for Erlang in the fall of 2023. We extended the analysis for Elixir in the spring of 2024 and now, SAFE officially supports Phoenix Liveview, which means a SAFE scan is now looking for vulnerabilities common in Phoenix web applications.

What is SAFE?

SAFE is a security scanning tool for Erlang, Elixir and Phoenix (LiveView) codebases. It works by loading and analysing your code, without running it. SAFE conducts an in-depth analysis of codebases, which can help you and your company to elevate your cybersecurity.

Supporting Phoenix LiveView

Now, as of the 1.3.0 release of SAFE, we support Phoenix LiveView, which means we can check for the following vulnerabilities:

• Cross Site Scripting (XSS)
• Cross Site Request Forgery (CSRF)
• Cross-Site WebSocket Hijacking (CSWSH)
• SQL Injection (with Ecto support)
• Denial of Services (DoS)
• Session leakage (unprotected session information)
• Session fixation (session ID renewal issues)
• Session hijacking
• Content Security Policy (CSP)

On-Prem report visualisation

With the release of the new SAFE version, a new SAFE product flavour was also launched, called SAFE OnPrem. This solution allows companies to host a centralised security report viewer that engineers and security specialists can access via the web interface.

Overview page of an example report:

User management:

Running SAFE

If you are interested in running SAFE on your code base, please check out our Quick Start Guide and contact the SAFE team . You can also drop us a message if you maintain an open source project, as you may be eligible for a free SAFE license.

More information about Open Source licensing can be found in our announcement blog post .

The post SAFE for Elixir: Phoenix LiveView appeared first on Erlang Solutions .

The moment a fintech product shifts from prototype to production is often when the cracks appear. Tiny shortcuts. Half-formed assumptions. Decisions made because “we’ll fix it later.” They all return, and they return quickly.

At first, everything looks fine. The demo works. Early users onboard without trouble. In turn, confidence builds. Then real volume arrives with real expectations, and the product that once felt promising starts to resist growth.

The (Minimum Viable Product) MVP phase should have revealed the weak points. It should have been the place to break things safely. But often it becomes a race to launch without learning much at all. Speed gets mistaken for insight, and the cost shows up when the stakes are highest.

For teams serving SMEs, the risk is even greater.

The Scaling Problem: When “go fast” Stops Working

Fintechs focused on small businesses usually start strong. They prove demand, attract their first cohorts and show early traction.

Then comes the real hurdle: scale.

Small and medium-sized businesses don’t want flash. They want reliability, simplicity and absolute confidence that their money, payments, payroll and data won’t break at the wrong moment. According to The Payment Association , with 5.51 million SMEs representing 99% of UK businesses alone, that demand is huge.

Picture thousands of businesses depending on your platform every minute. If your stack can’t handle load variations, regulatory nuances across regions or the complexity of business onboarding, growth becomes dangerous.

And the consequences aren’t theoretical. One industry review found that hidden infrastructure issues in fintech quietly drain 10–20% of capital and create terrifying downtime costs.

When an SME loses access to its financial tools, even for an hour, it can feel like a lost lifeline.

Scenario in action

Let’s imagine a fintech that nails product-market fit in one region. SMEs love it. Growth follows. Then expansion begins, and strain appears immediately.

The original build never accounted for multi-region onboarding, regulatory differences, load variation or different payment rails. The product did not fail. Success exposed everything the MVP never tested.

This often happens when early architecture is not prepared for real-world complexity. As usage expands, the gaps surface quickly.

Why MVP habits collapse at SME scale

In the rush to market, fintechs often use the MVP mindset (launch early, iterate fast). That works for consumer apps but is riskier for platforms serving SMEs, where downtime, data inconsistency and compliance are costly.

Research shows only around 43% of UK SMEs accessed external finance in Q2 2024, and just 44% of applications were successful. Given this tight margin of trust and reliability, the fintech solving SME problems must get the architecture right from early on.

SMEs often adopt fintech solutions fast: one study found that 65% of UK SME decision-makers believe they need the agility of fintech to enable their growth plans. The opportunity is there; what is less guaranteed is the product foundation. When the MVP is built purely for launch speed, the next stage of growth can expose fragilities.

Common challenges for SME-serving fintechs:

• Lack of monitoring for thousands of SME users rather than hundreds
  
• Compliance demands when onboarding business accounts vs consumer
  
• Manual operational workarounds that don’t scale
  
• Infrastructure built for single region, not multi-market
  

These issues rarely show up in a prototype. They surface the moment production load, regulation and real SME behaviour collide.

Building for production: What matters most

Turning a prototype into a platform that serves millions of SMEs requires architectural discipline. It starts with asking a simple question: what happens when this grows?

Technology choices matter. Systems built on concurrency, resilience and fault tolerance give fintechs room to scale without rebuilding from scratch.

Platforms using the BEAM virtual machine and languages like Elixir rely on lightweight processes and supervision strategies that keep systems stable under heavy load. Adopting these foundations early means your prototype does not have to be replaced. It evolves.

And SMEs feel that difference.

What this means for fintech SMEs (and their customers)

When a fintech platform is designed with SMEs in mind, the impact is felt inside the company and in the daily routines of customers.

Reduced downtime and more stability

SMEs cannot pause operations because a platform is struggling. Payroll, payments and transactions move continuously. Downtime is costly and trust disappears quickly. A system designed to scale helps avoid those fragile moments and reduces the need for constant emergency fixes.

Lower cost of change

When the architecture anticipates growth, teams spend less time rebuilding and more time improving the product. Smoother onboarding, integrated payments and better analytics become easier to deliver. Languages like Elixir support this quietly, allowing teams to make changes without breaking the foundations.

Simpler compliance and clearer audit-ability

Serving SMEs means navigating business account requirements, lending oversight and payment regulations. Systems built to production standards make compliance part of the design rather than a collection of manual steps.

Faster deployment and steady iteration

Fintechs must keep innovating without sacrificing stability. Lightweight processes and strong supervision make frequent, safe deployments possible. Stability and progress can coexist.

A better experience for SME customers

When the platform works reliably, teams can focus on problems that matter: cash-flow visibility, credit access, smoother invoicing and efficient banking. SMEs notice. 85 percent of UK SMEs would consider choosing a fintech over a traditional bank because the digital tools are stronger.

To conclude

Fintechs serving SMEs rarely struggle because the idea is weak. They struggle when the technology behind that idea cannot keep up with real businesses. The prototype is only the starting point. Production is where reliability becomes a promise you must keep.

SMEs run on trust, cash flow and predictable systems. When a platform fails, it affects salaries and core operations.

This is why resilient foundations matter. Using a programming language like Elixir, built on BEAM’s concurrency and fault-tolerance strengths, helps teams create systems that stay steady even as demand rises. It gives product teams room to improve instead of constantly patching.

The SME opportunity is significant. The question is whether your platform has the strength to grow with it. If you’re a fintech and would like to build with resilience in mind, let’s talk .

Turning fast- moving prototypes into stable, scalable solutions is far easier when you make the right choices early.

The post From Prototype to Production: Scaling Fintech for SMEs appeared first on Erlang Solutions .

We hear this too often: “XMPP uses XML. It should use JSON—it’s more modern.”

The logic seems straightforward: JSON came later, so it must be better. But better for what, exactly?

JSON became successful because it’s the standard serialization format for JavaScript. That made it convenient for browser-based applications.

Does that make it the universal format for every protocol? Of course not.

Consider this: browsers still use HTML to organize web pages, not JSON. Same with CSS. Why? Because using JSON for everything would be a nightmare.

XML remains the best format for representing trees—deep hierarchies of nested data. JSON handles flatter structures well, but good messaging protocols are extensible: extensions can be embedded at different levels and composed together, like Lego bricks. That’s where XML shines.

The Performance Myth

Another common claim: XMPP’s XML is more complex than JSON, so it must be much slower.

In practice, XMPP chat platforms are snappier, with remarkably low message latency. How?

XMPP clients don’t parse XML the way most people assume. They’re not building massive DOM trees in memory, like a browser loading a page. Instead, they use stream-based parsing—XML arrives, gets parsed incrementally, and converts directly into native data structures.

This is especially true in browser environments, where XMPP streams run over WebSockets, which naturally frames the XMPP protocol. That’s why you are never actually working with XML trees consuming large chunks of memory. Modern implementations like XMPP.js go further and use LTX—a lightweight parser built specifically for XMPP’s streaming model—rather than the browser’s DOM parser. The result: developers work with JSON-like objects anyway. The wire format becomes invisible to your application code.

XML brings three key advantages:

• Built-in extensibility with validation via XML Schemas
• Clean namespace management for XEPs: when the protocol needs to evolve, you can change the namespace of an extension, making versioning explicit and backward compatibility manageable
• 25+ years of mature tooling and battle-tested parsers

These matter when you’re building federated systems that need to evolve over time and need to stay compliant over time. The XMPP federation is a huge ecosystem of servers that can talk to each other, relying on different server implementations and are not always up to date. Still, the federation works, and we too often forget that this is a great achievement in itself.

Real performance bottlenecks in XMPP deployments come from elsewhere entirely: network latency, database optimization for roster and message storage, custom module performance, external components, or clustering and routing logic.

The myth persists because XML looks verbose when you read it. But visual verbosity has almost no correlation with parsing performance. Modern CPUs parse XML and JSON at nearly identical speeds for typical XMPP message sizes. Any difference vanishes in a real-world client.

Where the Real Complexity Lives

XMPP does have genuine complexity—but it’s not the wire format. It’s the protocol depth and the extensive XEP ecosystem with hundreds of extensions. That’s a real learning curve.

Consider XMPP when these factors matter to you:

• Federation across organizational boundaries
• Open standards and avoiding vendor lock-in
• Protocol stability that won’t break in three years
• Extensibility without forking the protocol

If those resonate, the wire format should be the least of your concerns.

We’ve been building XMPP systems for over 25 years. The XML performance question comes up often in early conversations. Every single time, we end up optimizing ejabberd configuration, clustering, architecture, client protocol usage, and databases instead.

Thinking about XMPP for your next project? Reach out during the design phase. We’ll help you avoid the actual bottlenecks.

The Smack developers are happy to announce the availability the first release candidate (RC) of Smack 4.5.0.

The upcoming Smack 4.5 release contains many bug fixes and improvements. Please consider testing this release candidate in your integration stages and report back any issues you may found. The more people are actively testing release candidates, the less issues will remain in the actual release.

Smack 4.5.0-rc1 is now available on Maven Central .

1 post - 1 participant

Read full topic

Signal improved its protocol to prepare encrypted messaging for the quantum era.

They call the improvement “Triple Ratchet” (or SPQR = Signal Post-Quantum Ratchet).

If history repeats itself, this could become the next open standard for secure messaging.

Signal (formerly Open Whisper Systems) created the Double Ratchet protocol in 2013–2014, introduced in TextSecure v2 in February 2014. They packaged it into the open source Signal Protocol. It became the mainstream standard for end-to-end encrypted messaging. XMPP adopted it (OMEMO, developed in 2015). Matrix adopted it (Olm/Megolm implements Double Ratchet concepts).

The problem is that current encryption methods could break when quantum computers get powerful enough, so Signal built Triple Ratchet to protect against that.

Most messaging companies are preparing for this but I noticed that WhatsApp has no public roadmap for the adoption of quantum resistance protocols. They use the Signal Protocol for encryption, so they may simply wait for the result of Signal’s work to adopt the new approach.

It is much heavier to implement, so I am wondering if Triple Ratchet follows the same path as Double Ratchet and gets widespread adoption.

If open protocols like XMPP and Matrix adopt it, it may be huge for European messaging independence.

What’s your take? Do you think quantum resistance will become a mandatory feature for end-to-end encrypted messaging platforms in the next couple of years?

Good news for anyone building messaging infrastructure in Europe: Denmark&aposs Council presidency is abandoning mandatory detection orders in the Child Sexual Abuse Material (CSAM) proposal for now. The proposal was nicknamed "Chat Control" because it was invasive, requiring platforms to scan all message content. To do that, it would have required bypassing end-to-end encryption, practically creating a surveillance infrastructure.

They gave up after Germany and other EU countries blocked the message scanning obligation. They abandoned plans to put the text to a vote in the Council of the European Union in October as they had hoped. Now, they propose to return to the previous status quo .

It&aposs a relief for companies working on open and standards-based infrastructure. As I&aposve already explained, mandatory scanning is technically impossible to enforce for federated protocols like XMPP and Matrix . Europe&aposs decentralized messaging ecosystem would have been threatened, and the law would have been ineffective at preventing illegal data exchange, as encryption can always be applied outside of the chat application.

I know this is the type of fight that is never really over, but still, it is nice to see that sometimes sanity can prevail.

The Erlang Solutions team has been creating webinars that share knowledge, spark ideas, and celebrate the BEAM community. Each one offers a chance to explore new tools, hear fresh perspectives, and learn from the people building scalable and reliable systems every day.

If you haven’t tuned in yet, here’s a look at some of our recent sessions, full of practical insights and new thinking shaping the future of the BEAM.

SAFE for Elixir: Strengthening Security for Elixir and Erlang

In SAFE for Elixir , Robert Fiko and Mohamed Ali Khechine from the SAFE team talk about what it really means to build secure software.

They introduce SAFE for Elixir, a tool created with researchers at Eötvös Loránd University , that helps developers spot and fix vulnerabilities before they cause problems. It’s an honest and practical session about weaving security into your development process and making it part of your everyday workflow.

Messaging in Regulated Markets: Compliance from Day One

Compliance isn’t the most exciting part of building software, but it’s one of the most important. It’s also easy to leave until the end, and that’s where the problems usually start.

In Messaging in Regulated Markets: Compliance from Day One , Piotr Nosek explores what happens when you treat compliance as part of the design process instead of a last-minute fix. He also looks at how MongooseIM helps teams meet tough standards like GDPR, HIPAA, and NHS, while still building modern messaging tools with encryption, notifications, and video calls.

Gleam’s Interoperability with Erlang and Elixir

Gleam’s Interoperability with Erlang and Elixir is a hands-on look at how this type-safe language fits into the BEAM family.

Raúl Chouza uses a live Tic-Tac-Toe demo to show how Gleam works seamlessly alongside Erlang and Elixir, mixing dependencies and even pulling in modules like Phoenix LiveView. It’s a relaxed and engaging session that shows how developers can experiment across languages and still enjoy all the reliability the BEAM has to offer.

What You May Not Know About with

Every Elixir developer has come across with , but not everyone has taken the time to see what it can really do. In What You May Not Know About with , Brian Underwood and Adilet Abylov take a closer look at one of Elixir’s most overlooked features.

They show how it can make code cleaner, easier to follow, and far more expressive when it comes to handling complex logic. The session walks through common mistakes, explores ways to manage pattern matching, and shares practical tips for better error handling, all delivered in a way that makes you want to jump back into your editor and try it out.

Women in Elixir

Women in Elixir is a celebration of the people driving change across the BEAM community. Lorena Mireles shares insights from the Women in BEAM survey and her own experience in the industry, offering a thoughtful look at progress, opportunities, and the power of representation.

She also highlights how mentorship, community events, and visibility can help more women thrive in tech and why inclusion benefits everyone.

Learning through our webinars

These webinars show what makes the BEAM community unique: a mix of curiosity, openness, and a constant drive to improve how we build and collaborate. They reflect the depth of knowledge across Erlang, Elixir, and Gleam, and the passion that keeps this ecosystem evolving.

You can check out these sessions and more on our webinars page .

The post ​​Expert Insights from Our Latest Webinars appeared first on Erlang Solutions .