Moixa was founded by Simon Daniel and Chris Wright in 2006. The company invents, manufactures, and distributes smart energy technology including the Moixa Smart Battery range and Moixa GridShare - the battery asset management software platform that enables end customers to maximise the usage of renewable energy and unlock mass adoption of EV technology.
Moixa has been named a Global Cleantech 100 company twice over the last few years and is dedicated to delivering the transition to net-zero.
They have also been a functional programming team since day one. We've asked Chris Wright, the co-founder and CTO at Moixa, and Richard Lewis, Senior Software Engineer, about their experience using functional programming languages to develop their products.
Tell us more about Moixa and your products.
Moixa’s GridShare platform is a global leader in optimising batteries in homes (storing power from solar on your roof), and in Electric Vehicles. We have ~28,000 battery systems connected to the platform in Japan, which we believe to be the world’s largest aggregate battery fleet.
We believe that by increasing the IQ of batteries, the world can live in a future powered by renewables. We are building the software products and tools in GridShare that will deliver this vision, partnering with some of the world’s largest companies (Honda, ITOCHU, Hitachi) to have a big impact.
We make use of machine learning to predict a household's energy consumption and weather forecasts to predict solar production and produce optimised plans for each household in order to maximise cost savings and minimise carbon footprint. This puts us in a unique position to understand across fleets of thousands of devices how they will perform in the future, and so enable the flexibility that the electricity grid needs to utilise the power from renewable generation - which can’t be turned up and down in the same way as a traditional power station.
What functional languages are you using?
Moixa started as a Haskell team, but at the moment we’re mostly writing functional TypeScript. We leverage the rich functional TypeScript ecosystem including libraries such fp-ts, io-ts, and RxJS, which allow us to write the expressive, safe, and readable code that we love to write. We also make use of Rust for the low-level code that runs on our devices.
What prompted you to choose these?
The main draw for us has always been a rich, static type system. When developing new features, we always start by laying out the types and trying to model the domain using types. As our platform grows, we have the reassurance that our code still makes sense because it all still type-checks. In addition to this, the higher order types and functional combinators in fp-ts provide type-checking for the logic that defines our business processes. As a result, developers can see in their IDEs when there are flaws in business logic even before deploying and testing their code.
What were the steps to that transition, from Haskell to TypeScript?
We transitioned from our original Haskell stack to TypeScript in order to allow us to scale our platform using Serverless. Through the NodeJS runtime, TypeScript was effectively natively supported by AWS Lambda. On the embedded side, our original codebase was in C++ and we transitioned to Rust. We started with some internal experiments in Rust but eventually took the plunge with a big-bang re-write.
What advantages and disadvantages do you see by using fp-ts?
The fp-ts library provides standard higher order types such as option and either which we’re able to use to allow typed error handling giving us the great advantage of fewer runtime exceptions. fp-ts also provides a reader type and using this we’ve created a dependency injection architecture which helps to separate out pure logic from side effecting code and also makes mocking effects in unit tests easy.
One of the disadvantages that we’ve encountered is the relatively steep learning curve for junior engineers and even for more senior engineers coming from a non-functional background. This is especially the case with fp-ts. We’re also aware that we take a run-time performance hit by choosing fp-ts as its internals are not especially optimised.
Did you have to make any trade-offs because of choosing these languages?
Our team was originally formed as a functional programming team. When we switched to using TypeScript, we had to try and figure out how to replicate the functional features we were used to from Haskell in TypeScript. fp-ts seemed a good enough trade-off, but we definitely noticed that it makes our code more verbose. We were also aware that we were losing the benefits of years of community contributions.
Currently, Moixa has 65 employees and counting, with offices in London and Manchester.
Tell us about the rest of your stack.
Our stack spans the full spectrum of platforms - from Rust that controls our hardware, to our monorepo TypeScript stack that powers our cloud with Serverless, to React(Native) that runs on our customers’ devices. We use a lot of native AWS services including IoT for managing our fleets of devices.
Have you seen any difference when hiring functional engineers compared to other more mainstream languages?
Functional programming is still not mainstream enough to expect the majority of engineers to have experience with it. This means that the engineers who do have experience with it had to teach themselves, so tend to be more intrinsically motivated. Intrinsic motivation is crucial to stay abreast of new technologies and to innovate.
At Moixa, they have a diverse team of talented individuals working together to develop software and hardware to help build the energy system of the future. The good news is, they are hiring! Check out their open roles here!
Originally written by Mihaela Popa for WorksHub
Top comments (0)