Software Engineer Esteban Küber on the Challenges and Opportunities of Rust and Commure
Many software engineers pick up new programming languages when they start a new job. But for Esteban Küber, learning Rust first is what led him to Commure. Below, he explains why he decided to join the company, weighs the pros and cons of writing the platform in a relatively young language, and shares details on the team’s upcoming projects.
What problem does Commure solve?
Like most legacy industries, health care is bogged down by entrenched processes. There’s a gap between what companies see as state-of-the-art and the actual state of the art, and there are a lot of regulatory requirements. That adds up to an extremely high barrier to entry for someone who wants to innovate in this space. Commure takes care of all the data integration and offers a simple, elegant API, which allows developers to focus on what they want to build.
But we’re also solving a problem on the provider side, where we facilitate access to their data. The people who typically purchase health care software aren’t the ones who actually use it, which means it’s optimized for reporting rather than to help doctors care for their patients. Doctors often have to enter the same information multiple times into multiple systems, for example, which is a waste of time and increases the risk of errors. Part of what we’re doing is minimizing that clerical work and making it easier for doctors to do their jobs.
What were you doing before Commure, and why did you decide to join the team?
Prior to Commure, I was at Twitter for five years, working on the infrastructure side. I built tools for other developers to use, including administrative tools for a key-value distributed database called Manhattan, and I generally tried to keep people from getting paged at 2 a.m. Before that I spent several years as a contractor for Google in Buenos Aires.
I found Commure through the Rust community, which I got involved with a couple of years ago. I’d been hearing about Rust for a while, and when 1.0 came out in 2015, I decided it was as good a time as any to learn. It was painful at first — I didn’t get anywhere. But I picked it up again a few months later, and that time I started contributing right away.
“We’re building something from scratch, which is exciting, but we also know exactly how it’s going to help our customers.”
When Diede and Eugene told me about the platform they were building, my first reaction was, “You guys are insane.” I knew health care had a lot of entrenched players, and the problem they wanted to solve seemed insurmountable. But as they explained more, I realized they weren’t just picking a random industry to try to disrupt, like a lot of startups do. The people on this team have real experience in health care, and so do the advisers. They were making very informed decisions about how to approach the product.
I was also interested in moving to a startup after spending so much time at larger companies. In a big organization, it’s easy to get in the habit of seeing issues as someone else’s problem, and I liked the idea of being on a team where everyone is passionate about finding solutions. What set Commure apart from other small companies, though, was the clear vision and objective. We’re building something from scratch, which is exciting, but we also know exactly how it’s going to help our customers. It’s very different from most startups in the Valley.
Tell us more about why Commure uses Rust.
The founders made a bet on Rust, but it was an informed, strategic bet. The risks are obvious — it’s a very young language, so it doesn’t have the same breadth or depth of resources as Java or Python or Ruby. Rust does have good bindings to C, so you can get some existing libraries that way, but the lack of existing resources is still a potential downside. And while the compiler itself is very solid, the surrounding tooling is less polished than what you might be used to with something like Visual Studio or Xcode.
But there are elements of Rust that really appealed to us. It basically applies 30 years of industry best practices and collective wisdom to a very low-level programming language. You’re writing code that could be at home in a very high-level language like Scala, but without any of the performance issues created by interpreting that language on a virtual machine. There’s also an emphasis on speed and ergonomics — and on accuracy, which will help us sleep at night when our platform is running in hospitals.
The other big benefit is the Rust community, which is really welcoming and open. It’s easy to get help with even the most difficult problems, and people are very passionate, which shows in the technologies they’re developing. Some of the software we write at Commure is eventually going to be open-sourced, because we’ve gained so much from this community and we want to be able to give back.
Can you share a recent project you’ve enjoyed?
In my first couple of months, I’ve spent the most time on the authorization layer, which is obviously critical for a health care platform. There are specific legal requirements around what we do for authentication and login. One of my projects in that space was implementing a new library to parse and evaluate XACML policies. XACML has been battle-tested in multiple industries, but it’s not common in startups because it relies on XML. It’s more of an enterprise technology, almost like a very small programming language. It was fun to work on, and I’m pretty happy with the results — we’re passing 430 of the 450 conformance tests, including all of the ones that are relevant for us. I think it’s going to be important for Commure going forward.
What kinds of challenges can a new Commure team member expect?
Because I hadn’t worked in health care before, one challenge for me was getting acquainted with the FHIR, or Fast Healthcare Interoperability Resources, protocol. I spent quite a bit of time reading up, to make sure I had the context I needed to understand its technical decisions and features, so I could properly implement it.
For someone new to Rust, I think it would also be difficult to lose the baggage of your experience with higher-level languages. There are patterns you can apply in Python or Java that flat-out won’t work in Rust. What’s really happening is that Rust is revealing cases where that pattern won’t work; it was just silent before. Still, that can be frustrating at first.
“We have a high-level roadmap, and we know which four or five things need to happen in the next month or two. From there, it’s just a matter of who’s most interested in what.”
As far as the specific projects you can work on here, we’re at the stage right now where we have the basic building blocks in place, and there’s a lot of variety in terms of what we do next and where you can focus. We have frontend work to do, performance-intensive code and libraries to write, and metrics to get in place to make sure our platform is easy to monitor and maintains a high level of uptime. We want it to be robust, from how we handle changing configuration files in a running service to how we deal with our storage layer. We do think it’s important for team members to get to know all the different parts of the platform, but there’s a lot of flexibility in terms of individual projects. We have a high-level roadmap, and we know which four or five things need to happen in the next month or two. From there, it’s just a matter of who’s most interested in what.