So something I have been chewing on for a bit is resource usage and scaling. So let’s start this with a question…

Should an app use more because cpu and memory is cheap?

There are several different facets to this to really go through that can make up a large memory size or use more than necessary CPU.

  1. Language and runtime

Java and Ruby for example are memory managed language, and in my experience have little care for how much memory they need to run. Your application may be relatively small, but to start may require more than would be traditionally needed. You bolt on frameworks and it starts to get potentially larger.

  1. Memory efficiency

Depending how the language or runtime handles it, your variable may have additional bloat as it may be managed by the runtime. So when you allocate large amounts of memory for an array, there may be extra costs added to this.

  1. Low level efficiency

This is often where you see speed boosts in languages. They will take some code and change how it is handled by either the OS, transpiled, or interpreted. Perhaps a better algorithm or better use of memory.

Building for efficiency

I have been looking at some languages lately in the light of for production and for mocking. There are lots of languages out there, and some of them come with a lot of features in their standard library. But factors mentioned above make some variation on your running or development costs.

So maybe you are a startup and you need to get a product out the door as soon as possible. Perhaps a lighter language such as Go is not in the proficiency list, but maybe a language like Ruby is. All right, so they can build an application quickly, and maybe it has a bunch of tools to just work. Great, and maybe for a while your server is fine running on a single instance because traffic is low.

Now, that same project is picking up steam and you start getting more traffic with higher memory usage. Now you need to scale either horizontally or vertically. Horizontal being more instances and vertically being more memory or CPU. Horizontally generally has a fixed cost for every instance and vertically is very variable, depending on your provider.

If you built your application for scaling, you SHOULD have made choices that use memory efficiency and to run fast. If you didn’t your operating costs began to grow as more features get built and tacked on.

Cost of development

Companies want to get talent for cheap, it’s just life. But they also want to just straight find developers. We are a commodity that people want, and we come in different grades, from mediocre to great. Some companies may care about what quality they get to an extent and may have the mentality that just get it done, I don’t care about the rest. YOU should push back and say get it done RIGHT. But you should also be reasonable about this. No one is expecting you to write a full server framework in C. There is a balance that can be met between the levels of language between assembler to languages like javascript or worse, PHP.

I would recommend personally, doing your mock up of a product or proof of concept in a language like javascript, and keep it as simple as possible. How do you keep it simple?

  • Cut authentication
  • Cut animations
  • Keep UI relatively simple
  • Be loose on memory
  • Stay on point

If you get the proof setup well, you can take the approved proof of concept and implement it correctly. Yes, this does mean potentially writing your code twice. But look at it as changing to a dump truck ( heavy and inefficient code ) to a race car ( fast and efficient ).

If you can’t get the approval to do proof of concept, then you should shoot for the mini van or SUV and make it clear that the operating costs will be higher. This may never matter as the company could be successful financially, and it may become hard if it’s not but you have to maintain some scale.

Does this really matter?

For some, no this doesn’t. But I recently wrote an app twice. First time it was in C# and the second time it was in golang. They both accomplished the exact same thing, but the go app ran at nearly twice the speed and over half the memory. Allowing for the entire pipeline to run more efficiently and let the teams that depend on us get to go faster.

Final thoughts

I am not going to lie, I hate languages like python, php, and javascript as I think they are misused and abused. Just because you can do something in language A doesn’t mean you should. Beyond language syntax issues, type safety, or bulk they don’t make great production frameworks in my opinion, but hey mock away. If I have a choice, I will pick something that is built for speed within a reasonable time of development.