So you had an idea, built a prototype, people started using it, now you decided to build something of substance. There are many shortcuts one can take during the development of a project but if it ever reaches the dreaded ‘Production’ than your needs go way beyond the usual I’ll just package it up and run it on my MacBook as a service. This book provides a comprehensive list of concerns and subconscious decisions that need to be made when building an internet facing production system and a product/company alongside it. We’re off! So hold on tight it’s going to be a wild wild ride.
The language and ecosystem
Choosing a programming language can be as simple as picking what you know best. That said as your company grows certain decisions will make your life a lot happier down the line. As you may know, some languages and ecosystems are a great fit, while other even if they might work, they would be a tight fit. An example even if you can run Node.js on an embedded system, doesn’t mean that might be the most sensible thing to do.
Things that need to be considered can be broken down into categories:
- The language
- The ecosystem
The programming language
Static typing or dynamic typing
Before we dive into the little research that is out there, let’s start with the basic premise. What static typing means that type checking happens at compile time, whilst in dynamically typed languages this only happens during runtime. In practice, this means that in some languages you explicitly have to declare types everywhere, or almost everywhere (different languages have different levels of type inference ). Okay, so what do we get for this in exchange? You get compile time guarantee for things like :
- Can we call this function with a parameter of this type?
- Does this method actually exists in this class?
- Can we assign the result of a computation to that variable?
I hope you see the general pattern it’s about verifying for the programmer that things actually line up. Some developers go as far as to say “If the types line up it’s guaranteed to run!"
- The research done in this area mostly provided inconclusive results, there were issues with the gathering of subjects, biases in the selected projects, issues with the analyzed results, but even this way there wasn’t any real conclusive evidence. So in this regard, my suggestions would be to go with whatever your team’s preference is.
The drawback is the compiler speed but from what I’ve seen for large enough dynamic projects the startup speed and extra tests because the lack of types the net result is mostly the same. In refactoring, the static languages, gave me such a significant help, as if I was almost pairing up with another developer.
Strong or Weak Typing
The debate for strong versus weak typing is sort of similar, just the context is different. In a weakly typed language when you write
$someVarible = "abcd"; // $someVarible is a string $someVarible = 123; // $someVarible is now an integer
[0,1,2].indexOf(0) returns => 0 [0,1,2].indexOf(0) == false returns => true
In a strongly typed language if you give a variable a type it usually ‘binds’until the end of its lifecycle. Note the above type coercion is not to be confused with implicit conversion, in which the compiler basically knows the rules in which one custom type can be converted to the other in a meaningful way. In some languages like Scala, you can even define you’re own implicit conversions and then import them as needed. A few examples below:
// In Java String token = "abcd"; String newToken = token + 123; => newToken now is "abcd123" //In scala implicit def bool2int(b:Boolean) = if (b) 1 else 0 scala> val b=true //b: Boolean = true scala> 2*b+1 //res2: Int = 3
The learning curve
Many people say learning a programming language takes only a few days since it’s just syntax. Whilst it’s somewhat true, and there are sites like learnxinyminutes It’s still not an easy task if you want to have a team write production ready, idiomatic, maintainable and scalable code. Every programming language comes with its own implementation of one or many paradigms, patterns, conventions. Even though some of them are related and the transition is easier ( think Java to C#) it might still cause headaches in terms of libraries, language features, runtime.
This is Part 1 in a series of blog articles “Are we there yet? The road to production.” In the next article, we will explore the importance of the chosen languages ecosystem, libraries, runtime, tooling, monitoring, APM and etc.