How Ballerina Lang can Improve their Developer Experience & Adoption

I stumbled onto Ballerina a few months back during a random jaunt through the interwebs, and after digging through their site I was intrigued enough by their features & guiding principles to give it an expanded ‘Hello World!’ test. My current method is to build a very simple package based on a popular Open Source module from PyPi or NPM. This can be a handy learning strategy, as you don’t have to spend time thinking about what to build or features, you can just copy features directly from existing implementations and focus entirely on learning to put it together. You also go through the full cycle of building, testing, and deploying a module where others can use it, imitating a real world use-case. During this experiment, I noticed a few missing pieces across the developer experience and marketing which I felt could be adjusted, and in doing so have a greater impact on growing the community around the language. I pulled together my thoughts into what are hopefully coherent suggestions for the Ballerina team to implement. If you’re interested in just reading about my experience learning and building a module in Ballerina, check out Giving Ballerina Lang a Twirl .

What is Ballerina 🔗︎

Ballerina is a young language in development by the company WSO2, and is advertised as being “Developer First” and to have built-in functionality so developers have to spend less time worrying about how you can get your code deployed to cloud providers and many of the pieces of building maintainable & reliable applications like documentation & testing. As they say “We plumb, you build!”. I’ve probably butchered their marketing spiel, so to any WSO2 employees reading this, my bad. For the rest of you, go check out their landing page to see if Ballerina is a good fit for you.

Suggestions for Ballerina 🔗︎

After filtering my notes, I had a short list of constructive tweaks to help the growth of the language and build on the work the Ballerina team has already done. Some of these ideas could be done in a few hours, others are more general and will require deep thought to flesh out what action items could accomplish them. The suggestions for improving Ballerina fall into two camps. First, they team needs to convince people the language is ready for production use and not just a toy for developer entertainment. Show them it’s ready for production environments and improves time to market and companies will bite. Second, reducing friction during the initial learning process, the early stages of getting started with the language. Users are most likely to leave, never to return, in the beginning when they haven’t invested time & energy into a new skill or platform.

• Assuage concerns of Production readiness - Find ways to reduce people’s concerns of production readiness, because nobody wants to adopt a language and find out it can’t stand up to actual usage. Companies want to know the software they are running is dependable and their developers can quickly write quality code.
  • Document current production learnings - From reading Hacker News comments & articles about Ballerina, it sounds like WSO2 is already using it substantially makes sense since they are the creators. It would be worthwhile to document what they’ve learned so potential adopters gain confidence in the language’s ability to stand up in production. Can also discuss the ease of getting new apps from first commit to live for users.
  • Make production learnings standout - Have a section on your landing page discussing it, and link to a page going into much more depth. Increase people’s confidence from the start, and then provide them resources relevant for running in a corporate production setting.
  • Enhanced debug capabilities - It was pretty difficult for me to get any debugging going with Ballerina, this could have been failure on my part but others will run into the same issue and blame it on the language. Making it easier to debug will be crucial to get businesses to consider using the language for their developers.
  • Improved test suite documentation - I had many questions come up while trying to write even very simple tests, and they were not answered by the current level of documentation. It doesn’t help me to know you can print a value beforeEach function. I want to know how I can do setup & then have access to those variables? Ran into others like it, since the docs at the time felt very surface-level.
• Ballerina central has lots of noise - There are a ton of projects on there that are just the “hello world” module, even if you go to the homepage you see it. It is disconcerting to have the main page showing so few actual packages and doesn’t give confidence that I will be able to find the packages I need. NPM may have the same issue, I can’t say for sure, but if they exist they are hidden by all the bigger projects on the platform.
• Add more interconnections in docs & expand them - Make it as easy as possible for someone trying to work with Ballerina to find what they need. For example, each page of Learn By Example should link to the stdlib page. If i’m working with examples already, there’s a good chance I’ll need the docs to expand beyond them. I also found myself searching through the Ballerina repos a decent amount to answer my questions, which is a lot of friction when you are trying to get someone interested in your language.
• Reduce as much friction as possible during beginning stages - Developers will dig deep trying to solve bugs of their own creation, but much less so with setting up with a new language. It’s hard enough to get people interested enough to try it out, but they aren’t devoted to your cause enough they will work through issues just to play with the language. The sandbox helps, but it’s more important to support someone setting it up on their machine, since that’s where any real usage is going to happen. I personally ran into issues with Java versions on my machine causing problems, and though it’s not technically a Ballerina problem, it becomes one because it causes friction which stops people from going farther with the language. The solution could be as simple as providing suggestions of documentation to follow in case certain errors arise. It’s easy to shrug it off while thinking “people shouldn’t be dumb”, but that’s a great way to not have anyone using your product.
• Add Ballerina to more sites about programming - The project will die if it doesn’t get enough adoption. There are sites Ballerina can add themselves, like https://learnxinyminutes.com/ , which won’t take long to make but will add new sources of traffic & potential adopters. Especially the case for Learn X in Y Minutes, because it’s alphabetical and Ballerina will show up right near the top.
• Add indirect content marketing - The team is writing a lot of solid articles on their blog related to Ballerina, but that won’t pull in people who aren’t already interested in Ballerina. It seems like it would do well to write more articles not directly about Ballerina, but involve Ballerina and can gain traction. Find something popular people want to do, like ‘How to build your own Slack bot’ and then in the article it’s implemented in Ballerina. The reader has goals beyond learning Ballerina, but now they know maybe it’s worth learning to accomplish their other ideas.
• More dev-friendly & most-used libraries - Take a look at NPM, PyPi, and others and see what the most heavily used packages are and consider if it’s worth getting an initial implementation going in Ballerina. Stripe makes it incredibly easy to use their APIs & docs, and in turn developers love them. Follow that approach, but make sure to consider the 80/20 rule for effort vs reward, hence looking at the most heavily used packages. Make the most common 80% of tasks developers do a joy and they will be ecstatic.
• (Bonus idea) Native property-based testing - It probably wouldn’t be a huge driver of adoption, but it would be super cool to see a language natively supporting property-based testing . Encouraging people to write better tests by default would be a decent selling-point for those who care about code quality.

Whether or not these ideas get implemented, I hope they provide the Ballerina team some useful insight from a different perspective. Ballerina has a lot of solid founding principles, which is what drew me to initially try the language, and with a company already backing it they are starting from a good foundation to survive & thrive. I also wrote up my experience creating a module in Ballerina, where I came up with all these suggestions, so if you’d like to learn more of the developer experience while writing Ballerina you can check out Giving Ballerina Lang a Twirl .