Time safety is more important than memory safety • Hacker News Board

Re: Time safety is more important than memory safety

#51

Post by whateveracct » Fri, Feb 14, 2020, 7:51 AM UTC

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…

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

If you want to write a random program that you don't plan to support but want to remain usable, Java is your best bet.

I've on multiple occasions recently used really random Java GUIs that are from the 2000s (Melee related). It sometimes took some finagling (iirc I had to use Java 8 or something .. luckily it was just a nix-shell away!)

Re: Time safety is more important than memory safety

#52

Post by pjmlp » Fri, Feb 14, 2020, 7:52 AM UTC

safety-third wrote: post #30

I actually have had the pleasure of porting a program from a defunct 16-bit language called Actor to C++. It wasn't a huge deal even at around 800 kLOC. All mainstream languages in the future are going to have some combination of structured, functional, and object-oriented programming. Converting is mostly going to be about syntax and libraries. As someone who has worked with C and C++ for living for over 20 years, I…

I don't share the same negativity towards Go, in spite of disliking some of its design decisions.

TinyGO, TamaGO, Android's GAPID, Fuchsia's TCP/IP stack, gVisor, are all good examples that Go has a place on C's domain, when one is willing to invest the resources (time and money) into making it happen.

Using Ada wouldn't be that bad actually. :)

As for Rust, now with Google using it on Fuchsia and Microsoft doing internal Rust summits, lets see how it evolves. Both companies are quite big into ISO C++.

Re: Time safety is more important than memory safety

#53

Post by pjmlp » Fri, Feb 14, 2020, 7:55 AM UTC

cbhl wrote: post #18

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…

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

You just need to go into life sciences lab robots, factory automation, medical devices, ticketing machines,.... to enjoy doing Windows WPF or C++ applications.

Re: Time safety is more important than memory safety

#54

Post by pjmlp » Fri, Feb 14, 2020, 7:57 AM UTC

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!

Except, check the language reference for FreePascal and Go, regarding language features.

And Go still doesn't have anything comparable to Lazarus, which isn't as feature rich as Delphi/RemObjects.

Re: Time safety is more important than memory safety

#55

Post by mntmoss » Fri, Feb 14, 2020, 7:58 AM UTC

In theory, we are asymptotically approaching a stable set of programming languages - a constellation of local-optimums. When something comes along with a different name and new syntax and cleans up some semantics, it's called a new language, but that's missing the point - the intent of the programming environment it provides remains similar. And then writing code in it is no real issue.

What ties us down to old languages is the whole environment - it is Joe Armstrong's "to give a gorilla a banana you must pick up the entire jungle" run rife through our production systems. Because our code increasingly depends on globally-sourced libraries, we tend towards copying around the entire planet and so there are layers of accretion all over.

And yet emulators do exist and run software successfully. The trick there is that they have a terrarium of sorts: a boundary that limits the ecosystem. The explosions that obsolete software tend to occur where a terrarium was not planned for by the original authors, rather continuous dependence on an evolving ecosystem was taken for granted.

Re: Time safety is more important than memory safety

#56

Post by pjmlp » Fri, Feb 14, 2020, 7:58 AM UTC

shmerl wrote: post #7

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

Here is something that I can gladly agree with you.

Re: Time safety is more important than memory safety

#57

Post by carlmr » Fri, Feb 14, 2020, 8:16 AM UTC

safety-third wrote: post #30

I actually have had the pleasure of porting a program from a defunct 16-bit language called Actor to C++. It wasn't a huge deal even at around 800 kLOC. All mainstream languages in the future are going to have some combination of structured, functional, and object-oriented programming. Converting is mostly going to be about syntax and libraries. As someone who has worked with C and C++ for living for over 20 years, I…

>Rust is amazing though. I see this as the programming language of the future until the U.S. Government slams down the hammer and forces everyone to use DOD-approved Ada.

I'd be happy if we used ADA or Rust for embedded systems. They're both amazing in their own right.

Re: Time safety is more important than memory safety

#58

Post by ribs » Fri, Feb 14, 2020, 8:17 AM UTC

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

I’d call it maybe still a bit too new for applications where enterprise-level funds or harm to human life is in scope if the software fails. But it’s getting there.

Re: Time safety is more important than memory safety

#59

Post by atq2119 » Fri, Feb 14, 2020, 8:33 AM UTC

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.

The early versions of programmable vertex and pixel shaders did that by enforcing bounded loops and not having any function calls.

It turns out that that's far too restrictive as a programming model, so while modern shading languages still forbid recursion, they are otherwise unbounded.

It would be interesting if there's a more useful middle ground somewhere, analogous to what Rust does with lifetimes.

Re: Time safety is more important than memory safety

#60

Post by bitwize » Fri, Feb 14, 2020, 8:39 AM UTC

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…

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

Intel has patents on the x86 ISA. Though the basics of the instruction set (386, 486, Pentium) are outside the scope of a patent, it's impossible to write a complete emulator for a chip made within the past 20 years without infringing on Intel's IP.