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. When I try a new language, I want to get past the toy examples and see what it’s actually like to develop. 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. I spent about an hour reading through docs & examples so I have a rough idea where I can find answers when I get stuck, but I learn best from action, so it was time for the rubber to meet the road. For people who can’t resist spoilers, here’s the module I created during this process: thyme , and docs! . If you’re interested in reading the suggestions I compiled to improve the developer experience & adoption of Ballerina, you can find it here .
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.
I don’t have much to say on getting up and running, so I’ll leave it to their documentation on how to install the language and how to use the Ballerina CLI tools . The Quick Tour will get you the rest of the way with a slightly more advanced ‘Hello World’ to ensure things are working correctly before you dive deeper.
Kicking things off, I decided Dotenv
would be a good starting point. Dotenv loads configuration information from a
.env file into your process as environment variables. A simple concept, but it touches on useful topics to know in any language, like interacting with the environment your application runs on. I started off right away with writing tests and found it quite helpful, as it has forced me to not only learn how tests work in Ballerina but also tackle a variety of utility tasks you need when writing tests, like generating random numbers, handling errors, working with strings & arrays, and basic flow control. Handling errors is done explicitly, though initially it appeared you could cop out by adding
check before the operation, e.g.
int val = check iThrowErrors(). I was wrong.
Things went downhill quickly after writing some initial tests. Ballerina currently runs on the JVM and uses hooks into Java to handle some of it’s standard library functionality. From other languages I’ve used I assumed there would be easy access to environment variables, but there is no
setenv capability in the underlying Java package
java.lang.System. This Java Dotenv package
mentions the same issue, so hopefully I’m not missing something obvious. You could implement a rough equivalent by loading from a file into an object, but the Ballerina Config API
seems like a well thought out implementation along those lines, and making a crappier version of it didn’t sound all that interesting.
The lesson here? Check the most important functionality of your idea is possible before doing any of the other work. Luckily this is just for learning, so the time already spent on language features wasn’t wasted. That said, a pivot was required.
Though the main purpose is learning, I like to have at least a semblance of a goal to drive what I’m doing. The philosophy I took was to wrap and use the native classes as much as possible, making it easy to plug in, while abstracting the annoying bits of date time interaction so developers can get back to building their widgets. For this reason, I decided to build mostly module methods that accept & return the native
time:Time objects. I could have focused on only creating functions around my custom classes, but that makes it harder for someone stumbling onto your project to adopt it as they have to go all in on your implementation.
On to the experience of actually implementing. Error handling confused me for a good bit, I may just be dense but it tripped me up time and again even after reading the documentation. Their test suite examples could use some work, it doesn’t help me to know if you can print something before each function. I want to know how to do test setup and then be able to access those variables, it helps keep a codebase clean & simplify your test cases. I found myself searching through the repo a lot to answer my questions. I also attempted to use fixtures for tests, but as far as I can tell you have to have module global variables to assign to if you want to access anything generated in fixtures. Seems like a pain, maybe there is a feature of Ballerina I missed which passes context between. A few more small thoughts & concepts I ran into:
int, but occasionally is an error, well then return
int|error. It works even for something wild like
[string, int, int|error].
io.sprintfeverywhere to log variables. Not a huge issue, but really clutters up the space.
anyaspect, it’s powerful for dealing with maps.
int, you have to use the special
'syntax when importing:
anytype when trying to use
dataProvider.In docs , it says “The given Ballerina function should return an array of arrays (e.g., string for a test function that accepts string parameters). Each array of the returned array of arrays should have a length similar to the number of arguments of the function”. Looks like it doesn’t support
anythough. It would be super useful to be able to do this. Json is available as an option in their docs, which could be close, but it seems like overkill if you just want something simple like a
string. I wish I could have found that early on.
At this point, I had a decent chunk of a half-way decently tested module, and a lot of ideas about the language. There are a lot of improvements this module could undergo, but a short list would be better repo file structure, using logging correctly instead of
println() , better error handling within tests & adding more property-based tests, and adding more helper functions. It also could have used more of the fancy features available in Ballerina, like Type guards, Elvis operators, custom error types, binding patterns, and more.
After a few hours, I had successfully completed a not totally terrible module and published it to Ballerina Central. The final product is available at central.ballerina.io/i_dont_remember/thyme
. I really liked the built in support for a code coverage report as well as letting you write documentation inline. Anything to reduce the friction it takes to get more documentation for a codebase is a plus in my book. I had no idea what I was doing and was still able to generate useful documentation
to go along with my module. At first I was not a fan of the error handling system (I have to explicitly handle this again?!?!?), but it grew on me. Now I like it forces the developer to think through error situations and handle them, rather than hand-waving it away and hoping it doesn’t explode later. The Ballerina team wrote a 3 part series diving deeper into error handling
if you’re on your own learning journey. On a personal note, I think my approach to writing in Ballerina is heavily object-oriented (OOP). I tend to think in classes & objects, which might be at odds with how languages like Ballerina, Go, and others operate best. This is something I will need to dive deeper into to expand my personal skillset, as it would be good to understand how to switch thinking for languages that aren’t necessarily OOP. Adding a useful article on inheritance in Ballerina
. Of all the decisions the Ballerina team has made, it seems like the most valuable is their easy integration with Java libraries with the
bindgen tool. This opens the massive Java ecosystem for use, which I’m sure will help them in getting companies to adopt knowing they don’t have to throw out everything they’ve built.
It was interesting to give Ballerina a spin, though my personal goals will keep me with other languages for now. I have a strong feeling it will continue growing over the next few years. With a company backing it, WSO2, they have a strong base to keep it going through the early stages when a language is most likely to lose steam, so I wish them the best of luck with getting it off the ground and into mainstream production use. I also wrote up opportunities I noticed for Ballerina to tweak their developer experience & marketing to grow the community around the language. If you’d like to see my thoughts on what Ballerina can do to become a widely used production language, you can find it here .
It's so easy as a developer to dismiss the idea of learning no-code tools. After all, you know how to code, why spend time learning tools designed for those who can't?
Let's break it down and see how you only need 99 people's support for your side hustle to make a drastic change to your life.