Topics

Featured in Development

Alex Bradbury gives an overview of the status and development of RISC-V as it relates to modern operating systems, highlighting major research strands, controversies, and opportunities to get involved.

Featured in Architecture & Design

Will Jones talks about how Habito, the leading digital mortgage broker, benefited from using Haskell, some of the wins and trade-offs that have brought it to where it is today and where it's going next. He also talks about why functional programming is beneficial for large projects, and how it helps especially with migrating the data store.

Featured in AI, ML & Data Engineering

Katharine Jarmul discusses research related to fair-and-private ML algorithms and privacy-preserving models, showing that caring about privacy can help ensure a better model overall and support ethics.

Featured in Culture & Methods

This personal experience report shows that political in-house games and bad corporate culture are not only annoying and a waste of time, but also harm a lot of initiatives for improvement. Whenever we become aware of the blame game, we should address it! DevOps wants to deliver high quality. The willingness to make things better - products, processes, collaboration, and more - is vital.

Featured in DevOps

Service mesh architectures enable a control and observability loop. At the moment, service mesh implementations vary in regard to API and technology, and this shows no signs of slowing down. Building on top of volatile APIs can be hazardous. Here we suggest to use a simplified, workflow-friendly API to shield organization platform code from specific service-mesh implementation details.

Zero Runtime Exceptions in Production with Elm

At QCon London 2017, Richard Feldman, software engineer at noredink and author of “Elm in Action” from Manning, explained how their decision to switch to Elm led to a 100,000 LOC system running in production with zero runtime exceptions since 2015. Here, we provide a brief summary of Feldman’s key points.

Elm is a purely functional programming language that compiles to JavaScript and fosters the use of immutable data and static typing for the creation of browser-based apps. Feldman recounts how they went full-scale with Elm after using it in smaller side-projects. In particular, after completing a few months long project using React, he realized that:

It would have taken so much less time to do this in Elm that in fact it would have more than accounted for the amount of time it would have taken us to ramp people up and to introduce this new technology to our stack and the end result would have been easier to maintain.

Feldman identifies a number of key factors that account for the increased productivity and reliability of using Elm:

Ellie, the Elm Live Editor, is a sort of advanced REPL for Elm, providing a rich interface when you can write, compile, and render your Elm code.

Elm does not incur the “one billion dollar mistake” of allowing null values to freely propagate through your system, and requires you to explicitly deal with them using Maybe values.

Elm enforces the use of a single immutable value to represent the state of the whole UI. No state is associated to individual components, as it happens in React, although the model need not be a monolithic value. Using the model, Elm assembles a Virtual DOM, which is then diff-ed with the actual DOM, so only the relevant changes are applied. This approach, which is also found in React, is able to preserve performance, while granting the simplicity of dealing with immutable values.

One huge benefit of representing the UI state as a single immutable value is the possibility of handling a sequence of UI changes through the sequence of immutable values associated to them. When compiled in debug mode, Elm allows to navigate through older UI states by simply clicking the corresponding model value. Additionally, it is possible to export a set of those values so other developers can immediately reproduce faulty UI states and how they were generated.

Being statically type-checked is a big selling point for Elm, according to Feldman, making it almost always true that “if it compiles, it works”.

A major factor behind Elm reliability is the way it handles JavaScript interoperability. Contrary to most of other languages compiling to JavaScript, indeed, Elm enforces a message-based approach, where JavaScript code runs inside a service. This ensures that the guarantees provided by static typing are not broken by untyped JavaScript code.

Finally, the Elm package manager, while not so extensive as npm, has its own strengths. In particular, it only allows packages to contain Elm code – specifically, no binaries are allowed, which makes it much more secure than npm. Additionally, it only allows packages that build correctly and automatically enforces semantic versioning.

Overall, Feldman says, JavaScript has proven to be quicker to get something on the screen, while Elm ensures higher overall development velocity.

A final remark concerns one of the usual objections to using a language like Elm, i.e., the difficulty of finding developer to hire. In reality, Feldman says, using Elm gave noredink a twofold advantage: on the one hand, it made their job posts stand out; on the other, it attracted developers that were specifically interested in learning Elm.