Which programming languages do you use?
“We primarily use Golang, as well as Ruby on Rails and JavaScript. We are working hard on deprecating any presence of legacy Perl code.”
—Shweta Saraf, Director of Engineering, Cloud Networking at DigitalOcean
“At GitLab we use Rails for the backend, JavaScript with Vue.js for the frontend, and Go for microservices.”
—Filipa Lacerda, Senior Frontend Engineer at GitLab
“Glossier uses Ruby for our backend code, and JavaScript on the frontend. Our retail stores run a point of sale application for iOSwritten in Swift. We also use Python in our data pipeline.”
—Christopher Wright, VP of Engineering at Glossier
“My team primarily uses Python for development.”
—Neha Singla, Engineering Manager at Optimizely
“I predominantly use Python, but since Sauce Labs is open to having teams own their own parts of the code and product, I’ve also been building in Golang for our newer tooling.
“It can be difficult to pinpoint a universal programming language at Sauce Labs. Projects are all over the map and require different expertise, from Android emulators to iOS simulators and a litany of operating systems.”
—Pamela Prosperi, Senior Software Engineer & Developer Lead at Sauce Labs
“We use Swift, Objective-C, Java, Ruby, JavaScript, and Python.”
—Angela Yu, iOS Development Instructor on Udemy
“C is where my heart is, and it’s what I use for almost all my work. I use a smattering of different languages for other small bits and pieces, but I like them for different reasons. Those are domain-specific things, like build systems and lexical analyzers. I really enjoy those.
“We don’t just use languages; we make them. Languages are invented for particular reasons; different things suit being expressed in different languages. If a particular concept is awkward to express, sometimes it makes more sense to invent a language where it’s more natural to say whatever you’re saying. Then the problem is reduced to just making that language exist. That might sound hard, but it can be simpler overall, because you’re not trying to shoehorn something into a box when it doesn’t fit.
“Lots of code is computer-generated; only some is written by humans. So it’s helpful to give convenience for humans, since we spend more time trying to understand code than computers do. A lot of my work is in that area.”
—Kate Flavel, Engineering Director at Fastly
Why do you use them?
“DigitalOcean is a huge contributor to Golang and open source, and has sponsored GopherCon for several years. We chose Go due to its simplicity, scalability, and automatic memory management.”
—Shweta Saraf, Director of Engineering, Cloud Networking at DigitalOcean
“GitLab started as a Rails application, and the frontend was built with CoffeeScript and jQuery.
“Nearly two years ago, we started to change the frontend codebase. The first thing we did was replace CoffeeScript with JavaScript. With the new ECMAScript specification, we were able to use the same features CoffeeScript provided without the burden of using a new tool. It was also a lot easier to find developers with good JavaScript knowledge than with CoffeeScript knowledge.
“We later added Webpack to enable us to start slowly splitting our code and removing it from the global scope. We also started using Babel to enable us to use ECMAScript 6.
“As features became more complex, we felt the need for a UIframework that handled the data bindings and DOM updates for us, and that was when we started using Vue.js.
“The same thing happened on the backend. As we grew, we felt the need to create contained microservices with fewer dependencies, which would be easier to maintain. Go enabled us to write performant code, and made it extremely easy to deploy the binaries. One of the main reasons why our CI Runner was built in Go is because it enables us to prepare a statically linked binary for different platforms, allowing us to use the same codebase while still having it run in different operative systems.
“A short learning curve was also an important factor in our decision to use Vue.js and Go.”
—Filipa Lacerda, Senior Frontend Engineer at GitLab
“Glossier is based on an open-source ecommerce platform named Solidus, which is built with Ruby on Rails. We initially chose this because it was a safe bet for us to go to market quickly. Some years later, the bulk of our systems are written in Ruby and JavaScript—they’re good general-purpose languages with strong community support, and our team is experienced using them in production.”
—Christopher Wright, VP of Engineering at Glossier
“Optimizely’s engineering teams primarily use Python for historic reasons. Our founders, Dan Siroker and Pete Koomen, opted for Python as the primary programming language from the beginning. We’ve been rolling with that ever since!”
—Neha Singla, Engineering Manager at Optimizely
“I don’t come from a Python background, but when I joined Sauce Labs, their full stack for the backend was 100 percent Python, so I needed to learn it. Other languages, such as Node, Ruby, and Golang, are used on a case-by-case basis. Additionally, because we work so closely with Appium and their team, JavaScript is used to provision Android and iOS devices.”
—Pamela Prosperi, Senior Software Engineer & Developer Lead at Sauce Labs
“A large part of my work involved consulting on iOS apps and teaching iOS development, so Swift and Objective-C are unavoidable. Having said that, Swift is a beautiful language and one I’ve chosen to use for some non-standard usage. It’s type-safe, allows multiple return values, and has a real functional flavor to it. It’s a language that’s worth getting to know, even if you never plan on creating native iOS apps.”
—Angela Yu, iOS Development Instructor on Udemy
“I think people are tempted to say speed when it comes to C versus anything else. That might be true, but it’s not what’s at the forefront of my mind most of the time. I hear people attempt to rationalize their preferences after the fact with attempts at cold technical justifications for features, facts, and coverage. But that always seems like it’s something that’s done after the choice was already made; it’s a way of convincing yourself the choice was a good choice. I don’t buy it.
“I feel like I’m expected to pick a language just because it’s objectively suitable for a task. I think that’s a terrible idea. My usual advice is to use what you enjoy. Because if you don’t enjoy what you’re doing, why are you doing it?”
—Kate Flavel, Engineering Director at Fastly
What challenges did you run into when choosing these languages?
“While we have avid Go programmers on the team, we also hired a lot of experienced people who were initially not very familiar with Go, but who knew C/C++ or Java. We faced some initial resistance while integrating the Go coding style guidelines. We also had to encourage programmers to invest in learning it.”
—Shweta Saraf, Director of Engineering, Cloud Networking at DigitalOcean
“Adding new tools to a big codebase has some challenges, especially when you don’t stop the development of new features while adding them.
“We believe in adding value to our product by shipping new features fast. To do so, we had to compromise on not having a perfect codebase when we added a completely new stack to our frontend codebase. However, we were able to keep improving the codebase steadily, release after release. For example, we weren’t able to use the code-splitting feature when we first added Webpack, but doing so enabled us to break our code into modules instead of having it in the global scope right away.
“Because we iterate so fast, it was also easier for us to make some minor adjustments until we reached an architecture for our Vue applications that we were happy with. This made the process of adding a new library a lot less expensive.”
—Filipa Lacerda, Senior Frontend Engineer at GitLab
“None to speak of.”
—Christopher Wright, VP of Engineering at Glossier
“While we use Python for historic reasons, my team loves how general-purpose it is—it solves all of our current use cases. To date, we haven’t really run into any Python-specific issues or challenges.”
—Neha Singla, Engineering Manager at Optimizely
“I started in web development, then transitioned to native mobile development, mostly for Android devices. Needless to say, I came from a Java and JavaScript background. Moving to my current role was challenging because it was a more backend/system style.
“The biggest challenge is that when writing backend and pipeline code, you aren’t armed with the same functionalities and you use different processes. Fortunately, Python is straightforward and the syntax isn’t overly complex.”
—Pamela Prosperi, Senior Software Engineer & Developer Lead at Sauce Labs
“The challenge is always to overcome your bias towards programming languages that feel similar to something you already know. Coming from an OOP background, I’ve had to fight the urge to just do everything in an OOP pattern, even if I’m dealing with a functional language.”
—Angela Yu, iOS Development Instructor on Udemy
“C in particular has a reputation for being unforgiving, and for people having to write a lot of the supporting groundwork that comes for free in other general-purpose languages. I think of that like translations for human languages: You can indeed make a literal translation, word for word, from one language to another, but the structure and concepts differ. Those literal translations end up being awkward and lengthy, because they recreate the groundwork from one language in another language. That’s what people are doing when they provide their own recreations of other languages’ generic types and memory management in C.
“Instead, I encourage people to aim for writing code “natively” in each language, in a way that works with whatever the language provides. In C, I find it’s quite rare that I really do want to build strings dynamically—the things that people seem to complain about just don’t seem relevant when I’m writing in a way that fundamentally suits the language.”
—Kate Flavel, Engineering Director at Fastly
How does language experience factor into your hiring? Do you require existing experience? Do you provide structured training?
“We do not expect anyone joining my team [Cloud Networking] at DigitalOcean to know Golang or be an expert in it right off the bat. We have a comprehensive 10-week onboarding plan that is tailored for every engineer who joins the team. One of the first assignments is to get familiarized with Golang and then write a program, deploy it on a staging cluster, and test it. We also provide a benefit where employees get a free Kindle and access to books related to their role. This serves as a good starter for anyone new to Go.”
—Shweta Saraf, Director of Engineering, Cloud Networking at DigitalOcean
“On the frontend team, the language itself is a big requirement. It is essential to have concrete knowledge of JavaScript core features, as well as a good understanding of how the browser works. We don’t require previous knowledge with a specific framework, but having some experience with the stack we use is always a plus.
“We don’t provide structured training for the frontend stack, but we provide extended documentation on how we use the tools. We also require everyone, with or without experience, to take the time to read through the official documentation for each tool.”
—Filipa Lacerda, Senior Frontend Engineer at GitLab
“We use a candidate’s language experience as a starting point for a conversation in the interview process. If they have a long history of working with statically typed languages, is a dynamic language like Ruby going to feel liberating or frustrating for them? Are they interested in learning? The experience isn’t a hard requirement, but we do want engineers who are motivated to use the languages in our stack.”
—Christopher Wright, VP of Engineering at Glossier
“Python is one of the best options for a general-purpose language because it’s versatile and easy to use. I believe that if you know any other object-oriented programming language, you can incorporate Python with little training. Unless we have a specific requirement for a specific project, I gladly accept candidates who do not have existing Python experience.
“At Optimizely, we guide engineers who have little to no Python experience through tutorials, tips, feedback, and code reviews, among other things. While we do not provide any formal training, we expect the engineer to ramp up themselves using the various resources we have available.”
—Neha Singla, Engineering Manager at Optimizely
“We’re very careful about writing our team’s hiring posts and formulating requirements for job listings. Because Sauce Labs is so diligent, we’re able to pull from a variety of technical backgrounds. As a whole, we prefer great attitudes and people who can bring a new dynamic [to their team]. This recipe helps keep our internal culture thriving.”
—Pamela Prosperi, Senior Software Engineer & Developer Lead at Sauce Labs
“When we hire development instructors, we look for extensive language experience. Otherwise it’s difficult to understand the nuances of a language well enough to teach it to students. But for development projects, we’ve often trained people from cross-platform backgrounds for native development, and vice versa. As with mobile development, the large hurdle is mostly around knowledge of Android and iOS APIs rather than anything specific about the programming language.”
—Angela Yu, iOS Development Instructor on Udemy
“The main languages we use at Fastly are general purpose, so it’s not the languages that matter, exactly, but the kinds of experience people have working on particular kinds of things. I’m especially interested in how people approach thinking about interfaces and responsibility, and their having a feel for what information should live where.
“We have customer support engineers who do write code and work with customers’ code. I’m pleased that we do support them moving into engineering. It’s wonderful to see that development, to see somebody’s personal and technical growth.”
—Kate Flavel, Engineering Director at Fastly
Which languages are supported (have company tools written in them) vs. unsupported?
“Go, Perl, C++, Ruby on Rails, and JavaScript are supported. For unsupported languages, there’s no hard blocker.”
—Shweta Saraf, Director of Engineering, Cloud Networking at DigitalOcean
“We have tools written in Ruby on Rails, Go, and JavaScript.”
—Filipa Lacerda, Senior Frontend Engineer at GitLab
“We support Ruby (backend), JavaScript (frontend), Swift (iOS point of sale application), and Python (data).”
—Christopher Wright, VP of Engineering at Glossier
“We have company tools written in Python and Ruby.”
—Neha Singla, Engineering Manager at Optimizely
“While the main backend at Sauce Labs is written in Python, our image building is done leveraging tools like Packer and Jenkins with Ansible playbooks. There are some Node and Python scripts in the middle, as well as image testing in Ruby.”
—Neha Singla, Engineering Manager at Optimizely
“We have major systems in C, Go, Ruby, and a surprising amount of Perl. It’s probably a bit unusual for a company dealing with web-related content to have so much code in older languages like C and Perl. But the thing that steals the show, for me, is VCL (the Varnish Configuration Language). That’s the language through which customers configure our system.”
—Kate Flavel, Engineering Director at Fastly
Is your current language your “forever” language, or do you anticipate switching at some point in the future?
“Nothing is forever. Technology is always evolving at lightning speed, and I encourage engineers to keep an eye on industry trends and learn new languages. That being said, we are invested in Go for the near future.”
—Shweta Saraf, Director of Engineering, Cloud Networking at DigitalOcean
“Forever is a very strong word. When it comes to web development, things change very fast! I don’t think we intend to change either languages or tools in the near future. Thankfully, nothing is written in stone, and if the time comes when such a change would empower us to achieve more, I’m sure we will consider it.”
—Filipa Lacerda, Senior Frontend Engineer at GitLab
“Looking at Glossier’s roadmap, our current set of languages are a good fit for the challenges we’re facing. I’m sure we’ll hit a point in the future where a problem is clearly better solved using a different language; we want to approach these choices pragmatically.”
—Christopher Wright, VP of Engineering at Glossier
“We want to break our monolithic codebase into services. When we embark on that project, we will revisit what language and tech stack makes the most sense for each service.”
—Neha Singla, Engineering Manager at Optimizely
“Because technology changes so rapidly, developers need to grow with it. Because of this, “forever languages” aren’t effective. Keeping yourself up to date with the latest technologies and languages is crucial to becoming a better engineer. I’m fortunate that Sauce Labs allows me to explore and stretch beyond my comfort zone.”
—Pamela Prosperi, Senior Software Engineer & Developer Lead at Sauce Labs
“No language is a forever language. I’m personally not that emotionally attached to any particular programming language. At the end of the day, it’s just a tool: If a better hammer comes along, I’ll use that hammer instead.”
—Angela Yu, iOS Development Instructor on Udemy
“Personally, for general-purpose coding, I’ve tried to enjoy a few of the popular alternatives, but nothing suits my natural way of thinking quite like C does. It’s like coming home.”
—Kate Flavel, Engineering Director at Fastly