Get faster: my 2024 resolution

In 2024 I want to become significantly faster at developing software in the main ecosystems I spend my working hours on: JavaScript + TypeScript with Node on backend and React on frontend, Rust πŸ¦€ for all performance-intensive workloads.

Get faster: my 2024 resolution

Being fast as a developer matters, and it only compounds over your lifetime!

It's not something that we're comfortable hearing as developers, especially with narratives like "I spend most of my time thinking as a software developer".

But the reality, the objective plain reality, is that the faster you can get something done (thinking + coding), the more things you can do => the more experience you get => the better you get at doing it => the more things you can do if you stretch yourself.

It's a virtuous cycle, and it has effects both on the types of problems you can tackle as well as their complexity. Like and craftsman could tell you for the past 20'000 years, the more you practice with your tools in a mindful way, the better you get at it.

You can read here a very interesting take on this topic as well, and suggested ways for the process of getting faster here.

So, my 2024 goal is to become significantly faster at developing software in the main ecosystems I spend my working hours on: JavaScript + TypeScript with Node on backend and React on frontend, Rust πŸ¦€ for all performance-intensive workloads.

I also have a "stretch goal" next year, and that is to try to become proficient in Zig 🦎

Because there are times when I need to throw caution to the wind and prototype something very fast, which also runs as low-level and performant as possible during runtime.

Rust πŸ¦€ - for all my love for it - is not the greatest in this area, or it could be once I've mastered it, don't know, could be a skill issue. But my experience so far has been that if you really want to get something done fast, quick and dirty, Rust πŸ¦€ won't really let you. Sure, you can go unsafe, but there's many hoops that you'd need to jump through there as well, which in some cases feel unnecessary. It's by no means the same experience that you'd get doing the same with C or Zig 🦎.

This is not a criticism in any way, it's just a set of use cases that Rust πŸ¦€ doesn't even want/try to support, and that's fine. I believe in using the right tool for the right job, and Rust πŸ¦€ is still THE language I feel the most confident about. I believe it will be the future replacement of C and C++ in most industrial and big tech software codebases over the next 5 to 10 years.

Back to quick and dirty low-level programming though, I've narrowed it down to Zig 🦎 , but it wasn't an easy choice. As you might have noticed from my book reviews this year (with several more to come still), I've spent quite some efforts getting deeper into C, and really wanted to love it.

Unfortunately I think there's very little benefits for me personally to put in the effort to develop mastery in C. I'll most likely not need to write production-grade C code in the visible future, nor require its extensive ecosystem of tooling. I also don't envision doing commercial projects where me writing C is required, and knowing Rust πŸ¦€ well allows me to cover +95% of all areas that C is used in.

Generally, I try to get good at languages which I am confident have both a strong future in commercial usage as well as a solid enough base already in terms of community, development and learning materials. RustπŸ¦€ has crossed that point in my view a couple of years ago, so it's a "sure bet".

Zig 🦎 is I feel still a couple of years away from achieving this minimum benchmark , but I'll take the bet on it right now for the following reasons:

  • I think it will poach a lot of talent from the hard-core C community (look at what they're doing with LLVM already), which will help significantly in its development.
  • It can do everything that C does - for my own needs - but better and with more memory safety (see `defer()` as well as pointer types).
  • Writing Zig 🦎 is arguably a slightly nicer experience vs. writing C.
  • Interop with C is better than any other language's, and on par with C itself (if you can even say that) => I can drop to, or interface with, C directly whenever required.
  • It still allows me to feel like a "cowboy" and do whatever I want to do memory-wise, same like C, which is something that I sometimes want/need to be able to do, and a use case which Rust πŸ¦€ doesn't facilitate easily (it's actually actively trying to prevent you from doing so, even if you use unsafe)
  • If you look at its history, for very good reasons C is not, and will not, develop in any significant ways going forward. That's ok, but I want the languages I invest in and work with daily to grow and evolve with the lessons learned over decades of software development. Zig 🦎 promises the same approach as Rust πŸ¦€ in this regard, alongside the bonus of a strong commitment in its vision to keeping the language simple for the developer (which is not really a value for Rust πŸ¦€ btw) but which I think is very important nonetheless when you need to get stuff done fast.

If my choice made you interested in Zig🦎, here's an interesting video discussion between Kris Jenkins and Loris Cro, VP of Community at the Zig Software Foundation, on the general philosophy of Zig and its ambitions in the near future.