modified: Thursday 13 February 2020
Time safety is more important than memory safety
This is an edited except from the EEVblog forum topic The Rust Megathread
Summary: "Time safety" is more important than "memory safety" et al. We live in a world where time destroys more things than software bugs will ever be able to do. You should choose a language based off the biggest threats to the (time-integrated) usefulness of your projects, not based off the threats in your local region.
A pet peeve of mine is around claims that languages like C are a bad choice for new projects and that languages like Go or Rust are better options. This is only true if you take a subset of the lessons history has taught us and disregard the rest. I see this as irresponsible.
I think we are living in the information dark ages, where a lot of our useful and amazing creations of code are simply not going to be around ten or twenty years from now. They will be broken (or passively deleted, another problematic topic).
We seem to have come to accept that a program written today won't be useful or usable ten years from now and I think that is a very bad philosophy. Compare it with many of the machines (cars, factories), artwork (music, books, film), architecture and systems (society, education, etc) that show how good creations can last decades or more. Most don't, but they have at least a chance of doing it.
A similar argument can be made about a lot of modern car designs and DRM in digital works: we dislike the idea of things having intentional or preventable use-by dates.
I see choosing "new" languages (or frameworks) as very risky propositions to the life of a project. These languages are less likely to be around in ten or twenty years time (newer and better Rusts and Gos are likely to form in the years ahead) and in the meantime require you to constantly expend effort to prevent your projects from being turned into a brick by language/environment/library changes. In contrast my old C projects from 5-8 years ago still compile and run, with one particular example only needing a small modification. It's not perfect, but C is much more likely to be the "safe" option if time x usefulness of your project is a goal.
Should you care about code and software longevity if you are only making personal projects?
I still say yes. I want to be able to show and demonstrate projects I made "when I was young" to my kids, just like I will be able to show them old pictures of family and physical projects I have made. I want to be able to show them the lessons of my life, not show them that the only lesson is about "oh yeah we lost all of that".
It's always useful to be able to use old code from old projects too. Ideally perhaps even forever, but in our current world that's a longshot. But even code snippets that survive a few years are very useful. Contrast this to how many environment or framework specific code examples or tutorials from the web that you have tried to use but found do not work any more -- you do not want your code becoming that.
Should we persue these new languages?
Yes, experimentation and development drive our society. But ordinary people using them, IMHO, provides minimal benefit compared to the problems it causes.
This is the same reason that we don't all drive prototype cars and wear prototype clothes. In the long term it would cause more harm than good.
As such: I don't think it's responsible to ask ordinary programmers to start their projects in new languages.