Hacker News Reader

That comment was great. It's so hard for me (raised on Windows and now immersed in Linux) to imagine something so foreign to the OS paradigms I'm used to. It just goes to show how much the things you are used to can limit your thinking.

Windows NT was supposed to be a modernized VMS (And legend has VMS+1=WNT, each letter individually…) - and given a face similar to Win 3.1 (and then 95/98/Me and then they were unified in XP)

It has a lot of the VMS features, and most of them are unused or effectively only used by malware (e.g. alternate file streams).

I did not get a chance to use VMS myself, but I did use Unix (and VMS/CMS, and a bunch of other OSes) at a time VAX was still a viable alternative even for greenfield projects.

My impression is that it is sort of like J/K/APL - powerful, compact, coherent, got almost everything right from a technical standpoint - but not friendly, feels foreign, and not liked by anyone who has ever used a Unix, or Windows, or a Mac - which is 99% of the relevant population since about 1985.

(Added): Macs also had multiple file streams (“forks”). It doesn’t anymore, for many reasons, but the chief one is interoperability. Less is more, worse is better.

Re file streams yes classic macOS did have them current macOS does not but it does not need them as you can use Bundles instead which are Unix directories that are treated as a whole by the SDKs.

Which goes to show why *nix won over more feature rich alternatives - the human element. Being feature rich makes the learning curve (usually) much steeper but tends to help in the long-term, while shifting the complexity in to userland means that if I don't need a feature, it needn't concern me.

You trade ability for reduction of complexity - getting an operating system that you can learn in months instead of years, which - since the tech industry has been in hipper-growth phase for much of the last 30 years, was more important.

Being free didn't hurt either.

Indeed, had AT&T been able to sell UNIX at VMS prices (or whatever else OS from those days) from day one, without access to source code, and history would have taken a different path, regarding UNIX and C adoption.

>Windows NT was supposed to be a modernized VMS (And legend has VMS+1=WNT, each letter individually…) - and given a face similar to Win 3.1

Same with HAL (1) and IBM, I read somewhere once.

(1) The one from https://en.m.wikipedia.org/wiki/2001:_A_Space_Odyssey

Google hal ibm connection.

> Windows NT was supposed to be a modernized VMS

Given Cutler hated UN*X, that only makes sense. NT did a lot of things right at the kernel level.

> and most of them are unused or effectively only used by malware (e.g. alternate file streams).

"Most of them unused"?

ADS was added to NTFS to support Mac OS file sharing over AFP ("Services for Macintosh"). Microsoft makes use of it for downloads from Edge, among other things. It's otherwise not a supremely useful feature and one that you'll silently lose data when moving to another fs/www further degrading it's usefulness.

I can't imagine any new systems programming languages gaining traction that aren't at least as safe as Rust.

Am I allowed to sigh here? It's a good thought, but this is humanity we're talking about here.

All it requires is some big-project, some big-corp creating some essential ecosystem with lame-language-A, and now it's got traction.

And frankly, look at rust and its weird crates. Weird as in "Let's make a super-safe language, then import random stuff from unknowns, unaudited, and just hope it all works out."

If rust was really serious about security, only signed crates from validated developers, with code review would be the norm. Oh but wait, that'd be "not easy".

What's your suggestion, exactly?

Vetting code is extremely expensive in terms of human time and human energy. Sadly it's not only a problem for Rust, it's a problem for every single programming language out there.

> The history of computing has many examples of products and languages winning out over technically superior alternatives for non-technical reasons.

While this is undoubtedly true, i suspect that there are also many cases where people presume the reasons are non-technical but when examined closly turn out to have hidden technical issues.

> At this point I can't see us going back to the way things were. I can't imagine any new systems programming languages gaining traction that aren't at least as safe as Rust.

Zig seems to be gaining traction. Hard to predict whether it will succeed or slowly fizzle out after the initial excitement phase though.

Is Zig gaining traction? It almost seems like the project has gone radio silent in the past year. It's hard for a language to get traction when it's not even 1.0 and there's not much of a roadmap on how and when they'll get there.

> I can't imagine any new systems programming languages gaining traction that aren't at least as safe as Rust.

I don't think safety is a 1 dimensional spectrum (say from 0% to 100%). I view it more as a multidimensional thing, and tradeoffs between these dimensions.

Rust invested a lot on _some dimension_ of safety, which is essentially static borrowing and aliasing. And the tradeoffs for this are numerous: Dynamic safety is either much harder in Rust (due to unsafe being vastly more dangerous and hard to get right vs say, a C program), or at the expense of performance (I.e. just Arc<Mutex<>> or copy everything). That also comes at the expense of an immense cognitive burden for the programmer.

I see a lot of space for different tradeoffs on different dimensions of safety.

> due to unsafe being vastly more dangerous and hard to get right vs say, a C program

It's not true. Both C (clang), C++, and Rust use same LLVM compiler, so both have same constraints in the unsafe mode. C/C++ developers just not care.

I don't think this is true. Rust has constraints that C/C++ doesn't have. For instance, it's undefined behavior to create more than one exclusive (mutable) reference to the same object or to create one where a shared reference already exists. This is not necessarily easy to ensure.

The aliasing rules in C are much more lax: you only can't have several pointers of different types pointing to the same object, except if one of them is a character pointer (ignoring the restrict keyword, which is opt-in and rarely used).

I don't think this is quite the same comparison. In Rust, multiple mutable pointers to the same object can exist at the same time. So, it's similar to C in this way. It is mutable references that must be exclusive.

It's besides the point whether C pointers are more similar to Rust pointers or references. It's even true that pointers BY THEMSELVES have fewer constraints in Rust than in C . It's in the interaction between pointers and references that it's very easy to trigger undefined behavior in Rust.

Besides the fact I already mentioned about the dangers of casting pointers to references, there's also the problem that pointers are only valid as long as no operations are done with references to the same object (no interleaving). On top of it, the autoborrowing rules make it so it's not always clear when a reference is being taken (and operated upon).

So yes, in my opinion _unsafe_ Rust is significantly more difficult to get right than C.

Rust has stricter rules than C++. E.g. global mutable variables are way more dangerous in Rust than in C++ - just creating a reference to it can be immediate undefined behaviour.

In Rust, use UnsafeCell.

In C++, multiple references to the same variable may cause «use after free» bug in it destructor.

But only Rust uses its equivalent to C "restrict" wrt. its shared and mutable references (unless dealing with UnsafeCell<>) for alias analysis optimization. (In fact, this used to trigger bugs in LLVM because it was hard to test its aliasing optimizations with purely C code.)

It’s not just restrict. Rust indeed does have much more strict rules that even though at first glance seem similar to C, the optimizer is allowed to do weird things if you violate a lot harder to understand rules. This has been very well documented.

For example, if I recall correctly it’s technically UB to cast to a *mut pointer unless the original variable was declared mut even if you have exclusive ownership over that object.

There was a fantastic blog post describing a lot of these nuances but I can’t find it.

> I don't think safety is a 1 dimensional spectrum (say from 0% to 100%). I view it more as a multidimensional thing, and tradeoffs between these dimensions.

Absolutely. This is evident in the different language features of Rust and Ada. At any rate, Rust has advanced the state of the art when it comes to memory safety. The next generation of programming languages are inevitably going to be compared against Rust. In the same way Rust has been compared against Ada. Especially given Rust's popularity. I imagine that if a next-generation 'systems language' can't at least match Rust's features, it won't achieve wider adoption.

> At this point I can't see us going back to the way things were. I can't imagine any new systems programming languages gaining traction that aren't at least as safe as Rust.

I see Rust being used in many context where it's safety features aren't really needed or even a hindrance like game dev.

Honestly the safety is overstated in importance. The amazing tooling, decent package manager, great error messages, the inclusive community, the type system that took the low hanging fruits from the academic functional programming world, are much more relevant for its success.

The problem with Rust is that it made using languages without automatic garbage collection acceptable again and I am not sure if this is good. The borrow checker is a neat solution and might be a good fit for certain niches but automatic garbage collection is just vastly more ergonomic to use.

We had Lisp Machines, we need to go back to future.

I'm with you - I like Rust for the overall pros/con balance, in context of with its alternatives. Safety is one thing. The tooling, error messages, type system etc you mention is another. Having mutable references as function parameters is another big one, shared by surprisingly few alternatives.

Safety and the hype reels you in and the qol hooks and keeps you.

Is that QOI or QOL, and what does it stand for?

Quality of life

GC implementations are widely available in Rust. You don't have to use garbage collection in Rust, but it doesn't stop you either. You just have to import some custom crate and 'implement' tracing for your own data types.

You will see their limitations when working with futures. That's really the number 1 pitfall in the language.

I've written Rust professionally for the past 6 years, and pretty much exclusively for stuff where memory safety is the least of my concerns (even speed!). I've made gRPC APIs, agents running on machines to setup configuration and such. The usual suspects for this work would usually be Python or Go.

You've pretty much summed up why I'm standing behind Rust for non-memory-critical applications: tooling, error messages, and the type system. For business logic, you cannot beat all that, as a lot of business errors can be avoided using those (all praise the Rust enums!). Also, you've summarized my feeling about the functional world embraced by rust: it provides quite a bit, without requiring a Haskell PhD to write it. Seriously, iterators and the associated trait are a godsend (even though having to always write .iter()....collect() is sometimes clunky).

As for the GC. I've yet to come to situations where the lack of GC was the real hindrance. It has more to do with futures adding not easy to grasp lifetime bounds to data, but one quickly learns to embrace it by moving data when needed. Combined with channels and Arc, there are many escape hatches making in my opinion the GC a non-issue.

IMHO, making GC-less languages acceptable again is a good thing, because it keeps diversity in the ecosystem and gives options. It also shows that doing without GC does not relegates written code to manual memory management like C/C++. In fact, Swift does the same and is pretty good at being a GC-less language. Both Rust and Swift are languages where memory management is opinionated by embedding it in the language, and thus ergonomic. Frankly, I rarely think about "oh hey, I wished I had a GC".

Exactly. I love Rust. If I could write Rust with just a GC enabled / No borrow checker, I would never choose another language.

> The history of computing has many examples of products and languages winning out over technically superior alternatives for non-technical reasons.

Unfortunately, the history shows that such technically inferior languages and products winning out are also because of outright market manipulation by their corporate backers, tons of money in ads, or attacks on competitors. The elephant in the room, is to look at what's generating or paying for the hype and marketing behind recent programming languages like Rust and Zig (for example).

> I think that the massive groundswell of interest around Rust...

A review of the groundswell, around Rust or Zig, is its not attributable to just grassroots or genuine interest, and can significantly be the result of outright astroturfing and artificial brigading. Sadly, many people follow along with the marketing or are bombarded into submission, "must rewrite in X" or "GC all bad and manual all good" foolishness, versus actual use case and legitimate examination of language tradeoffs.