Programming language ⚡️ energy efficiency compared

· Golang, Planning · Patrick Smith

A team of Portuguese researchers have compared 27 programming languages by their energy use. They compared both CPU and DRAM energy usage with total time of execution and memory usage to build a fuller picture of efficiency.

The aggregated figures for energy, time, and memory across 27 programming languages.

Unsurprisingly compiled languages such as C and C++ perform best or near the top. Their modern successor Rust also does well.

Golang uses more CPU, but is still relatively lean. It’s especially impressive with memory usage, using even less than C or C++.

Swift and C# are not standouts, but both do very well both with energy and memory use. This contrasts with Java, which is faster and uses less energy, but has over twice the memory usage of these two.

JavaScript is one of the fastest interpreted language, having had over a decade of focused performance improvements. I have to assume they tested with NodeJS — I think server-side JavaScript has many interesting futures outside of this one particular tool.

Ruby and Erlang are both at the high end for energy use and CPU time. This could be because many of what were benchmarked were computationally intensive algorithms, which if you are building web applications you may not be writing many of yourself. However, many of the underlying libraries may still exhibit this sort of performance and energy profile.

All in all, I think it’s an interesting comparison, and I think it’s great to be putting a focus on energy usage as an important metric — it is something to be mindful of for both code running on servers in the cloud, and code on users devices.

You can read the full paper here, and there’s also more analysis to read.

What I plan to learn in 2019

· Planning · Patrick Smith

Another year, another set of new shiny technologies to entice you! At Cogent, we recently asked each other what we were planning to learn in 2019. Below is my list: you’ll find a mix of front-end and back-end technologies, as well as some marketing related one.

It’s tempting to learn anything that looks compelling and interesting in any way. I am trying to be a little more particular and choose things that have some maturity. Or things if new, that I think will be here to stay.

One thing I’m keen to learn through is by teaching. To finally have a proper somewhat regular blog and make screencasts. I would start with a blog post, get feedback from people, then record a lesson or walkthrough to share on YouTube.

When I was teaching junior programmers I felt like lots of my knowledge was strengthened by having to articulate concepts that I just took for granted. I’m curious how things work generally so will want to know, but there’s always something that I gloss over — “yep this just works, and I don’t care why or how to do my job”. So it was great to sit down and study these concepts and then explain them in a way that didn’t lead to 35 confused faces.

After wondering if I should focus a blog on a particular topic, I’m thinking I’ll just write about what I’m working on and not worry about if I’m not satisfying ‘web developers’ or whoever with every single post.

What I plan to learn

  • Cloudflare Workers and what they best suit
  • Architecting apps well with the next-gen React
  • Optimising web apps to be faster and leaner
  • GraphQL
  • Golang and what it best suits, maybe compiling it to Webassembly
  • Google App Engine and Datastore
  • Elixir and what it best suits
  • Whether Gigalixir is worthwhile
  • Maybe Websockets and what they best suit
  • Will try CSS Grid again
  • Probably more iOS App development
  • Latest Swift changes
  • Possibly machine learning
  • How to run and launch open source projects
  • Marketing
  • How to plan and write and record screencasts — after teaching I find presenting to a group of people much easier and engaging for me than sitting down and cranking out words
  • How to not over engineer my blog and use something boring like WordPress (Done! You’re reading it)

What I plan to not learn

I find it helpful to have a no list too:

  • Not Reason
  • Not Rust
  • Not Android
  • Probably not React Native unless for a project, then yes
  • Less Node.js
  • Not Electron

I often made ‘no’ lists when teaching for what would not be covered, as it helped to focus the lesson.

What are you planning on learning in 2019? Let me know by tweeting me.