By Eugene Kuznetsov
Java is a good option for enterprise software, with a lot of maturity and a big ecosystem of both libraries and developers. Salesforce, my previous employer, is a very successful java shop, but my history with the language started much earlier -- I was part of teams that built some of the first clean room JVMs in the 90’s, and was an early enthusiast for the language. Yet java has gotten a bit long in the tooth, lagging when it comes to language features and its performance hampered by fundamental constraints of the VM’s runtime design. (More on this another time, but I have come to believe that garbage collection is one of them). Similarly, the maturity of the ecosystem brings many potential hires and many potential libraries, but also many unfortunate things. So Java would work, but it was hard to feel excited about it or even that it’s a responsible choice for clinical software that we hope will be used 20 years from now.
C++ is another option. I have a good amount of experience with it, it is mature, compiled, fast, statically typed and - in its modern variants - can be used safely and securely. It has another important advantage of being truly cross-platform and embeddable, so that one could embed one’s libraries or application inside other “master” applications. This is an important consideration for Commure’s product, both in integrating with existing healthcare applications and reducing the effort of mobile development. The two problems are that most experienced C++ developers only use 10% of the language, but they don’t agree on which 10% to use. So if you hire 10 experienced C++ engineers, you’re likely to find yourself mediating a debate about which 10% to use. Add to that the fact that it’s hard to hire C++ engineers and its unpopularity among younger generations, and it’s a hard set of tradeoffs.
The next option is the more modern and popular Go. While new, it certainly isn’t going away, with good adoption across the ecosystem and support from Google. It is compiled, has modern features, has good performance, and has not yet accumulated the plaque in its arteries that plagues other programming languages. The choice to use a garbage collector and a complex threaded runtime gave me pause, however. Those design choices are usually quite benign early on, but my experience with java made me wonder if Go could end up running up against the same barriers as it reached for ever-larger and more complex programs. I also encountered some engineers I respect who had a strong and somewhat hard to understand negative reaction to the language itself. These factors made what should’ve been the obvious option - using Golang - less obvious. Then there is the robust and interesting Erlang. The philosophy of process-based isolation and focus on reliability at scale seemed like a good fit. Its heritage of being born inside a carrier-grade telecom hardware company and the great success that WhatsApp had -- by picking what was an obscure programming language and using it to build a very successful engineering team and a very successful product -- made it worth considering. Yet I did not have any real knowledge of it, and it felt a little bit too exotic for a healthcare software company. I should add that it is entirely possible it would have been a good choice.
Finally, there was Rust. At the time of Commure’s founding, I had been following the language for a few years and used it a bit. There were some important reasons why its design made sense to me: focus on safety and security, compilation to native code, many modern language features, a robust strict type system, automatic memory management with no garbage collector, and the zero cost abstractions philosophy. Just like C++, Rust can be easily embedded inside other programs and runtimes: you can have a Rust library called from a Java or Golang or Objective-C program, but the inverse is far harder.
While the Rust community was very small -- with its creator Mozilla as the main serious user -- it was growing, and the language matched my tastes. It immediately felt like a winner for its time, the same way that Java and Linux felt like winners in their early days. Even years ago, Rust felt like a step forward in the areas where progress is badly needed (like rethinking memory sharing using borrowing & lifetimes) and a stay put in best practices where it’s not (C-like syntax, LLVM compilation, etc). There were some obvious drawbacks, of course. The top one is the risk of adopting any brand new technology at a startup, something that founders are usually told to avoid. The newness of the language meant that there were few Rust engineers available to recruit and not nearly enough mature libraries. It wasn’t at all clear how hard it would be for new people to learn, but it was clear that it wasn’t going to be the easiest language to learn.
Things have changed a lot since then, both for Commure and for Rust. The experience of using Rust has been very positive -- more on that in future posts, but for example, we have been fortunate to avoid debugging GC misbehaviors in production or chasing elusive undefined behavior. As for building the team, the great thing about making an unusual technology choice early in a company’s history is that people have a clear point of view. It turned out that many engineers were interested in using Rust at work and in the mission of making better software for doctors. Today, Commure has what is probably one of the larger engineering teams using Rust in production and one of the few building enterprise software with it. Meanwhile, the Rust project has grown tremendously in capability and popularity, with many larger companies adopting it for important products. It is now run in even more places, thanks to the rise of WASM in browsers and support from cloud vendors. I’m happy to say that what, several years ago, probably seemed like a very risky choice now appears like a safe option for building healthcare software with its heightened safety, performance and security requirements.