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

41–50 of 111 posts

Re: Time safety is more important than memory safety

#41

Post by pcwalton »

Counterpoint: NES games were handwritten in assembler for a long-dead architecture. You couldn't pick a worse development environment for "time safety". The source code for most of the games is lost, too. Yet they remain some of the most portable programs in existence, because of emulation.

The PC architecture is extremely well-documented in practice (as are alternatives like WebAssembly), and there are going to be emulators for them around for the foreseeable future. Emulators for the PC architecture are no more likely to die in the future than C compilers are. You will be able to run any program written for the PC, in any language, for a very long time.

Re: Time safety is more important than memory safety

#42

Post by zzo38computer »

pcwalton wrote: post #41

Counterpoint: NES games were handwritten in assembler for a long-dead architecture. You couldn't pick a worse development environment for "time safety". The source code for most of the games is lost, too. Yet they remain some of the most portable programs in existence, because of emulation. The PC architecture is extremely well-documented in practice (as are alternatives like WebAssembly), and there are going to be e…

Yes, although people still write programs for NES, sometimes for that reason, so it works.

Re: Time safety is more important than memory safety

#43

Post by zzo38computer »

wtracy wrote: post #37

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

Programs I write are generally designed not to depend on any particular internet services (if they need some, they are configurable), and this is part of the reason to do.

And, yes in the case of these FOSS it is probably easily enough to find an implementation and to work around the binary compatibility issues. In the case of a program written in an obscure proprietary dialect of Pascal that you do not have an implementation of, well, sometimes you might reimplement a subset which is enough to run these programs (I have done similar things in the past), although of course it is probably going to take longer and be more difficult than FOSS is going to be.

Re: Time safety is more important than memory safety

#44

Post by safercplusplus »

If you're planning that far ahead it may not be an either-or situation. That is, in the future C/C++ may also have an enforced memory safe subset. In which case the issue becomes, how do you write your code today so that it will conform to the safe subset? There are conformance tools in the works that can already give you a sense of the restrictions that will be imposed [1].

[1] https://github.com/duneroadrunner/scpptool

Re: Time safety is more important than memory safety

#45

Post by Scarbutt »

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.

Re: Time safety is more important than memory safety

#46

Post by kelnos »

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

Re: Time safety is more important than memory safety

#47

Post by kelnos »

LeifCarrotson wrote: post #17
cestith wrote: post #13

TL;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 co…

> In 50 years there will be C programmers who know how to fix a buffer overflow, compile, and run your program.

I don't think that's a given. In 2070, C might be today's COBOL. There are a few people who know it, and are paid obscene amounts of money to maintain aging systems to keep them from falling apart.

Now, there's certainly more C code now than there was COBOL code at COBOL's peak, but that's no predicting the future. What I'd call "modern" computing and software development has only been around for 30-40 years or so. In 50 years I expect things to be radically different.

Re: Time safety is more important than memory safety

#48

Post by 95th »

titzer wrote: post #40

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 "uns…

Was looking for this.

Re: Time safety is more important than memory safety

#49

Post by davedx »

dwohnitmok wrote: post #20
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…

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

Only anecdotes, but I've had the opportunity to be responsible for the choice of language in some greenfield projects, usually relatively small line of business applications. My choice is almost always nodejs, lately with TypeScript front ends and my most recent project using TypeScript on the node side too.

The reasons for this choice (I've also worked with Ruby, Scala, C#, Java etc):

* JavaScript developers are everywhere, it's an accessible language to learn with tons of libraries and a huge community

* Nodejs is a simple and great general purpose backend platform that will get you really far for 95% of use cases. It scales well, has a simple concurrency model and simple deployment and ops tooling

* Using same language on front end and back end reduces cognitive overhead. My biggest client at the moment uses C# on back end and TypeScript on front, and despite them both being very nice Microsoft languages there's still so many differences

Re: Time safety is more important than memory safety

#50

Post by pjmlp »

What a pile of garbage.

First of all try to compile C code written for 8 bit and 16 bit 80's micros to see how well it has stood the time, without making use of hardware emulators, spoiler alert it won't even compile.

Then plenty of programming languages, some of them older than C, are doing great.

Anyone with enough money can enjoy NEWP on Unisys ClearPath, a systems programming language almost 10 years older than C.

Or for free one can enjoy Algol 68 programs in 2020, http://algol68.sourceforge.net/

Guess what, those languages took engineering seriously, unlike C.

"The first principle was security: The principle that every syntactically incorrect program should be rejected by the compiler and that every syntactically correct program should give a result or an error message that was predictable and comprehensible in terms of the source language program itself. Thus no core dumps should ever be necessary. It was logically impossible for any source language program to cause the computer to run wild, either at compile time or at run time. A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary pre- cautions would have long been against the law."

"Hoare's The 1980 ACM Turing Award Lecture", https://www.cs.fsu.edu/~engelen/courses/COP4610/hoare.pdf

Still disappointed how Azure Sphere can sell its security story, while offering only C as programming language, so...

Even C++, with its copy-paste C89 compatibility, is already better than writing plain old C. And guess what, the language is 40 years old now.

Post reply on HN