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

81–90 of 111 posts

Re: Time safety is more important than memory safety

#81

Post by pron »

Scarbutt wrote: post #45
pron wrote: post #4

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

Golang is already a top 15 language, I would call that truly popular.

Not really. It has a 0.6% market share in the US, and I would assume a much lower share elsewhere: https://www.hiringlab.org/2019/11/19/todays-top-tech-skills/

I mean, it's popular, but I'm not sure it's a "safe language" just yet. Language popularity obeys a power law of sorts. Go is about 6x less popular than Ruby at the moment, and I don't know if I would count Ruby as a "safe language" either. So far, I haven't seen many Go programs meant to be used for the next, say, 15 or 20 years.

Re: Time safety is more important than memory safety

#83

Post by littlestymaar »

comex wrote: post #77
fwsgonzo wrote: post #75

Earlier quoted context omitted.

Anyone can claim anything that helps their cause. All you have to do is not implement the emulator using the official developer documentation for the system. For example on the original Gameboy the thing you have to avoid is using the copyrighted BIOS ROM. But you can avoid that by just initializing the CPU registers and instead starting at the cartridge start address.

FWIW, independent reimplementation protects you against copyright infringement but not patent infringement.

True, but patent infringement are limited to few places in the world, while copyright infringement are enforceable pretty much everywhere.

Re: Time safety is more important than memory safety

#84

Post by sacado2 »

kelnos wrote: post #46

> I don't think it's responsible to ask ordinary programmers to start their projects in new languages. Rust is 14 years old[0], its compiler has been self-hosting for 9 years, and its 1.0 release was nearly 5 years ago. Sure, that's not as old as C or C++, but I wouldn't call it "new" either. [0] https://en.wikipedia.org/wiki/Rust_(programming_language)#Hi...

Provided code written 14 years ago wouldn't compile on current compilers, I think it's fair to consider today's Rust is a fairly new (i.e 5 years old) language.

Re: Time safety is more important than memory safety

#85

Post by Buge »

From the title you might think it's talking about safety from pathologically slow inputs. Especially considering there's a different post also on the front page right now about that exact thing.

> PerfFuzz: Automatically Generating Pathological Inputs (2018) [pdf]

https://news.ycombinator.com/item?id=22315542

Re: Time safety is more important than memory safety

#86

Post by GlitchMr »

I kinda disagree. With C, you risk old autoconf scripts breaking, depending on library versions that operating systems don't include anymore, compilers learning how to exploit undefined behaviour they didn't exploit before, programs breaking due to making incorrect assumptions (`char` is signed, right?). C++ also adds exciting issues in terms of backwards compatibility breaks (for instance, programs using `register` keyword won't work since C++14) - refer to Annex C in C++ specification for a long list of BC breaks.

None of this is an issue in Rust. Cargo is a proper build system, not a weird combination of shell script and M4 using programs that are prone to breaking changes (like awk). Cargo requires defining program dependencies and prevents accidentally using a dependency that exists on an operating system. Rust in safe code avoids undefined behaviour, noticeably avoiding the risk of accidental undefined behaviour. Rust has much less implementation-defined behaviour than C (`i8` is a well defined type). Rust edition system means that breaking changes avoid affecting old code (even if Rust were to, say, remove `static mut` in edition 2024, this change wouldn't affect programs that wouldn't explicitly upgrade to edition 2014).

Rust is serious about backwards compatibility. Breaking changes are mostly unacceptable (other than in cases of soundness bugs, but even then there is typically a warning cycle before fixing a bug). In fact, you may take a look at "Compatibility notes" sections in https://github.com/rust-lang/rust/blob/master/RELEASES.md. The compatibility breaks tend to be very minor, and unlikely to break stuff. For instance, in Rust 1.39, `asinh(-0.0)` was changed to return `-0.0` instead of `0.0`. Strictly speaking a breaking change, but a program depending on that is very very unlikely. Rust also has crater which prevents accidentally breaking backwards compatibility by testing whether every public GitHub repository and crates.io library still works the same way. Additionally, even in case program compilation breaks anyway, it's possible to use an older version of a compiler with rustup.

Rust is here to stay. Even if Mozilla ended up supporting the project, some other company that uses Rust internally would continue to support it. It's free software after all. Even if that wouldn't happen, the old rustc releases would still work.

Re: Time safety is more important than memory safety

#87

Post by ratboy666 »

ratboy666 wrote: post #36
dnautics wrote: post #27

Earlier quoted context omitted.

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 pri…

And, for those who have been contemplating parameter widening: on the 68000, insert s += 3. For "portable" C89 code, declare the parameter an int (not char) -- then introduce char c2 = c and s = &c2 instead. This transformation is "safe" because parameters are copied by value and cannot be returned that way.

As to debugging -- many of these systems did not have "debuggers" -- an example would be Whitesmiths C in the late 70s and the 80s. We used a strategy of old-school paper validation, combined with function testing. Yes, things moved more slowly.

Code can be maintained. The above C89 code was just compiled with gcc 9.2.1 -- with gcc -std=c89 c89.c it compiled without warning, and ran (40 year old code).

The issue with (say) bring forward Whitesmiths C is that the Whitesmiths standard library is not POSIX. Not hard to convert, though. For example (as I recall) %d was %i

FORTRAN 77 (and FORTRAN IV) is in a similar category. As is COBOL and Common LISP.

SNOBOL4 is a bit of an outlier -- The original interpreter was written in macro assembler. That assembler is now converted to C, and the original interpreter can still be run:

The Macro Implementation of SNOBOL4 in C (CSNOBOL4BX) Version 2.0 by Philip L. Budne, January 1, 2015 SNOBOL4 (Version 3.11, May 19, 1975) BLOCKS (Version 1.10, April 1, 1973) Bell Telephone Laboratories, Incorporated EXTENSIONS (Version 0.25, June 16, 2015) Fred Weigel

No errors detected in source program

CODE (TUE AUG 4 10:28:58 EDT 2015) RUNNING ON CSNOBOL4 MAINBOL WITH SPITBOL, BLOCKS, EXTENSIONS ENTER SNOBOL4 STATEMENTS (TRY ? FOR HELP) 5,541,616 BYTES FREE CODE:

And, yes, I modified the original interpreter to add some extensions back in 2015. However, Budne has published the pattern matching engine in Javascript so there is an easy migration for those programs (https://github.com/philbudne/spipatjs).

In my opinion (and this is strictly my opinion), only Javascript appears to have this "lasting" property wrt modern languages. An important characteristic is simplicity, and forward-backward compatibility. As well, multiple implementations are important.

FredW

Re: Time safety is more important than memory safety

#88

Post by sly010 »

What kills code more than anything else is not the language of choice, but operating system vendors "improving" user experience by deprecating APIs and frameworks.

That said, there are language communities that definitely value change more than stability * cough * javascript * cough.

But go. Imho it's unfair to implicate go. It has no backward incompatible change that I know of, and it literally depends on nothing but the kernel interface, which is known to be very stable.

Re: Time safety is more important than memory safety

#89

Post by flavio81 »

dana321 wrote: post #28
benibela wrote: post #16

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

You would probably like go, its much like pascal. And it has libraries for everything!

Last time I checked, Pascal has generics and exception handling.

Re: Time safety is more important than memory safety

#90

Post by kazinator »

pdimitar wrote: post #79

> In contrast my old C projects from 5-8 years ago still compile and run Sigh. Again this circular logic. And again, this is a fact simply because many people chose to muscle through a lot of problems that C has. It's NOT because C is amazing or anything. Many people chose to muscle through COBOL's problems as well. Is COBOL amazing? Is COBOL giving you time safety? This is like saying that the Amish have the superio…

"My old C projects from 5-8 years ago still compile and run ... in my trusty Ubuntu 12 VirtualBox inside Windows 10!"

:)

Post reply on HN