Elliot Goodrich doesn’t think C++ is dying by “any stretch of the imagination”.  He tells Michael Oliver what the future of the language will be and how he’s helping build a robust library at Bloomberg .

---

How did you get into programming?

I got into programming when I was 13. One of my friends was making a website with flashing colours and text scrolling across the top, which I thought was pretty cool. Knowing that it was possible to make yourself leads you to buy books and build your own websites.

I kind of just fell into a job after university as a technical business analyst. I worked in the web team for a company doing business-to-business insurance. I was kind of doing a little bit of development - but not proper development.  I realised that I loved the work and I asked myself, “Why did I not just go straight into being a developer?”

How did you get your job at Bloomberg?

I'd heard about Bloomberg and all the C++ stuff they've done. I happened to come across a Client Server job ad and when I looked at it I thought, "This is everything I want to do in a programming job: high performance C++, working on libraries."

A typical work day is varied and there's not a huge amount of structure each day, the only really structured thing we have is a daily stand-up, where I find out what everyone did yesterday, what they're planning to do today and if they’re blocked on anything. After that, I'll do some code reviews. This is where you review the code people have submitted they they want to get into the code base and onto production. Other than that, it'll be meeting with other teams who are using our libraries, discussing ideas with other teams, maybe working through what they've done, and just coding myself.  Luckily Bloomberg still want team leaders to do a decent amount of coding, which is good. I still feel like a technical developer rather than just some middle manager.

Bloomberg has a substantial C++ library. Do you buy into the idea that C++ is dying as a language?

I don't think it's dying by any stretch of the imagination. One of the benefits of C++ is that it was fast and one of the goals of C++ is there should be no language in between C++ and assembly in terms of speed, there shouldn't be a more low level language where you feel, "Well actually C++ doesn't allow me to do what I want as fast as I could do it." That was great for when processors were slow 20 years ago, but processors got faster and faster, you've got a nice exponential curve of improvement, and C++ became less important. Because if you wrote an application that was slow you could just wait a year and it would be blazingly fast because of how quickly processors got better.

But now there are other benefits to C++, the CPUs got twice as fast each year, but how quickly you can access stuff in memory only just got a little bit faster every year. Now a lot of your application is actually bottlenecked by just fetching memory from RAM. C++ gives you the control to lay out memory however you like and have like very small data structures, increasing performance.  The power it gives is now back in fashion because of this.

Do you see Python overtaking C++ at Bloomberg?

You want something that will be fast to write, easy to test, and easy to deploy then Python probably beats C++ in that case. I think there'll be a bigger push to using languages for what they should be used for and if you need the speed then you write that little bit in C++. There's a few languages that are talking about the C++ killers. I think Rust is an interesting one to look at because it tries to solve two of the problems that C++ has, one is sort of memory safety, so the idea is that you'll never be able to access memory incorrectly, like de reference a null pointer, access memory after it's been freed and Rust tries to do this at compile time statically. And this has got the backing by Mozilla and they've been writing parts of Firefox in this, or the servo engine. So that will be interesting to see if that fills like a nice niche that C++ does. But C++ is far from dying, there's so much lines of code that even if no new applications were being written, which is far from the truth now, it will be alive for another 50 years quite easily.

What are some other challenges with maintaining – and adding, I suppose – to such a huge library?

It's always a challenge to maintain programming interfaces, like API compatibility, while making improvements to all of our users. It's a half-technological, half-people problem.

For my team, one of the biggest challenges is how you can improve things while still maintaining interface compatibility with your library. You write a library, this function does one thing, and you have a large number of Bloomberg applications using that thing. If you want to make that better, let's say it doesn't work in a certain situation or it could be better, how do you do that without breaking all these applications?

In the outside world you can just create a new version and it'll be up for all of those teams to just say, "Right we're going to use version two instead of one." They make the choice. But doing this would require us to now ship two versions of our libraries to all of our clients, increasing the file size. We tend to just try and update all of the people using our stuff to the latest version.

"It's always a challenge to maintain programming interfaces, like API compatibility, while making improvements to all of our users. It's a half-technological, half-people problem."

Is there potential for things to go wrong?

Very rarely things go wrong that hit clients, or a large number of clients. Our library gets compiled into a terminal, it gets released internally to all Bloomberg users and that’s usually when you see any problems. But any complex changes we deem to be dangerous will be on a switch in the code and we can set it to true or false on the server. Even if we shipped a version that had the bug, we can just turn if off on the server and we'll try again for the next release. So even if something breaks it's a very painless for us to disable them in that case.

What’s on the horizon?

I still think there's a huge amount of stuff we can do for our library. It needs to be faster. It's effectively a real time SQL query. The problem we're trying to solve is: You have tables of data, constantly changing data like latest stock prices, trades, all of this stuff and you need to display this to Bloomberg Terminal users who need real time data and to be able to sort, filter, and join in other data.

Our library allows the developers to say, "Here's a table of live data, that’ll be updating, I need to join them together, filter, sort, do all of these transformations and then just display it to the user." Five years ago people were saying, "Well we may need 5,000 rows in this. With 20 different bits of transformations." And now today they say, "Well we need 50,000 rows with potentially 100 different components of transformations."

People also want to run more applications at the same time, so we're constantly trying to enable more complex use cases by being faster and we've got very cool ideas what we want to do in the future. There's going to be enough work for us for a while and I would really love to see some of those stuff through.

Do you code in your spare time?

I still like to code a lot in my spare time. It was a point where I would come home and I would code and then I'd eat and then I'd code and then go to sleep and then go back to work the next day. I do really enjoy programming. Years ago it was sort of working on my own projects,thinking, "This technology was cool, let's go play around with it, learn a bit more." At the moment I'm actually doing more work stuff at home. No one’s forcing me to do that, it just happens to be that there are some really interesting problems that we've got at work and my brain doesn't care if I'm doing work or stuff for myself - if it's a fun programming project then I enjoy working on it.

---

At Client Server, we are driven by technology but powered by people. With more than 300 live jobs - including many in C++ - your story starts with a click .

---

Driven by technology, powered by people

About Us

Meet the Team

Our Blog