Hacker News Reader

Comment by AnthonyMouse | Hacker News Reader

> There would be no way to reverse decade old decisions that simply aren't the right decision anymore. Every new feature would need to be built on top of code from 1984.

Of all the reasons to prefer a new language, this is the worst one from a platform perspective.

C and POSIX allowed Unix to conquer the world. They allow code written since the 1980s to run with minimal modifications even on modern systems. The other major operating system family -- Windows -- is also strongly associated with backward compatibility.

Everybody always wants to throw away the legacy code, because maintaining it is expensive. But throwing it all away and starting over from scratch can be more expensive. Especially when you're dealing with millions of lines of third party code. Which is why the only platforms that are still popular after 30+ years are the ones that didn't force everybody to do that.

View on HN

You mean allowed security firms and black hat hackers to prosper, turning Internet on a Swiss cheese of security with an endless number of attempts of compiler saniters, process sandboxing, CPU extensions, CS research to get out of the mess.

That wasn't what the comment was about, thought, was it? Newer code base on newer language doesn't equate better security. That's a completely different discussion.

I'd say a goal of swift is to be more secure - so maybe not so far from this discussion

> You mean allowed security firms and black hat hackers to prosper, turning Internet on a Swiss cheese of security with an endless number of attempts of compiler saniters, process sandboxing, CPU extensions, CS research to get out of the mess.

I mean take over the world.

I know it's popular to hate C these days, but remember the context. The competition in the 80s and 90s were operating systems that didn't even have memory protection or the concept of user accounts. Unix was never going to lose over security.

And we're not talking about the language to write daemons or kernels in, just the system API. A system should make it easy to write your code in any language you want regardless of whether any other part of the system uses it. There isn't supposed to be a One True Language. System APIs that advantage any specific language are problematic -- which is why the C family is popular for APIs. It's simple enough that it's easy to wrap using nearly any other language.

For example, Java was the Next Big Thing around the time when IPv6 was new, and Java is "safer" than C. That would have been an opportunity for an operating system to deprecate the BSD sockets API, never extend it to support IPv6, and require internet-facing code to use a Java API in order to use IPv6.

The problem is that's just making trouble for everyone. People who want to keep using their C programs, or use any other language (like Rust) that isn't Java, will either get saddled with some awkward and slow kludge to use the Java API from another language, or will just not bother to support IPv6, making IPv6 less popular than it is already. People who do want to use IPv6 but not Java will prefer other operating systems, making a system that does that less popular in general.

It's no use to make something nominally more secure in a way that just causes people to not use it.

Just to be 100% clear, Rust can expose a C ABI for exactly this purpose. You still have to deal with unsafe around the boundary, but can keep the core fully safe.

Doing so was some of the earliest production uses of Rust, and is still among the largest.

> The competition in the 80s and 90s were operating systems that didn't even have memory protection or the concept of user accounts. Unix was never going to lose over security.

Really? Apparently we lived in different planets.

VAX/VMS, OS/360, Burroughs, AS/400, ....

UNIX was available with source code for a symbolic price to universities, that was the difference.

> VAX/VMS, OS/360, Burroughs, AS/400, ....

On mainframe hardware similar in price to a single family house. The competition on hardware individuals could hope to afford was the likes of DOS and MacOS Classic. And even on mainframes, the ones that have survived like OS/400 are the ones obsessed with backward compatibility.

It's expensive, but it looks like Apple can afford it.

Objective-C was hailed as the one true OO language by its smug fans, then Apple said one day that it's legacy software and it became legacy. Many still don't completely understand that and try to argue that it should be somehow brought back.

To those I ask: did Apple bring back the floppy, DVD, thick laptops and non-butterfly keyboards? No. Objective-C is destined for oblivion and it's time for you all to accept that.

> Objective-C was hailed as the one true OO language

Where? When?

Objective-C was always a reasoned compromise. No more, no less.

And yet it’s also the source of a huge amount of severe vulnerabilities today. It’s not as cut and dried as you make it appear, even if I do agree with your sentiment.

I certainly agree that deprecating millions of lines isn't a great way to win over developers. Apple hasn't deprecated Objective-C yet though, and I think both Swift and Objective-C will be supported side by side for a long time yet.

Apple is usually quick to deprecate (which does have its own advantages), but given that a large part of their own tech stack is built on Objective-C, I think they'll play the long game here. I would be surprised to see it deprecated before the end of next decade (although I wouldn't put it past Apple either...).

We have 40 years of legacy code in C but essentially all of it fails catastrophically at random. If we ever want a platform that actually works we have to start from zero undefined behavior.

Reply on news.ycombinator.com