Recently, we were told about a culture change to one of innovation. Our new philosophy is that people need to explore different technologies to work out which ones would benefit the company.

When investing time into this research and coming up with a prototype, obviously many experiments won’t bear fruit. As long as we document our thoughts; why the technology isn’t suitable, what scenarios it could be suitable etc., then it won’t be a waste of time, because we have learnt from it and educated others.

One team did a presentation on cloud computing, and the differences in performance when it comes to running severless functions. They reported that using languages such as Java and C# will be a poor choice due to “cold starts”. Better languages would be Go or Python that have a speed benefit. See Cold Start Comparisons for comparison tables and charts.

When the time came around to do more presentations, a different team talked about severless functions and how they encountered a problem called “Cold Start”. I was face-palming. What’s the point in these presentations if teams aren’t gonna listen to each other? Sharing knowledge and learning from each others mistakes or findings make teams progress quicker. It’s a waste of time repeating what other teams have already done.

Anyway, when the next presentations came about, we were all eager to hear about something different. But up stepped a team to talk about severless functions. The presenter explained that they knew about the “cold start” problem due to the other presentations over the previous months, but they wanted to witness it for themselves rather than just go by what they were told. I couldn’t believe it; why wouldn’t they invest their time in something new, and then come up with a presentation that people can learn from. Just churning out the same content was a waste of everyone’s time.

This week, I overheard a couple of developers talking about their experiences with severless functions.

“I’m finding Go really difficult to code in, so I might just use C# instead”

“What about the cold starts?”

“Well, it will be Microsoft’s priority to fix it, so by the time our code goes live, it probably won’t be a problem”

There are many programming languages around, and they are created for a purpose. As a developer, you need to use the correct tool for the job, and shouldn’t just use a language just because you are familiar with it. If you look at the findings in Cold Start Comparisons, maybe Microsoft could improve efficiency slightly to Java levels, but surely you can’t expect Python performance. It’s a completely different style of language. Also, it’s a bit of a gamble hoping that performance will improve by the time you rely on it.