Hello and welcome to the Thinking Elixir podcast where we cover the news of the community and learn from each other. My name is Mark Ericksen.

 And I'm David Bernheisel.

 Let's jump into the news. First up at Elixir Conf, Jose Valim in his keynote presentation, he talked about this project called Phoenix Sync. There's a GitHub repo in our previous episode. We talked about it and how on the repo it said, you know, warning, to-dos and unfinished code ahead. Well, the latest update is that that public repo has been archived. Don't really know anything about it yet. I've actually reached out to Jose, but I just haven't given him enough time to even respond. So we don't have any explanation like is this being just shut down? Is this was a bad idea or is this being transferred into a different project to make it more official? We don't know yet.

 He made it clear from the beginning, though, that it was definitely a proof of concept. We had no expectations up front. So no surprise. And I'm sure that whatever ideas are spawned from this are going to contribute to someone somewhere. We'll see what happens. And in case you didn't you don't recall what Phoenix Sync is. It's generally a way to sync front end changes through Phoenix channels directly to a Postgres database. So that was the general idea there.



 So pretty exciting in concepts, but don't know where that's going to go. We'll find out. All right. Next up, we have an update from Git Text, our chosen standard, you know, GNU based translation system. And Git Text has a big update that requires some changes this time around. And this is published in version 0.26 and includes a more efficient compilation strategy. So that's the whole reasoning behind this. Andre Alejo-Parti spearheaded this change along with other contributors, I'm sure. And here's a quote from the changelog. It says, "The reason for this change is that it removes compile time dependencies from modules that used to import a Git Text backend." And so in applications such as Phoenix applications where every view and every controller imports the Git Text backend, this change means a lot less compilation when you make translation changes. That's the reason for it all down. You know, I'm all for faster compilation. So the Git Text is one of those things that's just kind of peppered everywhere. So totally makes sense. Very good optimization. Very happy to see that. Actually reminds me a little bit of, speaking of internationalization, reminds me of a little bit of how XCLDR kind of works because you do a similar concept there. You configure CLDR to use your backend, you know, and you configure your backend with various, you know, configuration settings, plugins, you know, yada, yada. So Git Text is a little bit similar in that. I always felt like those two are very similar in nature. Kind of cool to see. Excited to see what comes of that, but just heads up that that does require you to change a little bit of code to take advantage of that. So when you're updating your dependencies, double check your Git Text.

 And next up, error tracking version 0.2.6 was released. This version adds a few key improvements. For a quick reminder of what error tracker project is, it's the Elixir-based built-in error tracker system that you can just bring into your application, add to your routes, and have like a Sentry-style error tracking and be able to mark things as handled and display inside your application. So in this latest update, there are a few key improvements that were given. Global error tracking disable flag. Error tracking can now be fully disabled for certain environments, maybe staging or maybe even production. I don't know. Like you decide where you want to turn it off. Hey, YOLO.



 An automatic resolved error pruning. Errors can now be automatically pruned after they have been resolved for some time. That's nice. Just help clean up the database because if it's being stored in your Postgres database, you want some auto cleanup.

 That's handy.



 Error ignore. Errors can now ignore particular errors based on their attributes and context. So we have a link to the repo where you can check that out. And yeah, I have yet to try and plug this into my app, but it is still on my list of something to check out.

 Yeah. Error ignore. I'm going to have to think about that one. Just clean up your errors, YOLO. Don't ignore them. I don't know. I know. There's something you can't, you just can't avoid.



 So much easier to just click a button than deploy a proper fix, I guess. All right. Hey, well, speaking of error tracker, there's another library called Tower. I was reminded by this because at the ElectraConf, they mimicuate, I think is the company behind it. One source of library called Tower that does a similar thing in a way to error tracker. Tower is a flexible error tracker for Elixir applications as well, but its goal is a little bit different. Whereas error tracker is about in-housing all that. Tower is more about providing an abstract API over it. So for example, if you're using Sentry or Honey Badger, you probably pepper Sentry or Honey Badger throughout your code base.



 Tower's goal, it seems to me that Tower will be the thing that is instead peppered in your code base, and you configure Tower to have the integration with your preferred service.



 And some of those don't really need to be services. They can just be email. They could be Slack because that's probably where people are getting most of their errors anyway, through Slack messages or something. But currently they support email and Slack and also Rollbar, but you can also imagine, and I'm sure they would appreciate contribution for other services like Sentry and Honey Badger. But that's the idea there. It seems pretty legit and excited to see where that goes.

 And next up, Jose highlighted some UX issues with an application interface on chatgpt. We have a link to his tweet or message on X. It's helpful to see the example to understand what it is, but this is the idea that's part of the chatgpt interface and it comes up and you're able to manage links. And what this is demonstrating is a common problem that happens in the situation where you have state being managed on the server and on the client. So it has a list of items and he hits delete, delete, delete on several items. And each delete request is being handled asynchronously, which means it goes off to the server, performs the delete, sends back the delete response of here's the new list of items after the delete. And then the second delete also being handled asynchronously at the same time. So then you'll see one item be removed from the UI and then like a race condition. The other response comes back and it's toggling on and off the different items as they're being caught in and out of deleted states. And so it's just kind of a little bit of a mess. We know Jose's talked some recently about the idea of state being, of just acknowledging that state needs to be managed on the server and the client, that we are actually building distributed systems just because the client is far away from our server. He said, "I was going to publish a video today showing optimistic updates with Live View, but everyone told me, no, there's an Apple announcement." So he's postponed that. We will certainly share that. But the idea is using Live View, how can we better handle this type of a scenario?

 Yeah. So I haven't seen that video, but that should be published today if everything's still on schedule. And for what it's worth, I think he could have done it over the Apple announcement because the Apple announcement was meh this year. It's like not much new.



 Yeah, I guess OpenAI is a little bit focused on Apple intelligence rather than good UIs at this point. We'll see.



 Oh, man. Okay. Well, next up, we have a new contribution showing an example of WebRTC in Elixir. So if you don't know what a WebRTC is, where it seems too big of a concept to kind of dive in and play with a little bit, well, then we got good news for you. So VoidTechMock maintains a repo of small scripts, one file kind of scripts that leverage Mix Install. So it's live book friendly, in other words, right? That allows you to kind of copy and paste this install script and test a thing out, test a library out. And the WebRTC library, Membrane, or X WebRTC in this case, sometimes if you don't know the domain well enough, it's hard to know where to start. And so this example was added to the Mix Install examples repo.



 And it looks like a fantastic introduction to how to WebRTC and how Elixir can work with that. So if you're curious about that, go check out that repo. Lots of other great examples in there, by the way. So fun to explore that repo. But yeah, WebRTC is in there now as well, which is what I consider WebRTC in this video processing stuff that Membrane is more known about.



 As kind of an unsung, you know, like I haven't called it a leg of the Elixir ecosystem, but



 it's getting there. I think it might be like a good leg of the Elixir ecosystem. You can't avoid video processing, you know?



 And Membrane is it seems to be the de facto library for that. That's hooking in with things like FFmpeg for the underlying processing of that stuff. So anyway, very excited about that. If you're interested in WebRTC, there's a good clean example now that's easily testable in a live book.

 And last up, just news from our general tech space. We noticed that Laravel has raised $57 million in a Series A partnership with Excel. I think that's how you say it.



 But so Laravel is a PHP based framework. Famously, Livewire is a project that was directly inspired by Live View and doesn't work the same way, meaning you can't proactively have state changes on the server push out to the client. So it's more limited, but it still helps to solve some of that problem of needing to define an interface like API transfer. You know, how do I package up into JSON? How do I create API endpoints to help solve all that still? But I think the craziest thing is just that. All right. So Laravel is a little bit unique, right? There's the Laravel PHP project and then the same person who's the creator and maintainer of that started a company.



 That's not sure exactly what it's called, but it's a Laravel company. And what do they have is Laravel cloud, which is their hosting platform. So this is, I think the valuation you're saying, you know, someone just is someone has to decide that this has value and it's an open source project. So how do you value that? I'm not sure. But I think the valuation is coming down on the hosting platform is and the prospect of that. And David, before we started recording, you said you pointed out that this is very much like Vercel.

 Yeah, it just reminded me a little bit of Vercel. So just just a little context of what I remember, at least, you know, I could I could be a little wrong here, but Vercel was a cloud hosting company and they they bought into Next.js. And Next.js is a JavaScript front end framework that allows you to construct a full application and Vercel really tune themselves to be able to deploy Next.js applications really easily.



 In this case, you know, Vercel was the hosting company and bought into Next.js. In this case, it seems that, you know, Laravel obviously started first here and then it's like also starting the cloud hosting company. So it's kind of going the other way.



 But hey, you know, you know, they've worked hard. I'm sure they've I'm sure they've earned it. This is this is now seemingly a trend. So I'm curious now if, you know, LiveView.cloud will be a thing. You know, I need to get on that. Maybe I can get fifty seven million dollars in other people's money. Yeah, totally kidding. Totally kidding.



 I'm not I don't know enough about Laravel's business, but I'm sure they're going to do just fine. So congrats to Laravel and all that contributed to that.



 May you see good, sweet success and hope that maybe there's an opportunity that we could work together at some point. Who knows?



 And that's it for the news.


 Today we're being joined by our special guest, Alistair Woodman. Alistair, welcome to the show. Hi, thanks for having me on. Well, I'm happy to have you here because you have some insight into the EEF, the Erlang Ecosystem Foundation, and efforts being made around where technology and government or governance and politics meet and sometimes clash and what that means for the elixir ecosystem and what we care about, what where we are invested, where our businesses live. And if our businesses touch government stuff at all, well, it's interesting to know that you guys have at least an eye on this and we would love to pick your brain looking forward to that. But before we get into all that, I'd love to hear more about you. Like where do you live and what kind of work are you doing?

 So I live in California, been there for about 35 years now. I left the UK where I was born over 40 years ago. I lived in Germany for about six years.



 My in-laws are all German and I'm in Germany at the moment and very happy being out, hanging out in my second home away from home.

 Nice. So.

 Do you speak German? Oh, fluently, yes. So I've been doing that all day today. This is my first go around in English.



 I'd love to learn a little bit about your history too. You know, like you're part of the EEF and you've been a board member for quite a while now. Like you obviously have some background in Erlang and Elixir. I'm curious of what your background is in.

 Well, so I have a sort of an interesting history with that. So I worked in high tech in the Valley for many years. The last job that I formerly had in the Valley was working for Cisco Systems.



 And the last project that I was working on, I had to go figure out how to do network management software with insufficient resources. So the budget that I was working on didn't stretch to doing the network management part of things. So I started looking for external code and that's where I ran into the company, TALF.



 And so I don't know if you know about TALF as a company. They are a Swedish, well, were a Swedish company.



 They've now been acquired by Cisco.



 That happened after I left and is not actually something that I was involved with directly, although I was aware that the conversations were going on. And there were serial entrepreneurs in Sweden that had done several startups before based on Erlang. So I sort of enjoyed hanging out with them and talking about their technology. And first of all, I thought they were like really smart engineers and they were really smart engineers. But I realized that one of the reasons that they were actually capable of getting the job done with less resources than my engineering team were quoting me was because they were using better technology than my engineers were. So that's how I started to hang out with folks in the Erlang community.



 So when I left Cisco, I could have retired and played golf all the time, but that's not my shtick.



 So I don't like hanging around with people in golf clubs.



 So I prefer to hang out with nerds. So I ended up associating myself with the Erlang community.



 At some point, it became apparent that we didn't have a foundation. And like almost everybody else had a foundation, the Haskell guys had one, the Python guys had one, the Eclipse guys exist for looking after Java. So because of that piece of history, I decided to volunteer and get involved with the board. And because I'm local in California, I tend to end up filing a lot of the paperwork for the organization because we're a Californian not-for-profit. And of course, some people will look at that and say, you should be going to the golf club more often.



 I did not realize that the Erlang ecosystem foundation was registered in California. That's interesting. And I'm guessing that's just because that's where you're based, right?

 Correct. But if you're not-for-profit, it doesn't really matter where you're based. I mean, a lot of companies in the US are all Delaware based because of Delaware Taxation laws. But if you're a not-for-profit, it doesn't really matter. And so not-for-profit is typically registered all around the 50 states of the US. And it doesn't really matter. The not-for-profit in principle belongs to the state of California.



 It's the ultimate owner, but we just need to file the paperwork.

 So I think you said it, but you've been with the EES since inception, right?

 Correct. Yes. And before that, there was an industrial users group that was an attempt previously to have an organization. So anyway, we founded the EEF and we view ourselves as trying to help all of the Beam language community stuff. So we're not-although we have the word "Burling" in the title, we view ourselves as being working for all the Beam community stuff. And that will be relevant, I think, for today's conversation because the regulatory impact of everything that we're going to be discussing today will apply to all the languages using the Beam. I know you guys are very focused on the Elixir space and I'm very excited with what's happening there, but we need to worry about everything, including the C code that sits underneath. So down in the basement, two levels down, guys.



 We're going to talk about how the Erlang VM is going to be rewritten in Zig, right? Or no, is it Rust?

 Rust, yeah. It's got to be Rust.

 Yeah.



 I'm just kidding.

 Exactly. We can have that detail right away.



 I think I will go to a golf club if that's the result.



 So I'm really interested in getting your perspective on this because being based in the US myself, working for US companies, I have-the level of exposure I have to most things is, you know, there's levels of certification like SOC compliance or things like that where there's some regulatory oversight or some auditors say, you know, I have to develop this set of procedures that I say I'm going to follow and someone comes in audits and says, yes, we are asserting that you are actually following the procedures you say you're going to follow or that you handle them correctly as exceptions come up. That's the level of exposure I have. There's another level of exposure when you're talking about maybe providing as a vendor, providing a service to a government agency. That's a different thing too. So where is it that your focus is in coming in on this whole topic?

 Yeah, so that's an interesting sort of discourse. I am also involved with other open source projects outside of the functional programming space. And I first sort of stumbled into the issues that we're going to crop up here through my contacts in Europe. So although I'm based in California, I do hang out a lot with civil society folks in Europe. And I first ran into what was happening here related to software quality through the EU Cyber Resiliency Act, which was the first time I became aware of what was happening. Subsequently, I think it's fair to say there are two areas which are driving stuff, both the US standards based stuff as well as what's happening in the EU. So I think we'll have to cover both of those areas as we talk. To get back to your question, Mark, there about it is I think a lot of the stuff, the standards in the US are ultimately driven out of NIST, the guys who are responsible for timing, weights and measures, unit measurement stuff. They do a lot of basic work. And if you've ever dealt with crypto stuff, and FIPS compliance and any of those other types of things, a lot of that stuff has originally came out of the NIST, the government agency. So some of the different regulatory departments in the US apply those things. But I think a lot of the basic research and intellectual thinking about what needs to go into standards and compliance stuff in the US comes from NIST.

 That's a lot of regulatory considerations here. And so we're talking about two distinctly different kinds of government systems. We've got the EU and we've got the US. Now I know this is very much so the election season in the US. So maybe we don't focus too much on the US stuff right now, because the two parties seem to be very different on how to deal with regulation. But more consistently in the EU, how would you see the attitude changing? I'm thinking about all of the recent exploits, all of the recent issues in technology. I'm remembering a conversation a while ago about software engineering needing to have certificates so they can be graded along the same lines of civil engineers.



 A bit of responsibility for the work that they're doing instead of just under the umbrella of their corporation that they're working for.



 I'm thinking about the FTC in the US.



 There's so many things in here that we could really unpack. And then lastly, the regulations that maybe most folks can sympathize with is that the EU forced Apple's hand to have the USBC port and standardized around the USPC port. To get rid of electronic waste, that's the intent anyway. So I know that there's a lot more regulation in the EU. So I'm sure that's what's driving some of this conversation. So maybe we focus on that, because this election year in the US is just going to completely change the conversation here locally, I guess. But what does that mean for open source?

 So actually, interestingly enough, I don't think I would agree with you that the election in the US is going to change things substantially. Because if we look at the history of software as mostly being along the lines that software companies have said, we're adults, leave it to us, this is a private commercial agreement.



 Companies have been doing business to business. Software selling to one another and everything was dealt with with private contracts.



 Then, of course, we as consumers, you'd sign up to a 96 page user agreement that you would never read. And you knew you basically didn't have any rights anyway, because whatever. Right. And that's been the way that the market has been allowed to run for at least the last 50 years in terms of the way that both closed as well as open source software sort of tends to work. The interesting thing that sort of happened is that that I think the regulators on both sides of the Atlantic have decided that that's not good enough. Right. So they have slightly different postures and I'll explain that in a bit. But I mean, if you look at what's happened from a headlines perspective, right, we've had the XZ exploits. It's probably safe to say that that was it was certainly well planned exploits, probably state definitely more than one person involved in that particular process.



 That's something that really worries people in terms of those types of threats to infrastructure. Then we've had other things which are just not quite as good as they ought to be engineering stuff. So the log for J, you know, zero day issues, heart bleed that worry people at the systemic level. But if those things don't get fixed and don't get fixed quickly, they could be exploited by bad actors. And of course, the bad actors spend a lot more time paying attention to blog posts than the good guys do. Right. So they good guys only sort of find out about things a little bit later on. And everything related to ransomware attacks, as well as the crowd strike topic that we had recently. Now, admittedly, you look at that and go and say, OK, well, that was just a self-inflicted wound. Right. And yes, it was. Right. But the politicians look at it and go, oh, what would that look like if it were really had been malicious? And somebody decided to take things down. Right. And of course, you've got the sort of favorite thing that everybody cares about if they do talk about this is like baby cameras and other types of things where there have already been cases where data and picture of children or babies get leaked back to random sources and you didn't know that your family was being filmed,



 et cetera, et cetera. And that is a very powerful brew of discontent that consumers and people who live in the security apparatus all look at that and go, you're not doing a good enough job.

 Yeah.

 That means the software industry.

 Right. And so we can think of this like over time with other industries long time ago, mine safety, you know, corporations just admittedly weren't really protecting their mine workers. So they had to put in more laws to protect them. Same with car seat belts. The data was showing that there were too many fatalities happening, you know, because of just people not taking care of themselves, but also the ones that could do something about it. The car manufacturers, you know, were the ones that could protect people. There's so much. And then maybe more, maybe more funny to think about it, but like New York City had the, the size of the soda that you could purchase.



 You couldn't do the 64 ounces ones anymore. Like you had to really control people's consumption of like sugary sodas.



 So you know, and on one hand, you know, you can instantly have the image of like, you know, don't tread on me kind of like feelings on laws in that case. But overall, based on the data of the market, you can see that like things do get better with those kinds of laws for the general, you know, population. And I don't know what that looks like for software. So I'm curious of where you think this is going or what is the EEF doing, you know, with this, what's the market doing when it comes to like regulating software? And I'm going to throw one word out there and then I'll shut up for the US at least. Does this have anything to do with the Chevron act?



 Well, actually that I do think that the Chevron, that Chevron might actually loosen up, make it more difficult for US agencies to end up regulating because the clue will be a push for that. But and I think this is arguably one of the reasons why in the US, I think the risk the regulatory response and this is why, you know, I've been talking to Brian at Dockyard is that the way that they will deal with the problem in the US is through government procurement.



 So they won't necessarily try to force the same set of standards on private individual contracts. But the federal government will start to say we will only buy stuff that meets certain quality standards and they can do that without losing, I think, to the Chevron act because they're their own purchaser. And I think you'll then find the industry will start to go, we want the same quality that those guys are actually looking for. So the folks who might be left out to dry the consumers in this particular, we don't have a big enough lawyer to deal with that. But I think both the federal government as well as business interests will want to tighten up software quality. The reason why it's more interesting in what's happening in Europe is that the Europeans tend to come up this the other way round and say we're there to protect consumer interests up to an including, you know, just, you know, going after a lot of business interests and saying, you know, it's in it's not good enough for you to be, you know, essentially externalizing the cost of different plug interface things and you, you know, expect the consumer to own 15 different cables. And they go, we're going to protect the interest interests of the consumer. So I live in an interesting situation at the moment where I'm trying to figure out what we will as a community will need to do to both solve the requirements for the US regulatory market while simultaneously paying attention to what the Europeans are going to do when they're not necessarily the same, but they will cause us mostly to have to do the same set of things.

 Your statement there is it's like it's forward looking, right? There isn't a something right now that they're saying you have to comply to this. I'm just curious as to what do you see? How can this type of mindset impact software development? Like what does this actually mean for me as a day to day developer or a company, you know, the owner of a company who's trying to provide a software solution? What kinds of impacts would this have?

 So initially you're right. Nothing this year. I do think that if you're actually selling to the government, the US government, for instance, you will have to start answering questions about what your code looks like and responding to things over probably as of next year. And in fact, some of the some of people who are selling into certain sensitive areas already need to provide that level of paperwork to the government. They are clearly the US government is clearly upping the ante as we speak related to many of the things that they're doing and saying as far as code quality is concerned. And you did sort of raise the David, you raised the observation that, you know, maybe as an output of the election, there could be different paths for this. But that's where I tend to be a little bit skeptical in the sense that there's a major concern amongst the US agencies related to state sponsored terrorism. Right. And I don't really think that the outcome of the election is going to influence that opinion one way or another.

 Yeah, I would agree there.

 Alistair, one of the things that I think of when I when I'm thinking about this, this topic is I'm aware that with some government contracts and things like that, they have like a pre-approved list of languages that say we already, you know, we've already had this validated, we already understand what this is, and this is on our approved list or this is maybe this other one that hasn't been vetted yet by our agency. And it's not on our approved list. If we are providing a service as an elixir solution, how does elixir fit into this idea of what's approved or not approved or eligible or I don't know, how does that work?

 Yeah, so that I think is a very interesting question. Right. The US government has been promulgating and the White House has come out with statements related to only use memory safe languages.



 Of course, at one level, when we look at the beam, it does behave very sensibly as far as memory safe languages are concerned. It has garbage collection. When things behave badly, the process, you know, let it crash, causes things to be taken down and memory cleanup occurs. And that's highly reliable. Right. And we, one of the reasons that everybody in the community is so excited by the beam is because we have that super secret feature. The problem to a certain extent is that if you look underneath the beam, right, the lower level of the code is actually written in C and C++. So if you were to strictly take the reading of things at the moment, you could assume that prejudiced entities inside of government institutions could say, well, underneath you've got C, C++, that's all bad, right? Elixir, therefore bad too. The sort of get out of jail answer to that is going to be that, well, Java's got the same thing. And most of the other languages that you think of as being OK will have some stuff underneath that still C and C++. And one of the reasons that the federal government and others are beating the drum about you need to rewrite everything in Rust now is to try and solve that problem. Right. And like any of the hype cycles that I've been through in my professional career, right, we're probably at the close to the top of peak Rust is called, you know, time, right? Because everybody's going to go, oh, great, we're just going to go rewrite all that intellectual property in Rust. And A, I don't think we have enough Rust engineers. B, we can't do all the regression and everything else. I don't think it's a practical solution.



 So what I do think is going to happen is that we'll have to start having conversations about accent stuff. And there is a lot of work that's been done at the moment by the C, C++ community guys to make sure that you've got the right compiler flags on. There's a good document from the open SSF about what to do, you know, to make sure your C and C++ stuff is not bad. And I think we'll end up with AI and other types of things looking for zero day problems in, you know, small amounts of C, C++ stuff. But this means that any time we start wanting to add features all the way down in the basement, people are going to go, why did you do that? Right. So we're going to end up with a situation where we will have to have QA testing and a whole bunch of other types of things and possibly even in a couple of years justify why we're doing that in C, C++, as opposed to not making feature enhancements in Rust, say. Right.

 So we are. So you're telling me we're going to rewrite in Rust.



 I didn't. I don't think so. But I think that people are going to look very hard about what people do do in C and C++.

 I want to have a better understanding of like who's doing this negotiation with whom, you know, and because of what act. I have a good picture of like what the problems are. I just don't know why they're problems right now. Can you help me understand like why, why and who's involved in this?

 What I think you'll see is that's lobbying. Right. So you will see everybody and their dog come out of the woodwork and say, I can't afford to rewrite my code next week in Rust. Right. And everybody will whine about special exemptions. And this has been standard procedure in the US government. I mean, I remember back to a day when I was at Cisco and the federal government said, you need to have IPv6 on your boxes. Right. And this was back in like 2001.



 And then vendors would come out and say, OK, well, we can't get it done this year. And then the federal government would go, OK, you're exempt for a while. So basically this process goes on for a while with the government wagging its finger at you and saying, you need to do better. And everybody going, we'll do better. Right. And and then when other people actually show up with better and you realize that you're in the bottom of the pack,



 then at some point you do actually need to figure out how to make it happen. I think everybody recognizes we can't just stop and take a 10 year pause to or even a three year pause to rewrite everything in Rust and then get back to doing what we were doing before. That's not going to happen. Right. The question is, can you justify that your stuff is good works and are you competent at making changes and doing modification? That's where they're going to start looking at what's happening.

 So is that more around the like the processes and procedures around writing the code? So like that you are.

 And in fact, I think there will be. So one of the clear things that both the Europeans as well as the US have registered, recognize is that they want to be able to look at the complete supply chain of where everything came from. Right. And this again goes back to their experience of finding out that who knew that everybody was using log4j all the way through their applications and it didn't look like it would be a major problem. And then oh dear, right. Everybody's using this stuff. Right. They really now will want you to be able to, if you're a vendor, be able to list everything that you all the code you're using, not just everything in Elixir and the Beam, but everything all the way down to the bottom of the Linux or FreeBSD stack or whatever you are, the embedded system that you're working on and be able to turn up and say, this is my complete supply chain of software.

 There's an incredible amount of layers involved there. Right. So I did today. Today I learned, by the way, I didn't realize that the US side was actually instituting some of these or calling for this kind of code quality as well. You know, I think the cyber resiliency act over in the EU is what triggered, you know, this conversation at all. So maybe starting in the EU. But, you know, we have the EGF is one organization that organizes and that there's a lot of good effort that's happening within the organization. But it's really like, oh, when I think about who's developing OTP, well, it's Ericsson. When I think about who's developing, you know, Elixir, it's a long list of contributors maintained by José. And then there's Gleam. There's all these other ones. Right. You're talking about Linux. So there's there's a Linux foundation. Like there's so many layers there and either of these kinds of governing bodies, the US or the EU, like do you imagine there to be a certification process at this point? Like I'm imagining SOC to compliancy kind of paperwork. Right. I've never heard anyone say that they loved going through that process. And so like, is there going to be a similar kind of like process there to, you know, publish, like approve basically that the software that and maybe by extension, the engineers, I'm not sure how we get personnel involved in here, but like at least the software that it's approved for use, that it is safe to use. And and when we add dependencies,



 you know, like we go through that thing again, you know, like how does that really affect the I don't know what that process would look like. Do you anticipate that really changing?

 There's a lot of effort being putting into those types of things. The good news is I think a lot of it will also be done through open source and visibly in public. Right. One of the things that was probably true about software last century is that the old argument about, you know, buy software from IBM or Cisco or whatever it is, because it was relatively safe and it was closed source and we manage the end to end processes of these things. Nobody's trying to put that genie back in the bottle. I think what is going to happen is that this sort of the free for all that we did have in the open source space where everybody just, you know, dumped stuff out there and then people take whatever they want or for whatever they want from somewhere and it's going to be good enough is also not going to be acceptable. And so you'll see there's a lot of things going on at the moment related to software bill of materials, to repudiation and statements around about packaging and other types of things where you as a package producer will make statements and say, we did this, we tested it. And then you might say, oh, actually, we found a bug, right? And then you would withdraw your statement about the fact that you think that it's safe to use. And there's going to be a whole bunch of essentially electronic stuff that you will have to go manage and pay attention to if you're in the DevOps space or even in the continuous integration build space that does not exist at the moment. But this has been very actively developed as we speak.



 Linux Foundation, the open SSF, and other folks, heavily encouraged by major players and the federal government and what's happening in Europe as well are going to be very active in this space. So tools will turn up. And guess what? Software devs will be expected to know how to use them and use them clearly. One of the comments that I do think that we as a community need to be very clear of, we don't want to be developing our own stuff inside the Beam environment. We need to be using a lot of these external tools in whatever environment they turn up in. Because the last thing that we want to be doing from a community perspective, is we're already claiming that we're special with the Beam, right? The last thing we would want to do is build our own verification tools inside of that environment, because then you have to explain to folks who are not on our side of the fence, why you're following particular guidelines, you actually want this to all flow through whatever the Linux Foundation, the open SSF end up doing. And following exactly their tool chains and everything else, we're going to have to connect the outside of our biology to what's happening in that space so that we can then turn up and show regulators here we do the same thing. You can check out Git history over here, you can look at all this, it's going to be understandable by people who are not experts in Elixir or Erlang.

 That makes sense. You have these larger bodies that are working more directly and closely with regulators or other government organizations and establishing this is the pattern, this is the set of tools, this is whatever it is that we've outlined and it gets the big checkmark, the big OK. And then if we're doing something exceptional, then it's all about, well, you have to really justify this and this is going to take a whole lot more investigating to understand why you're doing it this other way. So what that sounds like to me, please correct me if I'm wrong, it sounds like one of the things that you are really focused on is the awareness of what's going on this climate. And how does this impact Erlang and the Beam and Elixir and how can we best align ourselves so that this doesn't become a roadblock?

 Is that fair? That's a very fair assessment. I've been spending the last at least six months doing outreach to so we have become a member of the Linux Foundation. We have become a member of the OpenSSF. I'm going to sign up to the Eclipse Foundation and FreeBSD Foundation. We're going to be joining lots of other different entities because to a certain extent, we will have to end up lobbying and working with these folks. And we have common interests. And I see the primary role of the EEF to be working and providing that sort of backstop whilst many people in the community. And I am a member of the community because I think that the the exceptionality of what we have is where I would want to be making my money and spending my time as a developer. But we also need to be talking. We can't afford to be exceptional in this particular space. Right. And we have to be working with everybody else and figure out what's going on. So I do view that as a very important job that we're engaged on with the EEF. And so essentially, most of the folks in the community don't really have to worry about this from a day job perspective. You will have to follow. I will come and point out and maybe I'm going to be talking to you guys once every three months is like, you know, you have the latest talk with the news section about all these cool things. I'm going to provide the list of, oh, by the way, there's another homework assignment. You need to go do this. Right. Whatever it is. Right. I'm going to be Debbie Downer for the next couple of years telling you guys that you need to pay attention to stuff because it's coming.

 I am imagining the FTC for the Internet service providers in the U.S. recently introduced this like kind of nutrition facts of Internet plans. And I've seen it on a one I periodically check to see if there's fiber in my area. So I see I see if there's I see this nutritional facts kind of label like it's as if it's food. Right. I'm kind of imagining like that at some point there's going to there would be some kind of nutritional facts of a software package, you know, open source thing and close source anything. A nutritional facts of like it went through this, it went through this, it is automatically updating, it complies with this, you know, that kind of stuff. And then when you go to the gas pumps here, there's usually a sticker that says the last time this gas pump was calibrated was no joke. The last one I actually looked at was eight years ago. So who knows what kind of gas I'm getting out of that. But like there's some timestamp of like the last time this thing was audited or the last time a security incident happened with this this kind of thing. So that way developers can know when to update or when it's necessary. Anyway, I'm curious of what that would look like. Is that likely, you know, is that is that something that's going to absolutely absolutely.

 So the so I don't know if you follow VC is already right as a does that term about mean anything to you.

 C.V.E.

 Yeah, right. Right.

 Right. Yeah. Yeah.

 So so yes, another moment, they're mostly idle curiosity things, I think. Right. The cognizante pays some attention to them. Right. But I think it's going to be the case that pretty soon people will be coming around and going, hang on, why haven't you removed that piece of software? Why are you paying attention to these types of things? Right. So the tolerance for people being lazy and assuming that it's not going to be a problem is is not going to be, you know, put up with for many more years.

 Yeah. Well, let's let's wrap it up. I think this has been a truckload of information for a lot of folks that are unaware of the efforts that are happening across across regulatory agencies, you know, like in the EU and the cybersecurity infrastructure agency in the US, the SISA.

 Yeah.



 You already kind of outlines, you know, all that EEF is has done. So like that's that's kind of looking forward to, you know, we're kind of awaiting and negotiating, I guess, what those standards will will be. And we'll work with those other organizations. Linux Foundation opens SSF and et cetera. I'm curious to see what comes next. So we'll keep in touch. And we'll. Yeah. Well, we'll have a we'll have we'll have the it's not boring. It's necessary. It's we'll have the section of our news that talks about the the software nutritional labels, you know, that that that will need to start publishing. You know, I'm a little flabbergasted actually. I'm just like I'm so amazed of all the all the things that we talked about. It's so eye opening of all the effort that so many folks are actually going through right now that you just don't realize, you know, like so many folks are just happy to open up a blog post of how and build a blog in five minutes kind of thing and not realize all of the things that go underneath that. Personally, I'm curious of who is going to be deemed experts, you know, in the U.S. at least because that's where I live. And in the EU, it seems it seems to be, you know, like more more like the government is going to appoint and figure out who the experts are. But it's going to be top down kind of thing, whereas in the U.S. has typically been a fair mixture, but mostly feeling like it's market driven. And I feel like there are tides, tides of change coming there. I don't know what that's going to where that's going to land. So I'm curious of where that's going to be. But in any case, you know, we would have to work with whomever that is so we can fill out our software nutritional labels.



 Exactly. I think of this startup culture, right? Just one of the benefits of U.S. regulation in many different aspects, like how we handle bankruptcy, everything like all of these things. It encourages people to be able to start new companies. That is one of the strengths that we have as a nation and a culture. And I do wonder how this culture shift might impact that. And that's not clear to me yet. And I don't know where that's going to land. But I am very interested to see what that means. Like if I am I able to start a new company or do I have to get certifications to be able to offer a company to end consumers to offer a product? I don't know. The other thing, just when we're talking about rust and stuff, it reminded me I was aware of some recent Linux summit meetings that they had. And they were talking about rust being involved more in the kernel. And it's only being involved in certain parts of the kernel right now. But they're talking about like a lot of the technical challenges of now I have a whole bunch of code in C and now I have some code in rust. And part of the culture of the Linux kernel is if I make a breaking change that breaks something over here, it's my responsibility to fix it everywhere. Now I'm I'm a C developer and I have to learn rust. You're telling me I'm not going to do that. I'm doing this in my free time. You know, it's like there's just a lot of practical challenges that are being talked about. There aren't any good solutions yet. So I guess where I come down on all this is, Alistair, I am really grateful that the EEF is thinking about this, keeping an eye on this and helping us to understand in the election community. How does this impact me? How does this impact my ability to be a developer, to to provide a service to a client? Maybe I'm a contractor, maybe if I want to offer a startup and be a company, if I want to work with the government, what does this mean? So I am really grateful that you guys are thinking about this and that it's on your radar and all the steps that you said you've already joined the Linux Foundation, the OpenSSF. You will be joining the Eclipse Foundation. It's like, wow, thank you.

 Yeah, well, that's that's what bureaucracy is for, to a certain extent,



 is to keep that type of pain away from other folks. But yeah, it seems to be very necessary at the moment and I'm happy to do it. So I do believe that if we don't figure this out, we'll be in a very bad space. The good news is, I think that because of the way the language works and the way the beam is organized, we can lead other languages in terms of, you know, execution as far as this is concerned. But we have to move. We can't just sit there and go, oh, it's OK, we're fine, right? Because it's not going to be OK and it will not be fine. So we need to get with the program.

 I think one of the challenges that I see is if you wait for someone else to take the lead, it's going to be maybe talking about programming languages, right? They might say, yes, we're going to do something, make this decision. And that just handicaps an ability or feature that we have in the beam by a decision that they made. Right. Like they're just not thinking about what we can do in the beam. And we don't want that to be a limitation. Correct.

 The other danger that I think we face is that if you look, for instance, at Java and the maybe folks here that would say, oh, OK, but we're better than Java. The point is that they're too big to fail and we aren't. Right. So somebody's going to make sure that Java doesn't fail this test. Right. And they apply the appropriate amount of resources. But the institutions don't care whether we're not that big, that we're too big to fail. So we need to make sure we don't fail ourselves as a community.



 And we need to stay ahead of, you know, Java by our own ingenuity and skills. And we need to turn up because we're not going to get bailed out by anybody.

 That's amazing. And I know that the EEF is a relatively small organization. So how can, you know, all of our listeners, all all the elixir folks out there are laying beam, you know, beam folks. How can we help? How can we contribute?



 Most of you don't really need to contribute to start with because at some point we need to get a whole bunch of stuff done and then you need to start using it. But we could use folks who've got security backgrounds, folks who are good at software, bill of materials, skill sets in that area. And we are leading this from a technology perspective in the security working group. So you want to reach out to me directly if you're interested. I'm on the EEF Slack. The security working group is available to folks who are on the EEF Slack. So come along and join. And again, we don't need everybody to show up to start with because we just need folks who've got the requisite background in some of these areas to be able to help. And then at some point, everybody's going to have to go through boot camp to learn how to use all these new tools. Yeah, not unless you don't need to do boot camp this year, guys.



 So in the meantime, then maybe if you're not, you know, if you don't feel equipped for that, then, you know, dear listeners, you would be able to join the EEF and financially contribute to the ecosystem, you know, financials, at least to be able to find and resource these kinds of these kinds of efforts.



 Side note, I've actually done the bill of materials kind of stuff back in my Stripe days, so I actually I actually know what you're talking about. It's crazy. OK, so yeah.



 Well,



 thank you so much, Alistair, for coming and educating us, reminding us, you know, the importance of the EEF. It's easy to forget the bureaucracy, but it's much needed, you know, to get things done and to get things done well. And I'm looking forward to what our software nutritional labels are going to look like and what kinds and the ways that we can kind of lead the conversation to.



 And you know what? I'm going to put it on my bingo card, you know, in the next 10 years, Erlang VM rewrite and rust and we'll see what we'll see if it happens. Just just kidding.

 Well, thank you, Alistair, for taking the time to talk with us and get us caught up and just have general awareness of what's going on and the things that are concerning the EEF and how that may or may not impact us in the future. And we look forward to having future conversations with you to help us stay on top of that. In the meantime, you already mentioned some of the ways people get in contact with you. We'll have links to those in the show notes. But unfortunately, that's all the time we have for today. Thank you for listening. We hope you'll join us next time on Thinking Alistair.