Hacker News Reader

It is unethical to continue writing code in non-memory-safe C or C-based languages, for any purpose. Period.

I'm looking forward to seeing your new operating system and managed runtime written entirely using garbage-collected languages!

Parent poster didn't imply that the replacement would be garbage collected, just memory safe, which is a pretty big difference. I think you will see it sooner than you may think, it seems the tide may be turning.

Alright, I missed that nuance. I don't think I've ever worked with a language that provided memory safety without garbage collection.

I don't necessarily agree with the post you're replying to, but Rust is a memory-safe language without any garbage collection whatsoever. Proper unique pointers and move semantics are basically magic.

I'd be interested to know more about what you think of xenadu02's post. Practically, we can't completely stop coding in C/C++ yet, but a large class of software can be written in safer languages already, and it seems to me that once Rust is mature, we should strongly prefer it over C or C++. The security problems with non-memory-safe languages are really that bad.

What you're saying is perhaps ideal. The unfortunate reality, however, is that we really aren't seeing the "once Rust is mature" part actually happening.

There is still a large amount of change happening to the language and to the standard libraries. Some of this change has been of a here-and-there nature, where it's like they're trying to find an optimal or perfect solution that most likely does not exist.

C++11 (and C++14) may not offer the level of safety that Rust potentially could, but unlike Rust it's usable today, and using modern techniques does a reasonable job of avoiding dangerous situations.

It's been claimed that Rust will have stabilized and 1.0 will be released before the end of the year. Given that we're already into June, this becomes more and more doubtful each day. Now Rust is facing even more competition with this announcement of Swift. The longer we're forced to wait for a stable, seriously-usable release of Rust, the less viable Rust will become.

We have to be realistic. C is never going away. C++ is never going away. When has any entrenched programming language ever gone away? As someone who has been paid to write code in RPG (https://en.wikipedia.org/wiki/IBM_RPG#Example_code), I can confirm: never ever, ever ever. The best that we can do is to offer an alternative.

The reason why I put so much effort into Rust is because people who need to write the software in this space have literally no alternative that is not unsafe. Even if they cared about safety, they're screwed! Say that they need to write a library that can be written once and called from any language. That means, effectively, that they need to write that library in a language that 1) can expose a C-compatible interface, and 2) can run without a runtime. Which means, practically, that their choices of programming language are either 1) C or 2) C++. Despite Heartbleed, nobody's rushing to rewrite OpenSSL in ML. And I sure hope nobody's rushing to rewrite it in Rust either (we have no idea yet how Rust would fare for crypto, and we need time to figure that out). But once Rust is ready, you will at least have a choice. Memory safety will no longer be something that you leave on the table out of necessity.

I feel like the vast majority of the new programming languages coming out these days were conceived to make programming more pleasurable for the programmer. And yeah, I'm a programmer too, and I dislike many of the languages that I am forced to use every day. But Rust isn't about making programmers happy (although it seems to do that entirely by accident); it's about making users safer. Fewer vulnerabilities, fewer angles of attack for the baddies to exploit. And hey, if it makes software crash less, I guess that's cool too.

> We have to be realistic. C is never going away. C++ is never going away.

Not in the coming years, but it eventually will become a legacy language like RPG is, confined to old boxes running on long term maintenance contracts.

All is needed are a few mainstream OS where those languages are no longer part of the standard SDK. Like for example Microsoft just did with C as of Windows 8. Even their latest C99 compatibility changes were only done as they are required by C++11/14, nothing else.

> I feel like the vast majority of the new programming languages coming out these days were conceived to make programming more pleasurable for the programmer.

This was already possible with Lisp, Smaltalk, Mesa/Cedar, Modula-2, back when C was created, but then AT&T had better relationship with universities than Xerox PARC and ETHZ did.

The sad part, is that already in the 70's there were better alternatives, but UNIX creators just decided to ignore them and create their own language.

So they could implement SpaceWar on the PDP-11.

>Heartbleed. Majority of all SSL keys on the internet compromised. All ~2 billion of humans on the internet required to change their passwords due to a single mistake by a single programmer using C.

You can write shit code in any language - even Swift.

>how about goto fail?

I haven’t seen a goto in 20+ years. Strawman much?

>C is like saying "forget seat belts, child seats, anti-lock breaks, and adaptive steering! How can I power-slide? I want full control; I need to pump the breaks. People should just drive better, then we'd have fewer accidents”.

Yeah, and I suppose you’d prefer lumberjacks use rubber axes so they wouldn’t hurt themselves - or the trees for that matter. Life is dangerous. Get over it.

>At some point we have to admit C is no longer acceptable.

You bubble wrap your kids and lobby for lower jungle gyms at your kids schools too?

Swift doesn’t solve these problems and you sound like a self righteous ninny.

But hey - thats why there are scripting languages - for people who can’t deal with the machine. Pick one and go for it - but your scripting language isn’t suitably performant for things like audio processing (CoreAudio is in C/C++), real time control with tight tolerances, etc.

Grow the fuck up.

Sometimes you have to get your hands dirty and think hard and make stuff work. Your Swift code isn’t actually “safer” in the same way that the TSA hasn’t made flying safer - it is all security theater.

> you sound like a self righteous ninny [...] Grow the fuck up

Personal attacks are not allowed on Hacker News. Please don't post anything like this.

How about if you're developing in a field where the overhead of higher-level languages would prohibit the device from being made at all?

Do you just put on your idealist hat and say, "Sorry! I can't develop a medical device for you. You'll just have to die. At least no one was required to be careful about their programming."

> It is unethical to continue writing code in non-memory-safe C or C-based languages, for any purpose. Period.

And since memory-safe languages are written in non-memory-safe languages (i.e. C and C++), writing code in them is unethical as well, right?

Well, most implementations of Ada, Oberon and Modula-2 compilers among many others were boostraped, no C code in sight.

i registered just to say, "you're hired!"

So what other language can we use today on basically any imaginable platform, while still retaining the extreme degree of control, the excellent interoperability, and the near-optimal runtime performance of C?

Some will say Rust, but we're years away from that being realistic. C++, using modern techniques, is perhaps the only feasible response.

While there may be some validity to your claim about "billions of human beings wasting hours" due to vulnerabilities in C code, we can't forget that the alternatives would also suffer from significant forms of waste.

If using a language with slower runtime performance, for example, people will need to wait longer for their computations to complete. More powerful, or even just more, hardware will be needed to alleviate these delays. Slower runtime performance also often results in much higher energy consumption. The costs just keep adding up and up.

Forcing billions of people to use far less efficient software, while requiring far more powerful hardware, on a continual and ongoing basis, for decade upon decade, could very well generate waste that far, far exceeds that of dealing with an occasional flaw in widely-used C code. I just can't seriously buy your "All the performance benefits ever derived from writing everything in C has been more than erased, by orders of magnitude, by the damage caused from even simple innocent mistakes." argument.

C won't be going anywhere until somebody provides a practical alternative that offers benefits without any downsides. It's as simple as that.

C is dead on Windows and I hope Microsoft does not change its mind.

C is almost dead on Android, with its minimal exposure on the NDK and I hope Google does not change its mind about it.

C is now being killed on MacOS X and I look forward to Swift's success.

So this leaves out the embedded industry (slowly moving to Ada and Java on IoT) and the hardcore UNIX guys.

Hahahah C is dead? Come on, don't start that kind of bating. High-level efficiency-oriented languages are high-level efficiency-oriented languages and low-level performance-oriented languages are low-level performance oriented languages. This has been true and will continue to be true. Notice the number of high-level languages that have waxed and waned while C has continued to flourish...