Speaking Developers’ Love Languages

Developers are a finicky breed, especially when it comes to the languages they code in. And, while they don’t always get to use the languages they love most, there are still factors that give them an affinity toward certain ones and keep them coming back for more – whether for personal or corporate projects. In light of our ongoing ‘Go Week,’ we sat down with three Checkmarx software developers – Daniel Novais, Samuel Ferreira, and Jose Pereira – to learn a bit more about what makes them tick, their favorite programming languages, best practices for coding more securely, and much more. Read on! Thank you all for joining me! Let’s start with a brief introduction – tell me a little about yourselves and your roles here at Checkmarx. Daniel: I’ve been with Checkmarx for about four years, starting as a developer and working my way up to team leader. I primarily work with C# and have recently gotten into Golang due to my involvement in the support enhancements for Checkmarx’s CxSAST product. Samuel: I joined Checkmarx as a developer three years ago and have been focusing on our Framework Factory project for the past year-and-a-half, which provides quicker support for frameworks in CxSAST. Similar to Daniel, the majority of my work is with C#, although I spent a large amount of time with JavaScript when I was fully allocated to Framework Factory tasks. Jose: Pretty similar to everyone else, I’ve been with Checkmarx as a developer for four years and specialized in software quality and language compilers back in college. Since joining the team, I’ve worked on a bunch of languages ranging from C++ to JavaScript to Kotlin. I really enjoy the R&D side of things and seeing how the features of different languages converge and adapt. How do you decide which programming language is appropriate for a specific project you’re working on? Daniel: Typically, projects we work on aren’t tied to certain languages. However, certain languages are more applicable for certain projects, if that makes sense. For instance, if I wanted to make a web application, I would use React or Node.js. If I wanted to make a desktop program that works locally, I’d use Java or C#. Samuel: In my case, the biggest parameter is project size. If it’s something for myself or a few people, I’ll probably use a scripting language like JavaScript or Python. If it’s for something larger, I’ll use a strongly typed language like Java or C#. The reasoning revolves around safety – not in a traditional security sense, but rather because strongly typed languages mitigate the risk of crashing due to programming errors. Jose: For me, it’s all about the team. If it’s just for you, it’s one thing, but if you’re doing it as a team, everyone needs to be onboard and use a language that’s comfortable for the group. Like Samuel said though, certain languages are better suited for small scripts. And when you’re trying to achieve something more scalable that follows standards and practices, you’ll want to use more mature languages like C# or Java as there’s more documentation and well-defined standards. If you had to choose one language to use for every project, what would it be and why? Basically, which one(s) are your favorite? Daniel: I’d go with Go. I got to work with Go for the first time at Checkmarx when we started supporting it a few years back, and I was part of this initial team. Ultimately, this encouraged me to use Go for personal projects outside of Checkmarx. It’s a very versatile language, and the more you understand and use it, you understand how much it can be used for. Samuel: It’s a tough question, but if I had to choose, it would be Python. It’s very easy to write and read your code, debug it, install external dependencies, and more. It’s extremely accessible and quick to use. As a scripting language, it can’t be used for everything, but I’d say Python nonetheless. Jose: I’m going with Kotlin. I started to use Kotlin when a project at Checkmarx was presented to me and I needed to start learning it. It was very smooth to learn, very cool – the syntax is very neat to write and read. It’s also from JetBrains, which I’m kind of a fan boy of. Kotlin’s grown a lot since 2011 when it started as a JVM language and has since gone cross-platform. You can develop native apps for iOS, Linux, and more. Also, the language itself is very well thought of by most developers and has been a pioneer in simplifying and cutting down typing inferences, which every language is moving toward. Standards and documentation are still growing a lot, and it’s very important to continue to define this. Since we’ve dubbed this ‘Golang Week’ here at Checkmarx, we have to talk about Go specifically! It seems to be rapidly rising as a preferred language for developers. Stack Overflow’s survey saw it jump five places into the top five ‘favorites’ list this year. Why is this? Daniel: The main thing with Go is that it’s very versatile. Additionally, it’s a language by Google, so developers can trust it. They provide a lot of libraries, and anything you want to make the hard work is already done, you just have to pick the best packages. Go is a language that’s very easy to set up. You can quickly open up a file in Go, and in just a few minutes have a project up and running. That’s huge. Samuel: Personally, I haven’t programmed in Go language specifically. But I do know that Go is very well-suited for microservices-oriented applications, which is a real trend in recent years. That’s really one of the reasons that Go has seen such a boost in terms of popularity. Jose: You can tell that Go was born with efficiency in mind in an age where multiprocessors are rising. Current software and programming languages aren’t well-suited for these kinds of architectures. Go is very optimized for this with Goroutines. It’s very efficient for concurrency programming, which is the future. From a security standpoint, are certain languages more secure compared to others? Which ones and why? Daniel: In a sense, yes. Some of it depends on what the language is being used for. If it’s something for a webpage or database, those languages are more secure in general. However, the security of a language itself isn’t everything. Even though some languages may be more secure, it ultimately falls on the developer to ensure its being used in a secure manner. Samuel: From a security standpoint, the actual language isn’t as important. To Daniel’s point, what matters is the developer’s knowledge about what he/she is doing and the libraries and frameworks used to interact with databases, render webpages, etc. In terms of how I stay up-to-date on security issues, as Checkmarx employees, we have a lot more knowledge than developers from other companies since we have access to Codebashing. I’ll also follow websites and news sources that publish news about emerging vulnerabilities in languages. Jose: I have the same opinion as Samuel and Daniel. It’s not about the language itself, but rather about the developer knowing what they’re doing and the open source software they include in their program. Every day we see news about libraries that are vulnerable and people introducing malicious software into them, and thousands of people are using these. It’s very dangerous and something we need to work on. It’s a mindset – every time you’re contributing to a source code, you must ask yourself “is there a way someone can attack me with what I just did…is there a vulnerability here?”   What are some ways developers can code more securely? How does Checkmarx AST come into play and what makes it unique in this regard? Jose: Checkmarx is great for this – it’s our business. Having a tool like this run on your CI pipeline every time you do a commit, and coming back to you with a report with issues or potential issues, is invaluable. It will get you to think about what went wrong and how to better yourself. Resources like Codebashing will help you learn about the issues and decide for yourself if you’re actually vulnerable or not. If you don’t have Checkmarx, you have to develop those instincts yourself – start improving your code reviews, select people with specific mindsets that ask the questions that matter (are you staying safe, is your database protected, etc.). Daniel: Jose said it all. Using a tool like Checkmarx is the second step after your own knowledge on security. You have to know about security and protect yourself using the knowledge you’ve gained. Even if you don’t use Checkmarx, use another open source tool. Also, have code reviews, AppSec experts on your teams, quality components – all of this goes into creating secure programs. Samuel: Agreed with everything. Although it’s worth adding that having Checkmarx in your CI pipeline is valuable because even if developers in a company are aware of programming securely, sometimes, one person might in a rush to fix a bug or implement a feature. That one time they might not think to look twice about security and won’t be automatically notified about it. That’s the value of Checkmarx. What does the future of coding look like to you? Which languages do you see yourself falling in love with? Falling out of love with? Daniel: In the past 10-20 years, we’ve seen a boom in programming languages. In the coming years, we’re going to see some stabilization with languages converging. Languages like Go and Kotlin are here to stay. Samuel: Looking to the future, features like Jose talked about such as concurrency will introduce complexity. It’s harder to program that way. So one day we’ll become abstracted of those details and won’t have to worry about concurrency. I also think low coding development platforms will be a strong investment and eventually become an industry standard. Jose: The giants will stay around for a while – just look how we’re still working with COBOL after 60 years. We’ll certainly be dealing with a lot of Java and C#. C++ will make a comeback due to all the concurrency. Python and Go will start to grow up a little, and if they’re designed carefully, people will adopt them because developers love learning something new. Any advice you’d share with young, up-and-coming developers? Daniel: Never stop exploring or working with new languages and frameworks. New doesn’t always mean better. Many times it doesn’t. But you have to keep an eye out on what’s trending to find new things that you enjoy working with to become a better and more productive developer. Samuel: Agreed with Daniel. Additionally, I’d advise younger developers to get to know one strongly-typed language really well like C# or Java, and after you’re really comfortable with that, start exploring and expanding. At that point, you’ll already know how to program and will just need to learn new syntaxes and features that new languages have to offer. Jose: Regardless of the language you pick, be proactive about learning the security aspects, not just the functional part. There’s a bunch of concerns you should have that will make you a much better developer versus just having your program work. Interested in learning more about Checkmarx and the languages we support? Visit here. And, make sure to check out our newly published ‘Golang Guide’ here.