The linked Daniel J. Bernstein paper [0] is interesting. I note with some satisfaction that section 3.2 echoes a comment I made last week [1] that wound up at -1 (after some bouncing around). Arbitrary-precision integers should be the default in all new languages, with very few exceptions (and should clearly have been the default in Java).
Rust is an interesting case. It's intended as a systems programming language, so performance is considered important. I guess I can't say flatly that it should have arbitrary-precision integers by default, though maybe it could. But at least it reminds you, every time you write an integer type, that it's bounded, the length being right there in the type name ("i32", "u64", etc.)
Arbitrary-precision integers are not that slow if they're implemented the way most Lisp implementations do it. For a strongly-typed language, you would need only one tag bit: if the low-order bit is 0, then the remaining bits of a pointer-sized word, shifted right 1 bit, are the value; no heap storage or indirection is required, and addition and subtraction require no fixup afterwards as long as there was no overflow. Only if the low-order bit of an operand is 1, or if there's overflow, do you have to trap out to the general case which handles heap allocation.
Yes, this is slower than ordinary fixed-width integer arithmetic, as a couple of conditional branches are required, but it's nowhere near the price of heap-allocating every integer.
And the overflow check is now finally cheap in portable C. Before you had to use inline assembly for this trivial ex:
add %rax, %rbx
jo +4
Now you have the new gcc and clang overflow intrinsics (gcc-5, clang-3.4), which made it cheap and easy to use proper and precise int arithmetic, promoting int to bigint's only on overflow.
Civil aviation aircraft still fly 1930's engine designs in 1950's airframes, and the costs are prohibitive. Sure sounds like a great model for software... For example, a typical ~200HP aviation engine costs on the order of $30,000 and has no modern engine management systems.
This article makes a false comparison. When software is part of safety, such as in aircraft, it gets the same level of scrutiny.
You're missing the point. It's not about the system type, but rather the approaches taken to analyse system failures and the subsequent corrective actions.
His criticism still applies to today's projects: recently I've seen fixes in imagemagick done as minimal "patches".
I've seen patches in production code that amount to 20 if else's to handle specific inputs rather than the correct input.
I just inherited a system that uses trim everywhere on everything because originally they didn't sanitise the inputs.
Rather than hunt down all the inputs they just did trim(foo) == trim(bar) making it worse is that it's PHP and so not only do they trim things but they type-coerce them, good luck trying to reason about that 7 layers deep :|
The choice of language for a project is the least problematic thing in this industry. Egotistical programmers, the categorical error of equating CS fundamentals with engineering, rapid product development and iteration, and producing as cheaply as possible all are more serious problems in this industry than a choice of language to program in.
Rust is an interesting case. It's intended as a systems programming language, so performance is considered important. I guess I can't say flatly that it should have arbitrary-precision integers by default, though maybe it could. But at least it reminds you, every time you write an integer type, that it's bounded, the length being right there in the type name ("i32", "u64", etc.)
[0] http://cr.yp.to/qmail/qmailsec-20071101.pdf
[1] https://news.ycombinator.com/item?id=14906755