Adopting a New Programming Language in your Enterprise: Pains vs Gains

Adding a Programming Language in your Enterprise

ActiveState knows from our 2018 Developer Survey that one of the hardest things an enterprise can do is to adopt a new programming language. 67% of you told us you wouldn’t add a language because of the challenges:
2018 Developer Survey: Adding a Language Results
The overhead associated with adding a new programming language can be prohibitive, including:

  • Education – all of your developer, DevOps and other teams that touch code will need to learn a brand new language, as well as any new tooling that language entails.
  • Tooling – from IDEs to testing, depending on what you’re already using, you may need to either extend or entirely replace your toolchain.
  • Workflow/Processes – some languages are more flexible than others, and may well fit within your existing Software Development Lifecycle (SDLC). Others may require you to make extensive changes.


While some of us appreciate structured courseware, others find it a slog.



However, the tried and true formula of “learn one; do one; teach one” is still the best learning method. Here, the team member with the most knowledge of the language brushes up on her skills, tackles a real world problem that the team is currently working on, and then teaches the rest of the team how she did it. Learning directly from your peers using examples from work you do every day will significantly speed up language adoption.


Sometimes the tooling you’re already using can be extended, easing developers into the new language by providing familiar tools. You’ll gain lower friction adoption with less of an impact to productivity. Other times you’re going to have to suffer the pain of not only learning the new language, but also the new tooling that goes with it.


Consider the example of an enterprise adding Python to their existing Java skills. There are a number of Java tools that either directly support, or can be extended for use with Python, including:

  • IDEs like Eclipse, JetBrains IntelliJ and ActiveState Komodo
  • Code Repositories like Git and Apache Subversion
  • Binary Repositories like Sonatype Nexus and JFrog Artifactory
  • CI Tools like Jenkins, CircleCI, or TeamCity can all integrate tests for both Python and Java
  • Code Quality tools like SonarQube and Veracode, which also offer integrations to both IntelliJ and Eclipse
  • Automated Testing tools like Selenium


Some tools should remain dedicated to each language. For example:

  • Unit/integration/functional testing tools should be dedicated to each language, but can be driven from common automated tools. For example, Selenium integrates with PyTest for Python testing.
  • Build tools like Make and Bazel can build both Python and Java, but most Java-centric enterprises are more likely to be using Maven, Gradle or Ant. Unfortunately, there isn’t a one-to-one replacement for something like Maven in the Python world.
  • Polyglot IDEs often have a main language they favor. For example, PyCharm (JetBrains’ dedicated Python IDE) is updated faster than the Python plugin for their polyglot IntelliJ IDE, but will entail a productivity hit as your developers ramp up.

Workflow/ Processes

The majority of programming languages follow a similar, standard software development process, from versioning to building/testing to packaging/deployment. However, there are some key considerations to be aware of depending on the type of language you choose:

  • Build processes for Compiled vs Interpreted languages – i.e., while interpreted languages don’t require a build per se, they will require new dependency management, testing and packaging methods that a typical build process includes
  • Quality of Statically- vs Dynamically-typed languages – i.e., the maturity of a statically-typed language like C or C++ with proven quality tools vs the immaturity of the latest JavaScript framework may impact your maintenance & update resources and processes

Language Distribution


  • Community – free and ubiquitous, since it probably came with your OS. A great way to get started learning the basics.
  • Commercial – vendor-supported distro that typically includes a number of popular, third-party libraries. Best for exploring the language and its ecosystem.


  • Do-It-Yourself – don’t! There’s no need to get into the complexities of building your own language distribution when you’re just starting out.

Want to take a deeper dive into real-world best-practices for adding a new language in your organization? Check out my recent Webinar with expert panelists from Manulife and GSI Technology. Watch On-Demand.

Watch Webinar

Recent Posts

Scroll to Top