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

Re: Time safety is more important than memory safety

#61

Post by littlestymaar » Fri, Feb 14, 2020, 8:45 AM UTC

pjmlp wrote: post #52

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

> Fuchsia's TCP/IP stack

Isn't it the part they decided to rewrite in Rust two years ago ? Or am I confusing with something else ?

Re: Time safety is more important than memory safety

#62

Post by pjmlp » Fri, Feb 14, 2020, 9:02 AM UTC

littlestymaar wrote: post #61

pjmlp wrote: post #52

Earlier quoted context omitted.

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

> Fuchsia's TCP/IP stack Isn't it the part they decided to rewrite in Rust two years ago ? Or am I confusing with something else ?

Netstack appears to still being used, looking at the code repository.

And even if not, gVisor keeps using it, and gVisor is used in production on Crostini and Google Cloud.

Re: Time safety is more important than memory safety

#63

Post by littlestymaar » Fri, Feb 14, 2020, 9:16 AM UTC

bitwize wrote: post #60

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…

Actually you can, in any country but the US and Japan. Software patents aren't enforceable anywhere else AFAIK (and at least not in the EU for sure). For a commercial product that's a show stopper indeed, but for an open source emulator without commercial ambitions that wouldn't be much of a problem.

Re: Time safety is more important than memory safety

#64

Post by heavenlyblue » Fri, Feb 14, 2020, 9:18 AM UTC

ribs wrote: post #58

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.

“too new”. Would you say the same about he new Boeing plane, then - too?

Re: Time safety is more important than memory safety

#65

Post by rcxdude » Fri, Feb 14, 2020, 9:18 AM UTC

bitwize wrote: post #60

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…

Nintendo claims the same about emulation of their consoles. It hasn't appeared to be much of a deterrent.

Re: Time safety is more important than memory safety

#66

Post by pjc50 » Fri, Feb 14, 2020, 9:33 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…

Emulation isn't portability. It enables you to run the program, but not to modify it and adapt it to fit in with a new platform.

Re: Time safety is more important than memory safety

#67

Post by cshenton » Fri, Feb 14, 2020, 9:33 AM UTC

heavenlyblue wrote: post #64

ribs wrote: post #58

Earlier quoted context omitted.

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.

“too new”. Would you say the same about he new Boeing plane, then - too?

The 737 max? Yeah probably.

Re: Time safety is more important than memory safety

#68

Post by raxxorrax » Fri, Feb 14, 2020, 9:33 AM UTC

0xcde4c3db wrote: post #39

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.

That is pretty common in the embedded world. ANSI C is still equivalent to C89 here, which isn't really true anymore.

Re: Time safety is more important than memory safety

#69

Post by celticmusic » Fri, Feb 14, 2020, 9:36 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 the language that the C++ Committee would make if they could start over.

Bjarne has explicitly refuted this opinion.

Re: Time safety is more important than memory safety

#70

Post by 95th » Fri, Feb 14, 2020, 9:55 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,…

Agree. At work, we have a component written in Pro* C (C + Oracle). It's about 20 years old code. All the original developers are now gone and now we're all Java developers. We had a segfault last month in production. No one was confident in the fix we did because even though we all know C (more or less), no one knew the pitfalls of C. Segfault happened in string formatting which is a very trivial thing to a Java developer. It's not yet rewritten in better language yet not because C is such good language but because rewrites are a pain. But because of the last segfault, the business is now more motivated to have it rewritten in Java.