iToto's Blog

A Montreal based full-stack web developer who loves learning and trying out new things. This blog is my attempt to document my work as well as a place to discuss ideas or topics that I find interesting. Feel free to follow me on linked social networks.

The Java Experience

Over the past year, I've gone through some interesting changes. I started working at a company called ViralNinjas as a full stack php web developer. Most of my strengths being on backend development. Over the years, the company has gone through a lot of changes. We merged with a US company in San Francisco - called Sociable Labs. We created a brand new product as a SaaS using a Service Oriented Architecture (SOA). So, we essentially moved away from the LAMP stack to a SOA consisting of: Java, Kafka, Hadoop/HBase, Redis, PSQL for customer configurations with JS and OjectiveC for the clients. Not to mention all the changes we went through in the work force. While all were fun and exciting, the biggest for me - as an engineer - was the move in tech stack.

New and different

Moving to Java was a little intimidating at first. I haven't done any Java since some CLI programs I did back in college. Working on a large and scalable web system would be a whole new adventure. One that I was very interested in experiencing. Coming from years of PHP development would mean that I would have to change my train of thought from a loosely typed interpreted language to a strict/strong type compiled one.

Strong VS Loose Typing


public static int minFunction(int n1, int n2) {
    int min;
   if (n1 > n2) {
      min = n2;
   } else {
      min = n1;
   return min; 


function minFunction($n1, $n2) {
   if ($n1 > $n2) {
      return $n2;
   } else {
      return $n1;

There are obvious arguments for both sides. Strong gives more reliability and generally leads to better code that is easier to maintain and tends to be less buggy. Whereas loose allows for more flexibility and can be easier to write – as you don't have to worry about converting types in order to make things work. While I was coming into the static world from the dynamic one, I immediately noticed the benefit of something as simple as a return type. I found that knowing the types of the input and output of functions was extremely useful. Also, knowing what the types are allows you, as a programmer, to understand what state everything is in at any given point in time. Without it, data can come in as different types (which happens often) and can throw you in a different state - forcing you to have to put type checks everywhere.

There are many other advantages to strongly typed languages which we will touch in a little later, but for me this was a huge positive in favor of Java. At this point, I had decided that I was done with loosely typed languages.

Interpreted VS Compiled

Another advantage of using a strongly typed language is that a compiler can run through it and compile it down to machine code. Meaning execution of your program will be much faster as there is no conversion needed and the computer knows what to expect from the execution of your program. On the other hand, an interpreted language needs an interpreter to run through the code as it is being executed, it evaluates and compiles down to machine code on-the-fly. This generally means slower processing time, but the flexibility of executing different code without having to re-compile.

Aside from the pain of having to wait for compilation (which can take a while depending on the size of the project + dependencies), I still favor the speed and simplicity of deploying a compiled binary file versus an entire code-base to remote server(s).


Here is where my appreciation of Java started to wear thin. Because everything in Java is an object, you start to start to see things like:

Logger logger = Logger.getLogger(loggerName);

Which is fine, but when you keep seeing all these design patterns being used that start to make programming a simple program more obtuse and yield code that is harder to read, I feel like it starts to get more in the way of the programmer then to help them. I had found a really good response to this on Stack Overflow:

What it really boils down to is that verbosity is good when it clarifies the programmer’s intentions, but bad when it just adds noise to a construct that has nothing to do with the programmer’s intentions. I believe that Java has plenty of the latter kind of verbosity.

That is exactly how I feel about Java and it's verbosity.


In conclusion, I must say that working on this project has matured me as a web engineer. Working with SOA and the new tech stack has allowed me to learn about how to build reliable, scalable and better performing web systems for modern applications. It also made me realize how much I prefer strongly typed languages over loosely types ones. Although Java seemed promising at the beginning, I still found some things about it that I did not like. Interestingly enough, during this project, I had also stumbled on Golang. Ironically, it seemed to have all the things that I love about both languages, and none of the bad stuff. It might have been the timing, but once I discovered Go, I immediately felt that it was the language to rule them all!