Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Time safety is more important than memory safety

halestrom.net

Post reply on HN
Print view View original

31–40 of 111 posts

Re: Time safety is more important than memory safety

#31

Post by pornel »

Rust isn’t going anywhere in foreseeable future. Even if it died today, it could stay around for a decade or two (Python 2 did. C99 is both a dead language and still considered new).

When it becomes so obsolete you won’t be able to use it, it’s likely that whatever you wrote in it also won’t have any value beyond being a historical artifact.

And if you want to preserve programs and compilers for museums or far future, how about building computer for WASM+WASI and archiving that?

These technologies are still new, but their spec is much smaller and simpler than C and native OS APIs. You’ll be able to recreate a WASM interpreter even centuries later, and from there revive the compiler and rebuild the programs.

Re: Time safety is more important than memory safety

#32

Post by gameswithgo »

usually the argument to keep using a bad language is “but we have all this stuff we built and we don’t have that in newer things so we can’t easily change”. but this is a new take! we can’t use new languages because we expect only these flawed ones to live FOREVER

Re: Time safety is more important than memory safety

#33

Post by ScottBurson »

justinjlynn wrote: post #26
ScottBurson wrote: post #21

There's always Common Lisp. Still portable 35 years on. I recall once, not quite 20 years ago, porting a large CL program from a 32-bit implementation to one of the then-new 64-bit Lisps. Someone who didn't know CL thought that would be a hellish job, but it turned out to be quite straightforward.

With the new research being done in macro-level type systems there's a lot of great reasons to check out lisp again (as a person who loves strongly typed languages)! Type Systems as Macros - https://www.ccs.neu.edu/home/stchang/pubs/ckg-popl2017.pdf Dependent Type Systems as Macros - https://www.ccs.neu.edu/home/stchang/pubs/cbtb-popl2020.pdf It's so cool - especially the bits where they reconstruct each part of the…

I used macro expansion for type checking in Zeta-C [0], the first C compiler for Lisp Machines, in 1983. Didn't write a paper about it, though.

Dependent types are certainly interesting -- I'll give this a read. Thanks!

[0] http://bitsavers.trailing-edge.com/bits/TI/Explorer/zeta-c/

Re: Time safety is more important than memory safety

#35

Post by safety-third »

ryl00 wrote: post #24
platz wrote: post #19

It'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

It depends on what you're working on. I'm in the simulation area at an engineering company, and we've got plenty of Fortran code that dates back to the '70s that's still just fine. A little maintenance to work on removing deprecated syntax, a little work to replace common blocks with a more decoupled design, and we're probably good for decades more use. And if we can't get to that maintenance work right now, the stro…

Same here. We are stuck in Watcom F77 right now due to using some old extensions. We are in the middle of eliminating control characters from format statements so we can finally upgrade to new compiler.

Re: Time safety is more important than memory safety

#36

Post by ratboy666 »

dnautics wrote: post #27
labawi wrote: post #6

Earlier quoted context omitted.

C is only about 50 years old. I'd say it remains to be seen (not in our lifetime).

you might be able to compile C89, but would you be able to debug it? What if there are incorrect assumptions about the word size in your computer?

As part of "C lore", the answer is yes. In C89:

int main() {

func('a');

}

func(c)

char c;

{

char * s = &c;

printf("%c\n", * s);

}

is, um, dangerous. c is an int, not a char. So on a big endian machine, s may end up pointing to the high byte. Taking the address of a parameter is dangerous, unless the widening is taken into account.

This does work on a little endian machine (tried it). On a 68000, it likely doesn't print 'a' (\0 is most likely).

On little-endian, this is a lot safer. ANSI C takes care of this as well. Yes, we can "debug it". There is a chance that all knowledge of this is lost. But, for now, those of us "in the know" have experience to keep the old alive.

Re: Time safety is more important than memory safety

#37

Post by wtracy »

If "will this be usable in ten years?" is a concern, then you shouldn't be worried about your language choice. You should be worried about the services your program depends on.

Does your mobile app do anything useful if Google shuts down their authentication servers? What happens to your users if the App Store/Play Store decides to purge applications that don't actively support recent APIs? What happens when the Maven repositories your build depends on get shut down?

I would much rather figure out how to build a Rust program in ten years than try to recreate a web service that simply no longer exists.

While we're at it: All the "obscure" languages discussed here are FOSS. Finding an implementation will be relatively easy, and having access to the source means that things like binary compatibility issues can be worked around.

This is nothing like trying to resurrect a program written in an obscure proprietary dialect of Pascal that was only made available on a run of 200 floppy disks.

Re: Time safety is more important than memory safety

#38

Post by bvinc »

giornogiovanna wrote: post #14
schoen wrote: post #2

I 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.

My understanding is that automatically determining time complexity is impossible in the general case due to the halting problem.

And getting a compiler to truly understand the time complexities of your data structures would involve either extremely difficult theorem proving or just forcing it.

I do think it would still be interesting if a language had support for determining time complexity. It seems like it's often possible even if it isn't in the general case.

Re: Time safety is more important than memory safety

#39

Post by 0xcde4c3db »

pornel wrote: post #31

Rust isn’t going anywhere in foreseeable future. Even if it died today, it could stay around for a decade or two (Python 2 did. C99 is both a dead language and still considered new). When it becomes so obsolete you won’t be able to use it, it’s likely that whatever you wrote in it also won’t have any value beyond being a historical artifact. And if you want to preserve programs and compilers for museums or far future…

> C99 is both a dead language and still considered new

Lest anyone doubt this, I recently worked on a (proprietary) library that the company kept C89-clean because some (similarly proprietary) embedded targets are basically frozen in the mid-90s.

Re: Time safety is more important than memory safety

#40

Post by titzer »

It's tempting to just drop this one because it's borderline flamebait, but there are so many pernicious misconceptions here that it's worthwhile calling them out explicitly. I'm generally not into author-chiding, but TBH the post was written in a very inflammatory and ignorant fashion that I'd encourage the author to be more thoughtful in the future so that we can all get out of the muck.

1. False choice between "unsafe" and "new" languages. No, just no. Safe languages have been around since the 1960s (e.g. LISP). While it's not really "C versus the world", C/C++ are in the vast minority when it comes to safety across all programming languages. Throw a stick, hit a safe programming language. Java, C#, Rust, Go, Python, Ruby, R, Lisp, Clojure, Scala, Haskell, ML, Modula 3, TCL, JavaScript: the list goes on and on and on.

2. C programs don't break. Just plain false. C and C++ are underspecified languages, meaning they have undefined behavior in some situations--actually, most situations. Undefined behavior is silent and there are poor diagnostics. It's almost always a program bug. Undefined behavior and even nonportable behavior is absolutely rife in the C and C++ world. Programs aren't necessarily portable across platforms, compilers, language versions, and even compiler bugs. Well-specified languages give programs a much better chance of being portable. Which leads to:

3. Portability is mostly a language issue. This is only partially true. The fact is that portability and forward compatibility (time safety as this person calls it) is a function of dependencies--on the language version, compiler, external libraries, and general environment around the program too. Fewer dependencies generally means better forward compatibility. It's also good if those dependencies are maintained by teams who care a lot about backward compatibility. Some languages do more than others.

4. "Time safety" is a term. I have never heard of this term before, which just speaks to the uninformed nature of this post. I think the author means forward compatibility.

Anyway, if you feel like the core message of this post is that unsafe=future-proof, feel free to choose another unsafe language to do your next program. Hint: there aren't many.

PS: Java 1.0 is now 25 years old. Java 1.0 programs still compile today and the binaries that compiler generated back then still run on today's JVMs.

Post reply on HN