Good afternoon and welcome to today's Energy Seminar. I'm really excited about today. I think this is a great finale for our fall quarter. Today we have with us two of the main drivers of form energy, which has come up in several previous seminars this quarter from the regulators to the competitors to the complementors. So I'm really excited about this. We have here with us Eddie Baldwin, who is a Harvard undergrad in chemistry and physics, but also an EIPER joint MBA program alumni from Stanford, who has been with form since 2019, I believe, 2020. I think your biosystem. No, sorry. And then on video from Somerville Mass, working hard at headquarters, we have Scott Berger, who is an undergrad from WashU, but also has a master's degree in a PhD in engineering systems from MIT, where we've actually had several previous seminar speakers. I won't go into all that. And they are doing this exciting work at form energy, one of the hottest clean tech startups around town. So Annie, take it away. Thank you. It is a real honor to be here. As you mentioned, I went to Stanford. I just graduated about two years ago. And I went to a lot of these energy seminars. So it's really special to be here and be with you all today. We will just do a brief round of intros. So I lead battery product management here at form, which basically means that I work closely with folks like Scott and everyone else on our commercial analytics team on really understanding what the value and opportunity is for multi-day storage, how utilities think about it, what is it that they really need, and then with our technology teams making sure that we're actually building the right battery that unlocks that value. So I work at the intersection of both of those worlds. And I will let Scott introduce himself. Recording in progress. Well, so it's great to be here. I don't think that MIT has invited us to do one of these talks. So I think Stanford is kind of leading right now. So it is really great to be here. Appreciate it. I have a whole stick about what analytics is at form energy later. So I won't dig into it too much. But we're really closely with great people like Annie to understand the value of our products. Great. Well, we'd love just to share with you guys a little bit about form, what we're up to here, how we see the market opportunity. And as Scott mentioned, he'll kind of share a little bit more on the analytics side, how we go about modeling future grids. So for those of you who don't know about form, we are a company building a new class of storage assets, which we call multi-day storage. We've been at it since about 2017. Now we're about 170 folks. We're based out of both Somerville. That's where we do a lot of the cell development in R&D and engineering. And then we also have a big team out of Berkeley. That's where I work out of, where we do the product and systems development as well. We also have a manufacturing facility out in Pittsburgh. So that's where we are today. I expect if we come back here in a year, we will have grown substantially since then. So we just announced this year we raised our Series D. So now we've raised it just close to $400 million from folks who really understand kind of what it takes to build a totally new class of storage asset and really have this kind of long-term view about how to invest and how to build new, reliable assets for the grid. And just for some fun folks, so that photo up there at the top, that's from our 30-daying asset. That's where we were kind of jumping, where we got to be together after being apart from the pandemic. And then up here in the upper right is one of our full-scale cells. I'll kind of talk to you guys a little bit about what actually is in a cell and what it does. But there's just kind of a little bit of a flavor of being both kind of building a new storage asset that really builds a new grid, but also kind of building new chemistry that enables that. So when we think kind of broadly about why form started and what is the problem space that we're really trying to solve, simply it's, how do we replace the opportunity of what fossil fuel plants do today? And that even in the US alone, it's close to a terawatt of opportunity. So this particular figure on the left shows what we're projecting out, looking out through 2050 of what future grids really look like. And you'll see that there's a huge expected growth and renewables, at least a 4x growth between now and 2050. Huge growth also of capacity as well, meaning kind of the electrification demand. But there's still a lot of existing kind of legacy fossil fuel assets that kind of remain on the grid. And this is kind of our problem space of what does it really take for us to really retire that, both for coal and then natural gas. And if you think about why is it that we still expect to have some coal and natural gas on the grid, it's really a reliability problem. So you guys might have talked about this in your energy seminar, but you might hear utilities a lot talking about how do I build an affordable, clean and reliable grid. So when you think about reliability, it's really making sure that you're delivering electricity 365 days a year, but also across all these different types of weather events that could happen on the grid. So we're just showing you a sample of how utilities really think about this and some of the reliability challenges that they see. So one, and this is on the upper left hand side for the Pacific Northwest, maybe it's very hydro loaded and maybe you'll have these multi-day events where you have low hydro generation and you need a new kind of low cost energy to ride through those multi-day events. Some of you may have been familiar with the polar vortex that happened earlier this year where you have kind of the confluence of bad factors happening where you'll have low wind generation, you'll have gas assets are not operating and then you'll just have a big problem where you just cannot meet energy demand or you'll have very, very high electricity prices. So utilities even today are really thinking about how do we solve these types of problems, which today mostly gas solves today, but we wanna do this in a firm, clean, reliable way in the future. So if you think about the design space and this is actually one of my favorite stories about form is we weren't so much pick a technology and then find a problem that we wanted to solve, but we did it the other way around, which is if you wanna solve that reliability challenge, what is the best way or what are the types of kind of requirements on a storage basis that really solve that reliability space? So we and Scott will speak to this in much more detail, but when you model out what future grids look like with high renewable penetration, you want a new class of storage asset that's at least 10 times longer in duration and at least a 10th the cost, installed cost of lithium ion to really replace the generation of what we see for fossil fuel assets today. So on the Y axis, you'll see this is kind of an installed cost. Expect, you know, lithium ion today installed cost. So that's all in, not just the hardware cost, but you know, turnkey, everything installed cost to utility is around 300 bucks a kilowatt hour, probably bottoms out at 100 bucks a kilowatt hour on like a fundamental spaces. But if you wanna build a new kind of fundamental different type of storage asset that lasts for multiple days, so lasts for 100 hours, it has to be very, very low cost. So more on the order of about $10 a kilowatt hour. So this is kind of the design space for form is has to last for about 100 hours, has to be on the order of 10 to 30 bucks a kilowatt hour. And this is really kind of the opportunities space that we're solving within. So when form started, we kind of looked all across the possible design space. So what is it that, what are the different types of electrochemical couples that you could look at that could really get you to that very low cost? And if you look at a graph like this, there's many existing technologies today. Like I mentioned, if you were to do lithium ion just on a chemical cost basis, a dollar per kilowatt hour, you're around 60 bucks a kilowatt hour. But iron is actually been around for quite a while since like the 1970s. This technology has really been around and has the fundamentals about being a very, very cheap technology that can get you to very low cost. So it's different about form and I'll talk about this in a little bit is we can access a form of iron that's very different and kind of readily accessible from the steel supply chain today, which allows us to really get to very, very low costs on the order of a dollar per kilowatt hour. So when you think about what does an iron air battery do? How does it work? You can think about it as a reversible rest or an air breathing battery. So on discharge, the battery breeze in air. So you take your oxygen from the air, one of the cathodes or the catalyst in the cathode will react with the oxygen to form hydroxide ions and then you'll convert that iron to iron oxide. And then on charge, you're gonna reverse that process. So the battery will kind of breathe out oxygen, you'll return iron back to its metallic form and then you'll breathe out oxygen and that process repeats for thousands and thousands of cycles. So this is kind of the fundamentals of if you were to pick a very durable low cost scalable solution, iron air actually fits a lot of those boxes when you wanna kind of check, how would I actually wanna do this really well? So I spoke to this a little bit, but on an installed cost basis, we can really get to an installed cost about the 10th that of lithium ion. Safety is a big factor, right? So not only is iron kind of one of the most globally available safe molecules in the world, but actually on the components basis, which I'll talk about in a little bit, it's really just iron air and then water is kind of the fundamentals of our chemistry. There's no risk of thermal runaway and there's no heavy metals in the system. So it's very safe system, and which is something that really matters a lot for utilities. Scale is also very important, right? You wanna make sure that we can build this not just in the US, not just on individual continents, but can you access a format of iron all around the world? And you can, iron is actually made on every continent, right? So on a kind of a fundamentals basis, this really gives us to very, very low cost entitlement that can actually meet the requirements not just within the US, but kind of within the global, within the world. So on the fundamental building blocks of our system, so that you can think of the cell as kind of that fundamental chemical component, it really has all of those qualities that you want in terms of low cost, right? So the iron anode, this is a highly abundant, very low cost metal that's readily available from the steel supply chain today, with basically minimal changes that we can get to to inform the format of our system. Our air electrodes, these are all kind of commercially proven readily available electrodes. There's nothing really new or fundamentally different there. And then they're all surrounded in kind of a basic electrolyte, a high pH system that's similar to what you get in AA batteries today. So that's kind of the core building block in the chemistry side. And then on the balance of system side, which is all the auxiliary systems that you need to make the battery work. So air handling, water management, et cetera. All of these are kind of commercially off the shelf, readily available components. So there's nothing really new or fundamentally different that we're innovating on there. And that allows us to get to a very, very low overall installed cost. So when you think about what this actually looks like in the field, eventually you can imagine a system that's hundreds and hundreds of acres. And it really starts with that core chemical building block, so the cell. So that cell is that our smallest, repeatable electrochemical unit that includes the anode cathodes all surrounded in that water-based electrolyte. And then we build many of those cells in series and in parallel to build this battery module, which is kind of this DC power building block about the kilowatt sale. If you'd imagine what this would look like in a room, it's about a one by one by one meter module. So a little bit about to my shoulder height. And we really thought, we were very careful about kind of thinking about this design in a way that could really be low cost and easily installed and easily managed in the field. So something that could easily be shipped to a project site, easily movable with a forklift. And then to get an actual power block, which is what a utility would really need. They want something that's fully connected to the grid at the medium or high voltage system. You want not just many of those power modules, you'd actually have maybe thousands of those modules all surrounding around a utility grade inverter on the order of a megawatt scale. And then to get to the many hundreds of megawatt or even gigawatt scale, which is what you would really want to be kind of similar to what you get for gas plants today, you can imagine a hundred megawatt system would be about a 10 gigawatt hour installed battery, right? So it's a lot of capacity that you get. And this is where we really think is the opportunity in space of how you could really replace gas and coal plants. So just to give you guys a picture of what this looks like, you might appreciate this from being in an academic environment all the way up to product space. So just in early 2018, this really just started with an iron anode, right? Just one small pellet and just proving out that that could really work. And then we've scaled up since then, both kind of at the subscale to subscale cell level, building out to that full height cell. So that kind of gets to my shoulder height that gets you to that one meter depth. And then we've scaled out since then, both on width and then also on the module basis as well. So kind of building out what that first proof point looks like in terms of what an actual embodied electrochemical system looks like. So it's a big scale if you were to actually imagine this on a order of magnitude basis, on a power basis from the iron anode to a full module. That's, I think it's 300,000 X. That's quite big that we've been able to do in the last few years, which is really exciting. So we have a first pilot project, which is really exciting when you think about the opportunity and demand. So we're working with Great River Energy. They are a small co-op in Cambridge, Minnesota. And we will be deploying a one and a half megawatt, 100 megawatt hour system that will be coming online in 2023. And I think one thing that's particularly exciting about this is it's easy to think of multi-day or long duration storage as kind of a fall out problem or a solution that you wouldn't really want now. But in this particular utility, there's a lot of drivers that really drove them to be very excited about form, even kind of starting from two years ago. They have a coal plant in their area that's retiring and they have a lot of wind assets and they're just really craving a new form of firm clean capacity that they can use to replace what that coal plant used to provide. And that's where they got really excited by form. And we're excited to bring this onto the grid in the next two years. So with that, I will transition it over to Scott and talk a little bit more about the modeling side. Thank you, Annie. Well, that was a great tee-up for the company. I think if you wanna go to the next slide, just a bit about what analytics does it form energy. I think Annie touched on this earlier, but we really try to be a, I mean, just across the board, obviously a quantitatively driven company, we wanna make all of our decisions, informed by the best possible analysis. That includes at the very technical level. So we have, I have the next slide talks about this, but we have a lot of folks that do things that could be considered analytics at form, really with the analytics team within the broader business development and analytics group at form does, is kind of quantitative modeling of markets. So anything that touches the kind of economic or project or system value of our asset, and that is, that requires essentially beyond an Excel model to analyze, that is what the analytics team focuses on. So largely we're really kind of driven by the desire to understand the future trends of the power sector and how that will impact the economics of different assets, including our own. So we wanna be very unbiased, but then obviously we wanna inform forms, kind of product and strategy and policy decisions based on that. So we do this kind of unbiased or what we think of as unbiased assessment of market fundamentals and system economics and then use that to help form build projects. So we work really closely with our commercial operations team to really educate our customers. The reality is most utilities have not seen a 100 hour battery before. Some are still think that four hour lithium ion batteries are nascent technology. So this is a 100 hour battery, sounds very strange to them. So we do a lot of customer education and help them understand what the business case could be. We then, we also realize that this is not, form is playing really a 30 year game. This is not a kind of an effort to get into a market and get out quickly. This is, we see this as a multi-decade effort. We're all motivated by the desire to decarbonize. And so what we are trying to do is educate the market on what we think are the right mechanisms to decarbonize cost effectively. And then we obviously wanna do that by providing our unique view. So when we think about things from the multi-day energy storage perspective, that's the kind of unique perspective that we can bring. And then obviously we partner with internal teams to help them do their thing. So either informing the policy and regulatory affairs team or the product management team that any runs, as well as any other kind of teams internally, including the tech team, work with them to provide assessments of how our batteries should be expected to operate and things like that. This goes back really to the very founding days of FORM. FORM's, one of FORM's five co-founders was Marco Ferrara who led business development and analytics. Analytics being one of the core teams from the very beginning. And FORM's actually the first kind of experience using analytics at FORM was the company was actually founded around the idea of maybe building a 1,000 hour battery. And then we went and we looked at the different, as Annie mentioned, the different chemistries that could maybe deliver on what we thought was necessary or what we thought was gonna be important and said, okay, how would these things actually work out economically in the market? And then kind of moved that goal down to actually, let's focus on maybe 175 or 200 hours. And that was all informed by a project level economic modeling. And then actually when Annie joined, she kind of led another effort that we worked on together to say, actually what do we think is the right thing that clears in the market and then ended up going to 100 hours. So it's, I guess all of that is to say that one, this is started from very early on in the company's history. And two, it's had real impact on, how we think about the product that we're building and the thing that we're trying to go to do. Annie, if you wanna go to the next slide. This is maybe just another rephrasing of what I just said, but long story short at FORM Analytics is really or at least the analytics team is anything that touches energy markets of project economics and that is too big to excel. So primarily we're using Python-based power system models. We're leveraging cloud infrastructure to run those models because a key, I guess differentiating feature for what we're trying to do is model things in a scalable fashion and really represent the system with a lot of granularity, both in terms of how the system is operating from moment to moment in time, but also with respect to space. So we wanna be representing the details of the grid with the maximum level possible. And we're doing that informed by both existing system data, historical data and kind of forward-looking data. If you wanna go to the next slide, Annie. Part of, a big part of what motivates our work at FORM is a desire to understand the value of our product and just kind of how the system is, the power system will evolve in general. And a major driver of what we do is a belief that the best way to understand system economics is with optimization-based production costs and capacity expansion models or capacity expansion unit commitment and economic dispatch models. We confront this very often either utilities or IPPs or policymakers trying to assess the relative value of different technologies using first, a levelized cost of storage metric. We think that this is a pretty flawed way to do things in part because one is only an assessment of cost and it does not assess value. And even its assessment of cost is actually very imperfect because you have to make an assumption about what is the cost of the energy that you are charging the battery with. And more often than not, in almost every case that we've seen an LCOS or a levelized cost of storage model, they assume some flat value. So you're paying, I don't know, $20 per megawatt hour to charge energy. But of course, in the real power systems, the cost of energy varies over time and it really depends, are you charging from energy that would either be curtailed or go into the battery or are you co-located with a wind farm that has some kind of negative correlation with pricing. So when the wind is blowing very strongly, energy prices tend to be lower and so maybe you're charging with energy that is less than average price, et cetera. So really LCOS, it only assesses cost and even that it does a pretty bad job at. So we really don't like that kind of modeling. The next thing that we tend to see when people are baby being a little bit more sophisticated than traditional LCOS modeling is some kind of price taker dispatched modeling. So you'll say, okay, I'm going to take some prices that I see on the market, usually historical prices, although sometimes forward-looking prices that you get from some kind of vendor or some kind of futures market. And you say, what is the economics or what is the kind of value of dispatching this battery against those prices? This does a little bit better job of capturing costs because you may be capturing more realistic or a more realistic view when the system is charging or discharging. And at least it begins to capture value. So it begins to capture kind of what is the system going to produce in terms of returns and things like that. How is it going to benefit the system? It does that by representing different market products that are in the market. So maybe you're dispatching against, you're providing energy arbitrage, so you're dispatching against energy signals. Maybe you're providing some ancillary services, meaning very quick changes in the state of charge of the battery in order to kind of balance the grid over time. Maybe you're providing capacities. You're kind of reserving some amount of energy in the tank in order to be available during periods of grid stress. So you have some representation of market products. I have this kind of not filled in all the way because in practice, you're not really capturing the dynamics of those systems. So in reality, if I choose to charge or discharge an hour, that can actually impact the value of that service and you tend not to get that in these price taker models. So it's maybe not perfect. You're definitely not capturing how these assets are interacting with each other, meaning if I'm discharging now, is that preventing some other asset from discharging, et cetera? Maybe you're capturing a little bit about how the asset mix in the grid is changing and maybe a little bit about how that's changing associated with policy and regulatory constraints, but at the end of the day, that's kind of relying on an assumption that's happening outside the model, meaning you need to kind of assume that these changes are happening in the grid and that as a result, the prices that you see in your model reflect those changes, but ultimately it's imperfect and they're really not capturing, they're not great at capturing any kind of transmission detail or anything like that. That brings us to production costs and capacity expansion models. These are the tools that we tend to rely on most heavily because they capture the combination of these two things really captures everything that we think is really critical to understand the value of long duration storage. So together they can capture what market products are actually being offered in the system. They capture how this technology can interact with other technologies, meaning if I install this technology, does it avoid the need for other technologies, maybe avoiding the need for transmission or avoiding the need for other more expensive forms of generation? It obviously can capture the impact of policy and regulatory constraints. So we wanna decarbonize over time. So we look forward and we say, okay, what's the best resource mix to do that? To a degree, we can capture uncertainty and things like that. So this is a very long winded way of saying at the end of the day, what we think is really critical to understand the economics of these systems is very detailed kind of optimization based modeling and that informs a lot of our strategy and both around the product design but also our market interactions and our business development. So this is the approach that we take if you wanna go to the next slide, Annie. The tool, I'm gonna talk about one tool that we tend to use, it's a tool called formware, which is essentially a least cost capacity expansion model. What capacity expansion means in the power system context is essentially it's telling you what resources you should build and how you should operate those resources in order to meet whatever objectives you have within realistic constraints. And so when I say whatever objectives I have, I mean, if I'm a utility, I'm making some forecast of my demand out into the future and I'm saying I want to meet some fraction of that demand with clean energy or maybe specifically renewables and maybe there's some other constraints on my system. I have transmission representation, things like that and I need to be balancing supply and demand. Maybe I can buy energy from a market or sell energy to a market. You can kind of capture all of these things and then say, based on all of those constraints, what is the best set of resources for me to go invest in and how should I operate those resources? That is what we do with formware and that's a tool that we've built up in-house over the last four and a half years and we use it like I said to inform all of these different decisions. I'm gonna highlight a couple of projects or a couple of kind of outcomes that we've seen and just talk about how we tend, essentially show some examples of how we use formware to inform some of the decisions that we make. Annie, if you want to go to the next slide. Oh, well, this is, so I actually forgot about the slide, but long story short, this is just a reiteration of kind of all the different ways that we use analytics to form, really kind of marketing analytics to form everything from kind of business development, kind of commercial support all the way through, supporting our policy teams and our product management teams. So this is one of the kind of case studies that I wanted to highlight and just, I think it's useful because it underscores, it underscores really the value piece that I was trying to describe earlier, meaning how, using these capacity expansion models to understand the value that NASA can provide in the system. This is a case study that we built for kind of a least cost representation or essentially a representation of MISO, which is, I don't know the power systems background of this group, so I'll explain it briefly, but MISO stands for the Mid-Continent Independent System Operator. It is an entity that kind of spans much of the middle of the U.S. that operates the U.S. power grid in that region, meaning it essentially tells power plants when to turn on and turn off in order to meet demand at every different location in the system. And MISO as an independent system operator doesn't really tell the grid which resources to go by or which resources to go invest in, but it does do some kind of forward-looking planning because the system operator in order to maintain reliability, it's tasked with maintaining reliability, it needs to kind of know what assets it should expect to be online at any given point in time. A lot of the utilities within the Midwest are thinking about decarbonizing, and this case study was really a lot more relevant when the Clean Energy Performance Plan was being considered as part of the reconciliation package within the Biden administration, but so within that time one of the potential outcomes of the CEPP was that all of the states and utilities within MISO would have been incentivized to move towards 80% Clean Energy by 2030 on a path to 100% by 2035. That policy no longer exists, but the case study is still relevant because it kind of again points us to how can long-variation storage or multi-day storage provide value in a decarbonizing power system? And the long story short, essentially, the way we think about value is you say, okay, what's the least cost pathway to providing 80% decarbonization in MISO without multi-day storage? And that's kind of the middle bar. And then what's the least cost portfolio providing 80% decarbonization with multi-day storage? And what we tend to see is, without multi-day storage, we build a lot of renewables. Actually, we do that in really either case. We actually end up building a really substantial amount of lithium ion. And then we end up building a little bit of natural gas vine cycle plants with carbon capture and sequestration. That should say CCS, not natural gas CC. So we end up building quite a bit of renewables and then overbuilding or building a substantially the larger amount of lithium ion as well as carbon capture and sequestration systems to provide firm capacity. With multi-day storage, we end up building a little bit less renewables. We end up with a very similar quantity of storage, but we have to rely a little bit less on wind. And the impact there that's not shown on this slide is largely due to an increasing utilization of those assets. So we really reduce curtailment on that system and end up with essentially about a 40% reduction in curtailment. We replace a substantial amount of lithium ion. It's not a perfect substitute because these really are different assets and that provide different services. And I'll talk about that in a moment. But we replace a substantial amount of that and then obviate the need for kind of more expensive forms of firm capacity like carbon capture and sequestration. So what this shows is not only essentially how the system changes with the ability to invest in these kinds of assets, but also where the value emerges from and emerges from kind of improving that utilization and changing the asset mix in a way that reduces overall asset needs. You wanna go to the next slide, Amy? This is kind of another cut at that same story in a different region. This is for a utility in the Western United States, which is WECC stands for essentially the entity responsible for maintaining reliability in the Western US. And I think without going into too much to Jill on this slide, because it's really not necessary. The point I'm trying to make is that you can really use this kind of framework to understand both the system level value as well as the asset level value and saying for a particular project in a particular system, what is the total value that we provide in a decarbonizing portfolio? And if you wanna go to the next slide. One of the things that I mentioned that kind of comes out of this style of modeling is not only which assets should we invest in but how should those assets operate? What this shows is the operational profile of a multi-day storage system represented by the state of energy or state of charge essentially. So 100% state of charge or state of energy as the battery is completely full, 0% is completely empty. And what this shows is the profile on the next slide I have a direct comparison but the profile of how a multi-day storage system would operate and it's very different than lithium ion or other types of resources. What we tend to see is some combination of intraday battery cycling. So that's represented by these kind of purple bars on the right where you see essentially some charging and some discharging within a single day period. Maybe eight to 12 hour bursts over a period of maybe high demand or low removal energy production. Moving to the left we tend to see also, so we see that kind of intraday behavior overlaid with some kind of seasonal behavior. So in this case we're kind of charging up the battery or kind of net charging the battery over about a one month period in the spring where we tend to have high renewable generation and low demand followed by a multi-month discharge of the battery between late June or early July and the end of August when the summer demand months pick up. And then finally the last kind of operational behavior we tend to see is multi-day discharging or or charging of the battery to kind of stop gap the system during low renewable energy events. So this is the kind of behavior that we tend to see and it's one of the outcomes of this modeling and it helps us think about again where is our system creating value? And then also what do we need to go test? You know, how do we need to go design the system to operate or essentially how do we need to test the system? How do we expect it to operate? What kind of test should we run against the batteries and all of these kinds of things? And then the last slide that I have is really just comparing, you know how a multi-day storage system, this is from a snapshot from some work we're doing in California. How a multi-day storage system would operate compared to, for example, hydrogen which is providing more seasonal storage and lithium ion which is providing that intraday cycling. And again, this kind of analysis and this kind of representation can just help us understand how this asset is unique relative to other types of resources. With lithium ion, the kind of light purple here, we see a lot of basically charging and discharging every single day, in particular during the months, the kind of spring and into fall months. You know, it's essentially solid purple which means the batteries every single day charging and discharging, charging and discharging. With multi-day storage, we see that which is represented by the orange. We see that complimentary intraday and multi-day and monthly cycling. And then with something like hydrogen, we see much more of kind of a seasonal story where it's really charging all the way from late winter all the way through the fall and then kind of discharging throughout the winter, early winter into, I guess, still early winter. But I think what the other kind of key takeaway here is how these resources can be very complimentary in the system and this kind of modeling can help us understand how we expect these assets to perform and how we expect them to support other resources and providing kind of a clean firm portfolio. And I think that is the last slide. I don't know, Annie, if you wanted to say anything here. Oh, yes, just a shameless plug that we're hiring. Maybe just putting a little bit of color on that. When I joined Form last year, we were about 60 folks. Now we're about 170. We're hiring all across the gamut, both on kind of the software engineering side, on the analytics side on Scott's team, as well as on the kind of product development engineering side all across the gamut. So definitely encourage folks who are close to graduating time. Definitely check out our careers page. I will say just kind of personally, I think Form is at a very unique space where we're really thinking ahead about how we really build a new class of assets that can enable this fully decarbonized grid in a way that's really near term, right? I think a lot of people think about this in a 2050 time, a really far away timeframe, but what we're showing with our technology is that it's really possible in the near term. So yeah, feel free to ask us any questions about Form, technology, analytics. Yeah, we'll take it from there. Okay, thank you. Hi, thank you so much for a very interesting talk. My question might be a bit silly, but I was wondering what product management or product design looks in the context of these kind of businesses? You mean what did the teams do or what does the actual product look like? Maybe both, like what do the teams do and why are the teams important for the kinds of products that you guys are working on? Yeah, so that's a really good question. It's kind of what are the teams doing in a way that's kind of unique to product development in a utility space? Many, I think maybe I'll just speak a little bit to the product management side of things and then can speak a little bit towards the other engineering teams. On the product management side, we think a lot about what exactly is it that utilities really require in terms of the requirements of a storage system? And I think in product management, in particular, it's all about trade-offs, right? What's the right cost efficiency trade-off? What's a degradation cost trade-off? So the things that we think about in our team are given the landscape that Scott and his team put together with what utilities really need. How do we actually make sure that we're helping the technology team make those right trade-offs, right? And how do we make sure that we're asking the right question in a way that can prioritize their efforts? So that's what my team does. In terms of the other engineering teams, I think it's kind of similar to what you'd expect in another battery company, right? You'll have kind of product development, R&D, cell development, a lot of that's kind of making sure that the actual chemistry of our system works really well. So we've got a lot of folks on the cell development side. On the product and systems development, it's how do we really build this in a way that's very reliable across all types of kind of weather or extreme weather events that you have to manage towards the utility timeframe. And then there's also kind of the manufacturing level that as well, which is how do I not only build something to blast in the field, but how do I also build it in a way that can be manufactured easily and can be manufactured reliably? So we've got a lot of folks on the engineering and systems development. So those are the folks who are based out in West Berkeley and the cell R&D and development teams are based in Somerville. I'd also add that in the utility space, and I think this is generally true of hardware broadly, but I think it's particularly true of utility scale, bulk power applications, where the things that you're building, the unit sizes are very big. They are kind of costly just from an aggregate dollar perspective. It's very different than software. You can't afford to kind of release a product and do A.B. testing and see judge consumer reaction. You really have to kind of predict where you expect, what you expect demand to look like three to five years out or maybe in certain cases like a decade out and say, that's the product that we're gonna go build. And that kind of decision making where you're saying, knowing what we know today or what is the kind of best risk informed decision that we can make about what to go build that we think will meet customer needs, knowing that we're locking in decisions today about product design that are gonna last three to five years on a development cycle. So I think that is something that is kind of uniquely true of hardware and in particular hardware in that kind of utility scale energy space. What's the biggest product or market assumption that form energy still needs to validate? You wanna start, Scott? If I understood the question correctly, is what is the biggest assumption that a market or product assumption that we think about? Is that? If you guys don't need to validate or have a lot of questions about it. Still needs validation.  I mean, I think there's two related things. I mean, one of the biggest things that drives value for our system, we hope to be the least cost form of clean firm capacity. You want to provide kind of reliable capacity to utilities in a zero carbon fashion and we wanna be the cheapest resource to do that. That kind of assumes that utilities want clean, firm capacity. Clean being a differentiator than just firm capacity. So I think that is validated by both the kind of investment decisions that utilities are making and obviously the broader focus on decarbonization in the United States. But we are kind of skating to where we think the puck will be. We think that that trend is going to continue and that the nature of what firm capacity or clean firm capacity looks like is going to continue to require longer and longer duration assets. And I think that the kind of related piece there is we are assuming to a degree that utilities are not going to want to, or maybe policymakers and really customers are not going to want to continue to rely on natural gas to provide that firm capacity resource that we're gonna start to demand clean alternatives to providing firm capacity. So I think that is a big assumption that we continue to advocate for showing that there are alternatives to natural gas to provide firm capacity and that those alternatives are better in many ways. But that is kind of an assumption that ultimately drives how we think about where the right market opportunities are for us. Yeah, I guess I'll add on to Scott's point, which is it's an assumption that utilities will choose to not build new gas assets, but it's also like they, a lot of the excuse that they may use is that there aren't good affordable options today. So it's a little bit of a chicken and egg. If we had a solution like ours that lasts for 100 hours that is cost-effective and affordable, then could you retire gas plants? So that is the premise that we are going out with, but still something that we actively engage with customers all the time, right? And that's where the value of kind of this modeling piece comes in is showing you how you actually deliver on that reliable piece without other gas assets. Yeah, it's a great question about like, how do you validate your assumptions? So it's actually unique to form where we have a very close relationship with a lot of these utilities. Cause when we take the perspective of we wanna help you build towards your goals, right? Depending on what's unique to your grid, what's out there, how do we actually make you enable that future and how can we do that cost effectively? So by kind of taking those data sets and kind of working very closely, hand in hand with them, here's your grid, here's how we see it. This is where multi-day storage could provide value in that system. Then that, then through that close interaction we're kind of validating that particular assumption. Yeah. Super cool to see what forms up to you. Thanks guys. Just one question. It seems like a big part of the value of forms battery is sort of its capacity value for meeting peak events. Capacity markets can be very flawed throughout the US. I'm curious how much you guys think current electricity markets need to change in order to fairly incentivize products like forms? Or do you think that their current form is sufficient for you guys? Yeah, that's a really great question. I would say that I think we pretty strongly believe that markets will need to change pretty dramatically to encourage decarbonization. Markets are, this is a really complex topic, of course, but by and large markets are very good at kind of coordinating or current electricity markets in the US are very good at coordinating existing assets to ensure the system operates reliably and cost effectively given the resource mix that exists today. They are, they have not proven to be particularly effective at driving the kinds of investments we need to maintain system, even putting aside the decarbonization objectives, they have not proven to be particularly effective at driving investment decisions in a way that is kind of least cost and effective in that sense. And that's been demonstrated, again, putting aside the decarbonization goals that's been demonstrated for existing technology. So by and large, our markets have been shown to kind of operate really well, but not necessarily kind of ensure that we have the right resource mix moving forward. And then once you start to layer on the complexities of decarbonization and what that means and in particular, the need to drive kind of innovation. And so you're not just thinking about static efficiency, but you're thinking about dynamic efficiency, meaning the efficiency of the power system over time, our markets are really not great at optimizing for that alone. So one really simple example that I give often and you kind of touched on with respect to capacity markets, capacity markets are designed assuming that the kind of reserve product, meaning the thing that will get built at the end of the day is a natural gas combustion turbine. And that kind of sets the maximum clearing price in technical terms, it's called like the cost of new entry is always based on a natural gas combustion turbine burning natural gas. That is not a zero carbon solution. So if you're kind of benchmarking the reserve price in your market against a carbon emitting solution, that's obviously gonna skew the types of resources that you tend to see in the market. So that's just one really simple example, but we could really go on all day. I mean, I think our markets are designed really about meeting short-term peaks and are not really kind of starting to think about multi-day renewable energy roles and energy sufficiency over these multi-day periods and all different kinds of things. So I would say our markets are both a marvel of kind of engineering and economics. They're really incredible and they ensure that the system, which is the largest machine ever built operates effectively, but they have their limits and will need to evolve as we push towards decarbonization. So I had one, I may follow up to that question and that is in your work, either one of you or both, do you think the way forward in this regard is educating the regulators? Because we've heard a lot from the regulators here or kind of complimentary, I don't even know who these are, but I expect they are complimentary entrepreneurs that are doing other things that would in a sense work around the status quo ante. I wouldn't even blame that on regulators. It could be other public acceptance, blah, blah, blah. Do you spend a lot of time on that? The other model could be, we leave that up to our innovative utilities to handle all that stuff. So how do you do all that? We are engaging directly with regulators and market operators. So that, again, we're playing a multi-decade game. We wanna be building the markets for the long haul. So we are working with those folks. I would also say we're working directly with entities that maybe want to move faster than the market more broadly. So either, there are very progressive forward thinking vertically integrated utilities, vertically integrated utilities are maligned frequently for maybe being conservative or slow moving or something like that, but there are many that are looking to the future and saying, we see the writing on the wall, we see the need to decarbonize, we wanna get out of ahead of this issue and start, we recognize, we've done the modeling, we recognize the kind of resource gaps and that we're gonna need something else. And so we wanna start buying in today on solutions that we think can support us in decarbonization. So there are those kind of entities and then there's also the municipalities and commercial and industrial customers that also wanna move faster than the broader grid. And so they're saying, okay, we're gonna try and push this issue forward. So there are, I think there's the customers that'll kind of move quickly and we work really closely with those customers. And then I do think there's room for entrepreneurs that can create new ways of operating markets or new financial incentives and things like that that can allow customers to understand the carbon emissions impacts of their decisions. So depending on where you are in the grid and how you're operating, what the emissions impacts are and things like that. So I think there's definitely room for regulators, customers and entrepreneurs across the board. Very exciting. Sarah conveniently arranged the talks. We had the biggest CCA in California speak last week. So I can see those as other people you could reach out to because they are similarly minded, it seems to me. That's pretty terrific. With that said, I'd like to, before I thank these guys, thank Sarah and Marlies for a terrific quarter and all of you for being here. We'll look forward to reading your final essays. If you have any questions or comments, I know I owe a couple of people feedback on some of their interests, but feel free to do so. So with that said, we'll move on to the of close and personal student session with Annie and thank very much for actually doing a great job of not only creating a crescendo at the end of the quarter but tying a lot of themes that we've had exposed here together in a very creative and entrepreneurial way. So thank you, Annie and thank you, Scott, for a great, great talk. Thank you. Thank you.


The Ocean State Police Command has arrested four operatives of the DSS and the NSCDC for kidnapping a Burudushanj businessman in Oshobu. The DSS and NSCDC officers were said to have connived with Ajibola Ogunivi and reached away a Burudushanj businessman to a bush along Ilesha Road where they demanded ransom. The Commissioner of Police Olawali or Lokoli said 24 varieties of weapons were recovered from the suspects. Others were a Formatic Mercedes-Benz Jeep, Tricycle and Motorcycles. A man came to his office with gun and whizzed him away to the bush along Ilesha Road. And at the end of the day demanded ransom. Thereby, Sajj and his possessing of the sum of around 4,000 EUR found on him. He was consequently left to his feet in the bush where they escaped. The tactical team from the CP surveillance squad activated their investigation mechanism which led to the arrest of one of the perpetrators. So concerning the issue of the fire arm, I was found behind the warm mocks in my division so which is I'm solving there. Then due to the movement of one location that is going towards by particular data. So and for me so instead of me to go direct to my colleagues and find out so and then I mistakenly So the fire arm that you say I don't know what call over me so by that time.


Rhaid am ymlaen, mae ymlaen Jack. I'm here today to talk a bit about Elm. I've got into the habit of putting the flags of the countries I speak in at the beginning of each talk. So, I of course found the Spanish flag emoji and then it was pointed out to me backstage that this might be a bad idea given where we currently are. So, thankfully the organizer pointed my mistake out. So I've rectified it, I've got both. Hopefully that keeps everyone happy. So, yeah, I'm delighted to be here in Barcelona, the amazing city to talk about Elm. I knew it was going to be a good talk. I saw this sign when walking around yesterday and I thought to myself, it's a sign. Okay, I'm really pleased you laughed at that because I really wasn't sure how that was going to go down. My name's Jack, this is me on Twitter and mostly on the internet. You can find me on here and find links to everything. If you don't have time to do many questions afterwards, I will check Twitter afterwards and also please come and find me. I'm here all day so please come and just ask in person. I work for a company called Songkick based in London. We've also got offices in New York as well. We're a service that helps people find gigs and buy tickets to gigs. I have to mention it. We are hiring as is every other tech company in the world but please do come and chat to me if that's interesting. So, I want to talk about Elm, but before I talk about Elm, I have to talk about everyone's favourite language, JavaScript. Lee's actually done a great job of setting me up here, but I want to go back to when we first started building these kind of more heavy client-side architectures in JavaScript and what the kind of approach was. And I think we started with the MVC, the Let's Replicate Rails. And then we discovered that this didn't really work. But before we figured out that components were the way forward, we had a lot of stabs. We went MVC, we went MVVC, then we went MCVCV, MMCVCCC. None of these really worked very well and they didn't really work. They were pretty tricky to figure out. They caused lots of problems. Most frameworks at the time focused on the idea of two-way data binding and this dirty checking or polling where you have data in your view that the user sees and data in your code and you're just constantly checking the two to make sure they're kept in sync. I mean, anything that's called dirty checking can't be a good long-term solution, right? We got to a point where this was so popular that people even considered adding it to the language. Object.observe was a feature proposed. It even made it into a version of Chrome, I think, and maybe other browsers. And this led us to watch an object and get notified when this object changed. It turned out, however, that long-term this is a bad idea and people began to think that we can do better. And it was confirmed that we can do better. This library that you might have heard of came along and really pushed this idea of immutability and also components. And it's not just React doing this by any means. If you look at the later version of Angular, Ember, Vue.js, all sorts of frameworks now are very much focusing more on components rather than controllers. As said, I can skip a whole bunch of this talk. Lee wasn't lying when he tweeted me, telling me he'd set me up for success because he very much mentioned a load of stuff that I'm going to quickly touch on, too. The problem comes because on the client side, web apps have to deal with changing of data all the time. MVC worked really well on the server because you have much more control over how that data changes. You deal with post requests and you can make sense of it and control it very well. In the browser, however, you can have lots of HTTP requests going, different data sources. The user can do whatever they want. You've got browser extensions, all sorts of things that can mess with you. So really, this mutable data becomes very tricky to deal with. It can get changed from all sorts of sources and it's just a nightmare to work with as your app gets larger. So looking a bit more at the kind of trends that we've seen more recently in the direction we're going when it comes to web apps, we started to see that applications would begin to own their own state. So what we now have is mostly a single source of truth which is where all the data for your application lives. This data is stored as one big object, a JavaScript object. You could even use an immutable JS record or object, whatever type you need there. All your data is now kept in one single repository for you to manage. It doesn't all necessarily have to be there. If we look at it's a JavaScript talk, I have to do to do's as an example. If we have like a to do app, you might let the user go to a specific URL to control how they're filtering their to do's. So in the URL we have slash filter slash completed. That's a bit of state that the user is in the completed filter. So I wouldn't then duplicate that in my main application state because I'd have the data in two positions there. It's all about having a single source of truth. Most state lives in one place, but there are exceptions. As most of the answers in computer science go, it really depends, which is all I've really got for you. But anyway, once we have that state object, our UI becomes just a representation of that state at a given point in time. Again, taking to do MVC as an example, here I've got my to do and it's done is set to true. So we have that one striked out on the list. If I swap that to false, it's now not done and it's not struck through. If I swap it back though, we're right back to where we were again. Once we've got all this state in one place, it's very easy to build a UI that represents that state because we have much better control of all the data. What we've also seen, I'm a bit worried I'm going to get hunted down on Twitter for this slide, but what we have also seen is that efficient rendering, at least initially, is not a developer concern. Things like React, Ember, Angular 2, et cetera, Elm, as we'll see, are very, very good at taking the state changes and figuring out the minimal amount of changes they need to make in the DOM. Now, I'm not saying that you don't need to worry about performance and rendering performance and I'm not saying that developers didn't care about it, but at least initially the frameworks will give you a lot for free and enable this pattern to work. If React, when it first came out, was really, really slow at changing the DOM and diffing it, it wouldn't have got as popular as it is today. So it's great to see the frameworks taking on some of that burden, but we do still need to do work as developers as well. And then the tricky thing is really keeping track of how this state can change. In a typical web app, there are tons of actions a user can do that could change something. And really you want to be able to very much model those in your application and keep track of them. This is all about explicitly defining how users can modify the state through interactions like button clicks, form, fills, et cetera. And also being able to trace it. I worked for a while in a big Angular app, in fact I still do. And stuff like this, I'm not explicitly hating on Angular here, it just plays very nicely for my example. You can modify things in the view by just chucking them onto the scope, right? And there are patterns in Angular I know that let you avoid this. But things like this, it becomes very tricky to track where scope.x has been changed or where it's been mutated. You don't know what called that, you don't know where it came from and so on. It can be very tricky when a bit of data can be mutated in a ton of different places. However, what we've seen recently is a library called Redux, which takes the approach that you should explicitly define all the actions a user can take to modify the state. And these are called actions. So this function addToDo returns an object that has a type and it has some additional data, and this is an action that the user can perform. And we'll see in a minute we then have functions that can take these actions and deal with them and update the state of our app. The beautiful thing about these is because they're playing objects they can be logged and serialized and you can replay them and debug and all the rest of it. So once we have actions and we have our state we can have update functions that can take an action on the state and give us back the new state of the world. So if our state is an empty list of ToDo's and the action is user addedToDo, the update function should take both of those and give us back a new state. If you have followed Redux, these are called reducers in Redux because they can reduce an action on the state into a new state, but update function is just as good and a bit less confusing. So if we have this action, user log out and my current state has a user with name Jack in it, I can get the new state by calling update with both of those and we just get back user undefined. So we now have functions that can give us back the new state also without mutating the existing state and giving us back a whole new one. What's also really nice about this pattern is your update function encapsulates most of your business logic which makes it really easy to test. You don't have to like fire up any UI or deal with like mocking Angular or React or Ember or whatever in your test because it's just a plain function. And it also really separates your logic and your user interface which is really nice as a developer to work on. I want to talk a bit about data flow as well because as I mentioned, we kind of had the two-way data binding approach of Angular and early Embers and all the rest of it, but more recently we've been taking this almost unidirectional data flow. So on the left here we have kind of the Angular and the old way of doing it where you just go back and forth constantly, you're checking. In the new way we have this unidirectional data where data only flows in one direction around your application. So the user does something, they fill out a form, they click a button, that calls the update, that gives back the new state which is given to the view function to then re-render onto the screen in the user. And it turns out this is just much easier to reason with because you know where the data is, you know where it's come from and you know how to handle it. Recommended reading, Andre Stoltz who's definitely around here somewhere and didn't pay me to put this in honestly told me that you should all read unidirectional user interface architectures which kind of goes into that stuff and a lot of detail is a really good read. So what you end up with really is this state at the top of your app, the big red box which can take actions from components which are the blue circles, send them back up, they get dealt with and then the changes propagate through your application. But data only flows in one direction. And then our update functions get a bit more complicated and we can switch on the types and we can deal with every single user action that can occur. And then you have one place where most of your business logic sits. This is kind of good but we still hit some JavaScript issues. It's very easy to accidentally typo one of these user actions. It's very easy to forget to deal with one. It's very easy to return something in the wrong shape like your state will have a specific shape where you're expecting certain keys of values and it's very tricky to mess this up when you have a big application and it can cause weird bugs where like something in your state gets set to undefined and it's pretty tricky. It will be really nice if we can model these using types. So instead if we had a type message which says these are all the messages that a user can perform it happens to be called message because that's the terminology in Elm but you can think of these as actions. So these are actions that the user can perform. So we can have a new user or we can log out. And this is where Elm comes in. Elm tries to be a language to solve some of the problems that Lee was talking about that I just mentioned about these immutable architectures that we want to build for all the reasons Lee touched on. I'm not here to say it's the perfect language yet. I hope one day it will move towards there. I don't know if there is such a thing other than JavaScript. It's also not the perfect solution to all our problems. I'm not here to say that you should all ditch your JavaScript and rebuild an Elm although that would be great. I do think there are certain times where Elm is more applicable and also you have to bear in mind the fact that Elm is not quite as mature as JavaScript and some of the frameworks around. So if you were to Google Elm you'd probably hear that it was functional, typed and compiled but those are all a bit computer science-y for me and a bit boring. They don't make me really want to dive into Elm. So I've gone for the much more exciting, expressive, self-documenting and robust, right? Cool. Yeah. There is a learning curve to this. There's a lot of new stuff in Elm as you'll see it's very dissimilar from JavaScript. The syntax is very tricky. If there's any functional programmers and Haskell users in the room then that's good. I think you'll find the syntax a bit easier to pick up. For those who haven't, which was me, I'd never done Haskell or anything similar, it does take a bit of time but I promise you you will get used to it and then really enjoy it once you're there. So the code is very expressive. It's very functional. It's a bit lispy. So we call add with one and two. We get back three. We can map over list of numbers passing this anonymous function. The backslash, by the way, for the anonymous function is vaguely supposed to mean a lambda. That's how you can kind of remember that one and you can also do things like partially apply functions. A lot of things that anyone familiar with this style of programming will recognise. We also have this really nice syntax called pipes. So if we have the make person function that takes my name, Jack, I want to call that and take the result of it and pass it to increment age, then pass it to increment height, although I really don't want to get any taller, and then pass it to increment weight. We can, instead of going from there where you have to work from the inside out, you can use the pipes to make it look a bit cleaner. Anyone who's written any elixir will recognise this syntax as well. Unfortunately for me these days it seems to be more about incrementing weight than anything else. But we're doing okay, I think. Hopefully. I don't look too bad. The syntax as well for Elm is just really clean. It's really nice. You have increment age that takes a person. That's how we define a function. And then we take the person and then all the properties to the right of the pipe are the things that get updated. Similarly, add x and y is very clean and you can easily partially apply these functions with one argument. So add two is the result of calling add with just one argument, too. As I mentioned, Elm is typed, which makes it very self-documenting. You don't need to tell Elm what types you're working with. It can infer them automatically, but it can be really nice to add what's called type annotations. So if I have the add function, I can say it takes one integer and another integer and returns a final integer. So the type on the right-most side, it's over there for you, isn't it? Yeah, is the return value. Every other type is each argument in turn. So is even, for example, takes an integer and returns a boolean. I would encourage you to use these and annotate your functions with types. It will save you in a couple of months when you come back to the project and also kind of help the compiler out as well. Then we have what are called union types and these took me a while to kind of get my head around. They're basically a way of creating a type that can resemble one of many states. So if we go back to thinking about filtering to-dos, I might have a type called filter which can either be show all or it can be show completed or show active. And this is basically all the states that my filter can be in. What's really nice about this is I can then write a function show to-dos which takes a filter, a list of to-dos and gives me back the new list of to-dos. And I can use case which is kind of similar to switch in JavaScript. And when the case of the filter is of the show all type, I'll return all the to-dos. If it's show completed, I'll filter the list to just find the completed to-dos. And if it's show active, I'll swap it to find the not completed to-dos. This is really nice for a number of reasons. They can be checked by the compiler. So the compiler knows that you've dealt with all the cases correctly. It's very easy to change or rename one. You rename one if you forget to do it in all places. The compiler will blow up at you. And it's really nice as well to be able to work in your own terminology to say that the show to-dos function takes a filter is really, really nice. It just makes things much easier to follow as a developer. And often in these client-side apps we're working a lot with JavaScript objects, right? We'll have a big object that probably came from an API that will represent our user and all the information about them. In L, we don't quite have objects. We have something called records, but you can think of them basically the same as a JavaScript object literal. And you'll often need to pass these objects around your system. You'll have lots of functions that take a user object and do something with them. We can type these in L by creating type aliases. Type aliases are just saying, right, there's a record with this specific set of keys and I want you to act as if it's a type. So say I'm working with some API that gives me back a person which is a name and an age. I can define a type alias person and then any functions that either take a person or return a person can be typed using that person rather than just taking a record. This is really nice because your code is much clearer. It's cleaner. It's typed in your domain-specific terminology which makes it very easy to work with. The compiler will guarantee you're meeting those type requirements so you can't accidentally take a record and add an extra field to it or delete a field because the compiler will tell you that the types don't match. And we can avoid a whole class of bugs where you expect an object to have a certain property but it ends up not having it because something's gone wrong somewhere along the way. Elm is also very robust as well. If we go back to JavaScript for a minute, if I've got an object and I pass it into a JavaScript function, what guarantees can I make about that object? It turns out none, right? The function can just completely do whatever it wants to it because it gets the reference of that object and it can mutate it as much as it wants. That's why we all love JavaScript. In Elm, that's not the case. Everything is immutable. So if I have this person record in Elm, I call increment age. It can't mutate the person record. It must return a new person and then I've lost all the mutation bugs that I've ever had to deal with in my JavaScript career. So there's a whole blocks of bugs that just aren't bugs in Elm because they can never possibly occur. Elm functions are always pure as well. A pure function is a function that takes all its input as argument and it doesn't need any external input. So here, the sum function is pure because it takes A and B and it will return them added. The other sum function is not pure because it relies on some external data, window.foo. So in the case of sum, I can call it with two and two and that will always 100% guaranteed before but other sum can be whatever the hell it wants because something can be take window.foo. In Elm, you have to write pure functions, which means, again, you can't have a function weirdly change its behavior because you've accidentally relied on an external bit of data. And another problem that really hits us in JavaScript is dealing with the absence of data or something not being present. I've got a quote here. I call it my billion-dollar mistake. Does anyone know who said this? It wasn't my boss either, hiring me. No, so this... I'll give you another clue. It was the invention of the null reference in 1965. This is by a chap called Tony Hoar who said this has led to innumerable errors, vulnerabilities, and system crashes. He literally describes it as the billion-dollar mistake and one he wishes he'd never made. That was kind of the first time that null or undefined in some guys became... was implemented in language and then obviously it's been implemented in every other language since within reason. And it causes a whole load of bugs. I'm a Ruby developer as well as a JavaScript developer. We've all had the like no method foo on nil. JavaScript we've had undefined is not a function or the rest of it. So Tony Hoar made this mistake. You might say it's a horrible mistake. That did not deserve any of that applause. And it's okay if you would like to leave the room. Okay. I really thought that was going to go away but more worse than that did. Anyway, so null null, how do we represent a value being either present or empty? Because sometimes data isn't there, right? If we take like a react component it might get some data from an API and render it. But when do we know that props.api data is actually present if we're making this call asynchronously and at some point that data will come back to us. Usually this means wrapping your render calls in like ifs or checking if the data was there and using a different render function or a different component maybe and all the rest of it. In Elm we have a very British term called like maybe. You can kind of think of this like the shrug emoji or the shrug command on Slack. It's kind of like maybe this data is there and maybe it's not. So this is the type of maybe. This is built into the language. A maybe is either just a value or nothing. So maybe is one of those union types like when we created a filter. Maybe union type has some data attached to it. It's either just that bit of data or it's nothing. So if we have, if we take some imaginary value as a value I'm either just the integer five or I am nothing. And then I have the type maybe int because it's a maybe that might have an integer around or it might not. And this is really important because now you can't possibly not have data when you're referring to a variable. So if we take some list one, two, three and I pull the first thing off the list using list.head I try and times it by two. If we have data in that list this is great. That will work. I should point out this isn't valid Elm because list.head returns a maybe. If you imagine it wasn't and if this was valid list.head that would give us one times two and we get back two. But if list is empty we'll get like undefined times two and then we've got an error. We've got a runtime error and our app has blown up. So you can't ever get into this state with Elm because it makes you deal with every possibility of the value not being there. And this blows up if list.head gives us back nothing. A more concrete example say you've got an app and you have a user who can log in. You might model them as maybe a user which is a custom type you've defined. Then in your view you have to use this case statement to check if the user is present or if they're not. So you can't ever forget to deal with a case of some bit of data missing. It's just not possible and the compiler will shout at you. This takes a while to get used to. I used to hate this when I first got started with Elm all these like extra bits of work to pull data off. But it turns out to be really useful and also makes your app much more robust. Just quickly we also have a module called tasks which is used for making asynchronous work mainly HTTP requests. And tasks either fail with a specific type or they succeed with a specific type. And again you have to deal with it. You can't forget that a task might fail. You have to deal with that. When we want to run a task we hand it off to Elm in the form of a command which is a thing we give to Elm that it will run in the background for us and we'll touch on those a bit more later. As I said, there is a lot going on here. There is a big learning curve but I hope there are enough benefits to make you attempt it and I've got a load of resources at the end as well. There's another really good blog post by Andre that I'll recommend called Everywhereness as a Foundation. The Elm compiler makes sure 100% of your code is thoroughly checked against corner cases and error cases. This makes Elm be almost able to guarantee that your application won't have any runtime errors at all ever. Which sounds like a bit of a bold statement but it's actually demonstrated to be true in a couple of companies who are really using Elm. This is a quote from the creator of Elm, Evan. We also have a compiler that gives extraordinary helpful hints. It is good enough that no red ink which is a company who are writing lots of Elm runs 36,000 lines of Elm in production and has never gotten a runtime error from their Elm code in more than a year. I think it's pretty amazing. We've got like track.js at work and the number of like undefined is not a function errors that just you haven't got a hope of debugging them to be able to run something like this is pretty cool. Elm's compiler is also just amazing. Cory Haynes tweeted this the other day. So here he made a typo. So he was expected to pass selected item but he passed selected items, the plural, and Elm compared it all and figured out where his typo was.  So I know I've got a fair amount to cover so I'll try and go fairly quickly. We're building actual apps in Elm and we have something called the Elm architecture and this is made up of three functions. We have model which just gives us the initial model of our application so that's all our data. We have the view function which can take the model and produce the HTML that will be rendered onto the screen and we have the update function which can take those messages or user actions and the current state, the current model and give us back the new model. And Elm deals behind the scenes with all this data changing and re-rendering on all of it. So when you have the what change question that Lee was talking about, Elm just does it for you and you don't have to worry about it. When your update function returns a new state, Elm will, you know, diff the views and update the DOM for you without you worrying because it's all immutable data it's much more efficient to do that as well. You can kind of think of this architecture in this kind of unidirectional flow that we saw earlier. We had the model, the view and the update and things go round in a lovely circle. So to build the hello world of these kind of apps is a counter app where we can increment and decrement numbers. Firstly, I define the model. In this case, my model is just an integer. I'm just going to call it zero. I define a function initial model which gives me back about zero. Secondly, I define the messages that the user can make or call via clicking buttons. In this case, they can either increment or decrement the number. Then I define my update. So I take in the message and the model. If the message is increment, I'll return the model with one added and if it's decrement, I'll subtract one. Fourthly, the view. Elm has a really good HTML library. The syntax of which does take a little bit of getting used to. I'll give you that. You can see there we have a button. Once we're one where we click it and we'll decrement and one where we'll increment it. Then I put it all together. Elm ships with an HTML app beginner program function where you give it the model, the view and the update and it just hooks everything up for you. Highly recommend using this to get started. Then if we run that, it does indeed work and we can click and things go. I've got a link in a bit to GitHub where all the code lives, by the way. I'll go fairly quickly through it in the interest of time, but feel free to come and grab me or raise an issue on GitHub, whatever you like. We left the view until last which is a property I really like about building Elm apps that we can just worry about the UI less and make sure our business logic is sound. Also, the update function where our core logic is would be so easy to test because it's not attached to the UI in any form. Dealing with side effects as well. So often we'll need to not only update some data but make a request to an API to fetch some data, for example. In Elm, we explicitly model those so we hand some data off to Elm in the background it will run our task or actually the peer request and then it will give some data back when that task has been run. So in Elm, we call these commands.  So the Elm architecture part 2. Again, there's a bunch of code. I'll go fairly quickly. Please grab it on GitHub. Come and find me today. I'm happy to walk you through it in more detail because it can be a bit tricky to get this across to you in five minutes. We've got a new signature for our update function. It now not only returns the model but it returns a command and this is some background work for Elm to do. If you want to think of this in diagram form it kind of looks somewhat like this. The command is up there. Update function can give Elm commands. It will run them and then it will give them back to the update function. So let's say I want to grab some data from GitHub. I create a GitHub person. This has a name and company and this is data that comes back from the API. And I have a model which has the username I want to make the request for and then the GitHub person which is a maybe GitHub person because we might not have the data yet. Then we define the messages. So we've got fetch GitHub data. That will be sent when the user clicks the button. New GitHub data is what I'll get back when I've actually resolved a request and got data from the API and fetch error is if the API is down or something goes wrong in my request. Then we define the update. Notice that we're now not only returning the new model but also at any commands. So for example in the case of new GitHub data we'll return the model and we'll update the GitHub person because we've got data now and then we'll also give Elm command.none which basically means chill out you don't have any work to do. In the case of fetch GitHub data where the user has clicked the button I won't touch the model. I'll give it about the same model but I'll tell it that I want you to fetch this GitHub data with this username. I won't go into how that fetch GitHub data function works so I haven't really got time but again all the codes on GitHub. So again we've got our update function we give it back commands Elm Runzo commands and calls back to us. Then we define our view. So again we swap on the GitHub person if it's just the person I'll render the person's name and company and if it's nothing I'll show the button and have the load thing. Finally we have the initial model which username Jack Franklin GitHub person is nothing and our init function which gives us about the initial model and any initial commands we want to run. This is useful if you want to run a command when the app first runs for example. Then I hook it all together ignore the subscriptions bit I'm just going to try and pretend they don't exist for now and if we run this we can hit load and we do get my data back from the GitHub API. You'll notice as well that I'm actually using opera here which I want to make perfectly clear is not an attempt to influence anyone at this conference at all. So just another example go for this in diagram form so the user clicks a button we call update we give it the fetch GitHub data action and we return the new model and we also return the fetch GitHub data command which is over here. The view renders in the background behind the scenes we make a request the API and Elm's doing that for us. Then finally we get that data so we have this new GitHub data message that has come back over here. So we call the update with this new GitHub data in the model and we return our new model and also command.none so we've done all our work and then the view renders and we get the data back. I made this slide in keynote a long time ago when I worked for Pusher rather than Songkick and I couldn't find the original keynote so there was no way I was making this again so I've done a very subtle update which I hope hopefully I get away with.  This does maybe seem like a lot and I'm aware there's a lot to take in but it all comes down to trading off boilerplate versus explicitness. I like that Elm makes me write a decent amount of code I like that I have to structure everything. The thing is it's much more apparent how good this is when your application grows fetching data from GitHub API you could do that in two or three lines of JavaScript but you wouldn't have any of the structure that Elm has given you here. So I think it's very hard to get across a lot of the benefits of Elm in a small application but I'd encourage you to try building bigger things with it as well. All the code is on GitHub. I'll put these slides up and I'll tweet a link but that's me on GitHub so that's the repo you can find all this code. I know I'm running out of time. I'll go fairly quickly for the rest. In Elm we kind of use components I just want to touch upon this because I saw a tweet yesterday which was really well timed by a guy called Scott. He says the more I'm using Elm the more I see that components were a mistake. Components needed to exist because types didn't in JavaScript. About types JavaScript needed a way to isolate mistakes from the rest of the system and types like the ones in Elm help us with that a load. I'm not sure entirely like I think the idea of some form of components in Elm is good but what's really interesting if you do try Elm is that you'll find you don't want to create these small components you're quite happy with this bigger kind of architecture. So I just think that's kind of something to ponder. All right very briefly the Elm ecosystem how you get up and running and all the command line tools that Elm gives you.  You don't need to run anything else very easy to get up and started.  There's also Elm Package which is a package manager for Elm. It does all the things you expect. It's really cool. It's also I've got to show you this the most British package manager. Do you approve of this plan? When I install something and if I install like a specific package like the HTML package. May I add that to the package.json for you? It's a very polite package manager which I think is probably the biggest selling point for me. Anyway, there's so much more I haven't covered like I didn't have time in the half an hour which I've already gone over sorry to go into everything. So I would encourage you to check it out.  But just to summarise why or when should you consider using Elm?   I found that I write way less tests when I'm writing Elm apps because I'm really confident that the compiler has got my back and will spot silly errors. You're happy to kind of ride the wave. Elm is fairly new. It's settling down. It's picking up a bit of traction. There's a lot of stuff still to be done and worked on. You're happy to kind of build some packages. You know, things like React have this humongous amount of components available on the net that you can pull down and use. Elm is a bit newer. It just doesn't have those yet. You know, more packages get added every day but was still not quite like a React or Angular or Ember state. What if this talk has put you off Elm? I hope it has not. But it does take time to learn. I know this can be a bit overwhelming. Guide.elmlang.org is like a book freely available online that talks you through everything. Highly recommend giving that a go. If you do give it a go and you get stuck, please come and find me more than happy to help. And also, Elm the language brings many concepts that Lee's already touched on that are very language agnostic. So even if you don't use Elm in production, there's a lot of stuff we can take away from this. This kind of expliciteness of the Elm architecture and how things are modeled across the app very explicitly makes things easier to work with. I don't think I need to sell these too much but types are great. They have a lot of benefits. Again, immutability using something like immutable.js for example gets you a lot more guarantees about your data that you don't have by default in JavaScript. And also the thing I like most is this process of defining your application step by step. So you define your model, define how the user can interact with it, define how those interactions are dealt with, then define your view and rinse and repeat over and over again. I think that approach has really stuck with me. Will everyone be writing Elm in one, two, or five years? Guess what? It depends. I have absolutely no idea. I think it's a really cool experiment. It's great fun. As someone who's written primarily kind of JavaScript and Ruby over the last four years picking up something very different like Elm and working with it has been really, really enjoyable. I've really enjoyed hacking on it. So I'd encourage you, even if you don't think you'll use this in production, which not many people are, to pick it up and give it a go because I think you'll have a load of fun doing so. So, yeah, as I said, I'll put the slides online and I'll tweet them with the hashtag. I'll put them in the Slack channel. But here's a few links to take away. Guide.elmlang is the best place to start. The docs are where all the API docs lives. Community has links to like the IRC, the Slack channel, et cetera, which is very active. There's my talk as well and the slides will go up on speaker deck afterwards. So thank you very much for listening. Do you use Elm in production at Songkick? So I've been at Songkick three weeks. So yes, though. So yes, yeah. No. I'd like to think maybe in the future we could, but we're not there yet. No. The supplementary question from the questioners. What would it take for them to use it? Well, is it mature enough? Is it... What would be the thing that makes your bosses go, yeah, we're going to use this? So I think once you get the Elm app built and into production, you will have, you know, it's a way more robust application. Like we've seen the people at No Reading, they've got I think now like 50,000 lines of Elm and they don't get any runtime errors. They don't spend time debugging that sort of stuff. So I think there are trade-offs, but you get a lot of benefits back. Elm is certainly way more mature than even six months ago when I first did a talk on it. I would definitely recommend using it on a kind of smaller side project, maybe an internal tool. I think it's a really good place to start to kind of show off those benefits and then start to work towards getting it into production. It's also tricky like at Songkick, I'm the only person who knows Elm, so it would be a little irresponsible to just start pushing it up and then I could just run away and be in a world of pain. But they could never fire you. Well, that's true. Yeah, I'd be indispensable, so maybe I should. I think because Elm compiles down to JavaScript that I know the answer to this question, but it's been asked, can you render Elm's server side? How do you deal with SEO? So not yet, it is being worked on. It's kind of, there are a lot of bits of Elm that are being worked on. This is one of them. There is an experiment into getting Elm rendered on the server and I would be willing to bet that it will happen, but they're not there yet. There's a few questions asking for comparisons with TypeScript and other such languages, but I feel that that will be a long discussion. Yes. But here's an interesting one. When would you not use Elm and pick just pure JavaScript instead? So I think if, so Elm really shines where you have a load of data that's changing all the time, you have a lot of user interactions and the rest of it. If it's something a bit more static where you could just layer on a little bit of JavaScript I think it would just be overkill to use something like Elm. Obviously if you, I wouldn't build any mission critical stuff in Elm yet. I think people are familiar with JavaScript. It's more evolved. The framework is more mature. So it kind of depends on how important the app is to you and being able to work on it over a long period of time and all the rest of it. I think certainly side projects is a great place to start with Elm before looking at using it for more critical bits of infrastructure. And I guess like every other framework understand its advantages and power and use it when you need that as advantages and power but if you don't... Absolutely, yeah. Yeah, I'm not, you know, if you've got a fairly static app but you want one bit of JavaScript then using Elm will be, you know, complete overkill. Excellent. And obviously a lot of people are interested in your previous circus career. So your trademark move was a double back somersault with a half twist. So could you demo it now? I've got a little pain in my foot at the moment. That's a terrible shame. Yeah, I know, sorry. What a disappointment. He'll be here all day, so maybe he'll get better. I'll throw a couple of beers at the meet-up. Who knows? Good man. Ladies and gentlemen, Jack Franklin. Thank you.