[deleted]
Time safety is more important than memory safety
11–20 of 111 posts
Re: Time safety is more important than memory safety
#12I thought this was going to be about concurrency, but it's instead about the risk that programming languages will become obsolete quickly.
I was expecting a discussion of timing side channels in encryption. Valid points all around, really.
Re: Time safety is more important than memory safety
#13TL;DR: It's better to have buffer overflows and use-after-free bugs that still work in 50 years than to have secure code you may need to migrate.
Re: Time safety is more important than memory safety
#14I thought this was going to be about concurrency, but it's instead about the risk that programming languages will become obsolete quickly.
I thought this was going to be about bounding the time complexity of your algorithms; I don't know if any language does that yet. I suppose this title has a lot of interpretations.
Re: Time safety is more important than memory safety
#15I don't get the argument. Is the author complaining about complexity of languages like Rust? I.e. only simple languages supposedly have longevity? C++ is complex, yet it already exists for quite a long time too. Just because C happens to be a long used language doesn't mean you shouldn't be using newer and better languages and that those languages can't be used for a long time too. C is used not due to big benefits,…
Honestly, if you care about longevity, Rust simply isn't the language yet. I'd at least wait until there's a specification and a GCC frontend.
Anyway, C does have some benefits as a programming language.
• "Legacy" projects like Linux and CPython will keep it alive for decades to come.
• It's extremely portable. Rust is less portable, and even when Rust supports a niche platform, it's relatively clunky to get things started.
• C libraries are always very easy to call from other languages. Rust isn't quite there yet, and translating things like traits can be a bit of a pain.
Re: Time safety is more important than memory safety
#16I use Pascal for all my projects because it has memory safe strings and arrays.
Almost all buffer overflows and security bugs could be solved by rewriting all software in Pascal.
Everytime a software crashes, you should say, it crashed, because it was not written in Pascal
I just spend two hours modifying my xml parser to load files that have a doctype with inline declarations. Never needed to load an xml file with a doctype before, and I only wrote the parser for the files I have. I also have plans for a json parser. There is a surprising lack of Pascal libraries.
Re: Time safety is more important than memory safety
#17TL;DR: It's better to have buffer overflows and use-after-free bugs that still work in 50 years than to have secure code you may need to migrate.
I think you're being sarcastic? But I also think the article genuinely believes that's true.
In 50 years there will be C programmers who know how to fix a buffer overflow, compile, and run your program. Conversely, a program written in a language and dependent on a package repository that only existed from 2017-2024 will likely never find an academic willing to invest the thousands of hours in learning that legacy code, digging through archives, and making that program run again.
Re: Time safety is more important than memory safety
#18I think this is yet another post that falls into the trap of mistaking HN/Reddit -- fashion publications, really -- for something else. They're GQ or Vogue, not the New York Times. https://news.ycombinator.com/item?id=22106559 The vast majority of developers do and always will choose well-established languages. If Go or Rust or Zig or Kotlin or Clojure or Elixir ever become truly popular, by that time they will have…
If you agree with this principle, I think the end result is that you choose the most popular language for some window.
For banks and airlines, you conservatively pick a large window. At one point that ended up being COBOL. That is slowly migrating to Java now. I suspect it will move to TypeScript in about a decade or so.
For new code today, I'd probably pick TypeScript.
A few years ago, I'd have picked Ruby. Before that, Python, Before that, Perl/CGI. Before that, Java. Before that, C++.
I wonder if at some point the tides will turn back to writing pure-personal-computer-and-no-cloud C/C++ Windows applications.
Re: Time safety is more important than memory safety
#19It's actually the assumptions around longevity that need to be examined.
Software is not like etching perfect museum-pieces.
It is the union of the world that defines software's context, and since that will always change, we'll have to continue to write and re-write software to ensure the match is appropriate
Re: Time safety is more important than memory safety
#20I think this is yet another post that falls into the trap of mistaking HN/Reddit -- fashion publications, really -- for something else. They're GQ or Vogue, not the New York Times. https://news.ycombinator.com/item?id=22106559 The vast majority of developers do and always will choose well-established languages. If Go or Rust or Zig or Kotlin or Clojure or Elixir ever become truly popular, by that time they will have…
I doubt that most developers ever choose a language to work on at work. They usually join a pre-existing project that already has enough of an investment into a given language that choosing any other language requires a very compelling reason.
To see what languages developers are actively choosing as opposed to going along with, you'll need to measure the proportion of languages used among greenfield projects (and ideally truly greenfield ones, i.e. ones that don't require technical support from other teams within the same org).
I don't have data for this, but I'd be surprised if Go wasn't way high up on that list (and on Android, similarly for Kotlin).
So does anybody have data on greenfield projects?
N.B. I also wouldn't be surprised if the majority of developers hardly ever chose a language for anything, that is I wouldn't surprised if the majority of developers have never started a substantial project from scratch and have only ever joined existing ones. A lot of people prefer to do things other than code in their free time and again, in the workplace, especially in large organizations, it's perfectly possible to only ever work on pre-existing codebases.