[nudq]

I like how these three points aren't just "strengths of Rust", but...

> the necessary components ... to make imperative programming work as a paradigm

You know, before Rust imperative programming just didn't work. Didn't work as a paradigm, even!

[swsieber]

> Rust works because it enables users to write in an imperative programming style, which is the mainstream style of programming that most users are familiar with, while avoiding to an impressive degree the kinds of bugs that imperative programming is notorious for.

That's from the previous paragraph. So yeah, out of context it's a bad quote, but in the context it's a little less hoity toity.

[_bxg1]

It had state mutation as a massive liability - which is probably why FP has seen such a surge in recent years. Rust is the only language that mostly solves that without totally changing the paradigm.

[0815test]

It doesn't really change the paradigm compared to FP even, it just enforces a clear separation at all times between sequential state mutation on the one hand and references to shared (and generally immutable, except as provided for by explicit mutability mechanisms) state on the other. Which is essentially what FP languages end up doing, though they go about it somewhat differently.

[_bxg1]

Right. The problem is that functional purity always comes with overhead; data structures like Clojure's help a whole lot, but there's still a cost.

But one of the primary motivators for functional purity is to avoid unintended side-effects.

In pure FP, You never even have to bother your mind with unexpected side-effects because there are no side-effects.

Rust instead gives you the vocabulary to carefully articulate intended side-effects, preventing all other, unexpected side-effects at the same time. So you can colonize the wilderness, instead of avoiding it altogether, and for that you get to skip the overhead of treating everything as immutable. Not that this is an indisputable improvement for every use-case, but it's a novel tradeoff and one that is definitely preferable in many domains.

[skohan]

There seems to be a certain train of thought within the Rust community that unsafe languages are fundamentally invalid. I saw a comment on another forum claiming that C++ was even unsuitable for personal, experimental projects because unsafe code == undefinted behavior, and therefore your program produces "random results" which would not be fit for, say, scientific inquiry.

Apparently the Linux kernel, and all code written before 2010 is just completely random!

[lmm]

> Apparently the Linux kernel, and all code written before 2010 is just completely random!

The Linux kernel is well known to be completely random when considered as a C program: building something useful out of it relies on a particular set of flags and ad-hoc implementation details of GCC (e.g. -fno-delete-null-pointer-checks).

[skohan]

> building something useful out of it relies on a particular set of flags and ad-hoc implementation details of GCC (e.g. -fno-delete-null-pointer-checks).

That makes it esoteric, not random. If the Linux kernel really did produce "random output" there is no way it would serve as the backbone of the global computing infrastructure, the financial system etc.

[tomp]

From my observations, there seem to have been considerable efforts to avoid it being just random. Compiler & library "optimisations" have broken Linux before ("randomly") [0] [3]. Linus has ranted about this [1], multiple times [2] [3].

[0] https://lwn.net/SubscriberLink/793253/6ff74ecfb804c410/

[1] https://lkml.org/lkml/2018/6/5/769

[2] https://bugzilla.redhat.com/show_bug.cgi?id=638477#c129

[3] http://lkml.iu.edu//hypermail/linux/kernel/1407.3/00650.html

[lmm]

> That makes it esoteric, not random. If the Linux kernel really did produce "random output" there is no way it would serve as the backbone of the global computing infrastructure, the financial system etc.

To the extent that Linux is useful, it's not written in C. The particular binaries produced by GCC with particular flags have particular behaviour, more or less, but considered solely as a C program in terms of the C standard (i.e. behaviour on the C abstract machine), Linux does produce random output.