1. 42
  1.  

  2. 15

    It’s a grandiose extrapolation of what Rust was supposed to be. There is a grain of truth in there — Rust really was supposed to take established post-ALGOL academic research and make it a practical, pragmatic systems programming language.

    You can get a better, straightforward explanation straight from the author: http://venge.net/graydon/talks/intro-talk-2.pdf

    1. 4

      That PDF is funny, because I don’t think a single code example can be compiled on the Rust which became 1.0. It does however explain the history of how Rust came about.

      1. 21

        Rust explored a lot of designs before 1.0. It tried to have GC pointers, Erlang-like tasks, Golang-like green threads. When people wonder “why won’t Rust just add feature X?”, surprisingly often the answer is “Rust 0.x had it, and decided not to keep it”.

        1. 2

          Classes and interfaces is my favourite feature here.

    2. 7

      Will come back to fully read. Was longer than I expected. So far, it seems to be making arbitrary claims and distinctions though. Feels like a pretty unrooted opinion piece. Hoping this gets better when I get a chance to fully read it.

      1. 5

        I read it to the end. Unfortunately it doesn’t get better.

      2. 6

        I didn’t read this blog post, but I sampled one or two paragraphs that were about things I know about, and I found them to be full of small errors or otherwise generally not true. It may be an interesting blog post, it mixes a lot of things that readers will be interested to know about, but it also seems to be globally incorrect.

        The fundamental claim of the blog post (highlighted in its TL;DR), is as follows:

        The ambition of Rust is, as I perceive it, and whether the people driving it even knows it or not, to finish what the ALGOL committe as primus motor started in 1958, and what the Garmisch NATO conference concluded was necessary in 1968: to develop a language for systems programming that rely on formal logic proof, and to fulfill what ALGOL never could, what Pascal never could, and what the whole maybe-not-700 functional programming languages never could: a language that joins the disciplines of computer science and software Engineering into ONE discipline, where the scholars of each can solve problems together.

        I think that this claim makes little sense – it is not clear that it means something precise.

        1. 11

          The historical part is drivel, there is no such planning, but I can say with some authority that the conclusion is roughly correct. Rust has described itself as a project that is academia-friendly, but industrial and at other points as the industrialization of previous research.

          1. 4

            Some more errors have been pointed out over on Reddit. I posted it here mostly because I found the history fascinating but I guess I should’ve done some validation of the author’s claims beforehand :/

            1. 1

              The article also doesn’t really make a compelling argument why Rust is the one that will successfully integrate the disciplines of software engineering and computer science, nor why it’s necessary for the language which does that to be a low-level systems language. It also presents the idea of the Linux kernel being implemented in Rust as almost a fait accompli, meanwhile from everything I’ve read, Linus Torvalds wants to keep it out of the main kernel tree for the foreseeable future.

              1. 1

                Personally I would be excited to see Rust as an accepted linux kernel language, I think it would be great if the kernel transitioned a part of its codebase to a safer language than C, with richer abstractions. I don’t think that other high-level languages (for example OCaml :-) have a large, robust enough community of systems/linux people to make this happen, so Rust is our figurehead here for “better programming”.

                1. 1

                  I think that would be too expensive, ultimately I would like to see really good, fast (OCaml-based :-) static analysis tools that would run directly next to the text editors and IDEs of C developers, and in their build pipelines. You probably know the usual suspects like Coccinelle and Frama-C/ACSL. My hope is that these will improve in ease of use until they get to the level of typecheckers like TypeScript and Mypy.

                  We need to meet C developers where they are right now, in their C codebases. Rust is a story for another day.