First blog post! Here’s something about concurrent-ruby…
By: Michael Wagner
Tags: Programming, Ruby on Rails, Ruby, Rust

Ruby Language

Hello and welcome! I’m Michael Wagner, a software engineer at a startup in Charlotte, NC, called Investor Management Services (IMS). I do mostly Ruby on Rails and Javascript frameworks like AngularJS and ReactJS. I’m also an avid learner in newer programming languages and other technologies such as Rust, Crystal, Kotlin, and many more. I’m always interested in learning new things that I can take back and apply to whatever I’m working on, both inside and outside of work. Now, enough about me, let’s move onto what I started this for!

At IMS, we use ruby gem called concurrent-ruby to handle mostly async work, like Promises, as we’ve found them to be an easier solution to manual threading in ruby. However, something I discovered this week was that they have a Maybe implementation included with the library.

Now, if you’re not familiar with what that is, here is some context: In most programming languages (Java, Javascript, Python, Ruby, etc.), they have a concept of a nothing value, a value that represents essentially nothing. null , nil , undefined , None are all values that represent nothing. This all seems well and good, however, it has been criticized ever since its’ inception, even by the creator himself. My main takeaway from having a value that represents nothing and trying to develop code with it, is that most languages don’t guard you from getting this value, they expect you to handle what happens by yourself or even encourage its’ use. The most important thing about using a nothing value is to document that something might return it, otherwise it might fail when you’re least expecting it.

However, a Maybe implementation takes a different approach. Instead of dealing with code that works and sometimes returns nothing at moments notice, you get a maybe, which contains either the result or nothing. Makes sense right? How is this different? Well, for one, you now have to check what the result was before moving on, instead of assuming everything was all good and you get a error down the road. And for second, your code is much more clear to the end user, especially if you are passing a maybe around, because now they can decide what to do if something didn’t work. I find this to be a much better alternative than accepting that something could fail and possibly swallowing the error. Here is a quote from concurrent-ruby about their Maybe implementation:

A Maybe encapsulates an optional value. A Maybe either contains a value of (represented as Just ), or it is empty (represented as Nothing ). Using Maybe is a good way to deal with errors or exceptional cases without resorting to drastic measures such as exceptions. Maybe is a replacement for the use of nil with better type checking.

In some languages like Rust, a nothing value doesn’t even exist. Meaning, it might have a type of nothing, but you can’t use it as a value, where-as you can in those other languages. This was something I really enjoyed when I spent some time last year learning Rust, the idea of handling for these kinds of edge-cases. And I was so happy to see I could use something similar in Ruby as well!

Thanks for bearing with me on my first blog post! I plan to write about something every week, on what I’ve learned. I know there wasn’t any code examples in this post, I promise to try to add some in the future. I hope you enjoyed this and have great day!