3 ms·

Rust is not the MIT approach, because an important aspect of that approach is that it's conceptually simple. Rust is a leviathan of complexity both in interface

by dokyun 2y ago

Rust is not the MIT approach, because an important aspect of that approach is that it's conceptually simple. Rust is a leviathan of complexity both in interface and implementation. Common Lisp is an MIT approach language, and approaches the same problems like memory and type safety by doing "the right thing" by default and offering more advanced options like type annotations and optimization levels in a "take it or leave it" manner. Rust will force you to program the way the compiler wants in the name of safety, while Common Lisp will allow you to program safely and freely, and decide which parts are important. An observation of this idea is that Rust compilers are terribly huge and slow because they use static type-tetris for everything, while Common Lisp compilers are very fast because they do most type-checking at runtime.

steveklabnik 2y ago
> An observation of this idea is that Rust compilers are terribly huge and slow because they use static type-tetris for everything, Rust's typechecking passes are not the reason why the compiler is slow. Code generation dominates compile times. Type checking is pretty quick, and Rust makes some decisions that enable it to do so, like no global inference.
- dokyun 2y ago
  ....so why is it so slow to generate code?
  - steveklabnik 2y ago
    The compiler doesn't do a whole lot to try and minimize LLVM-IR, and monomorphization produces quite a lot of it. This makes LLVM do a lot of work. (EDIT: maybe that's being too harsh, but what I mean is, there's been some work towards doing this but more that could possibly be done, but it's not a trivial problem.) On my current project, "cargo check" takes ten seconds, and "cargo build" takes 16. That's 62.5% of the total compilation time taken by code generation, roughly (and linking, if you consider those two to be separate). In my understanding, there can sometimes be problems with -Z time-passes, but when checking my main crate, type_check_crate takes 0.003 seconds, and llvm_passes + codegen_crate take 0.056 seconds. Out of a 0.269 second total compilation time, most things take less than 0.010 seconds, but other than the previous codegen mentioned, monomorphization_collector_graph_walk takes 0.157s, generate_crate_metadata takes 0.171 seconds, and linking takes 0.700 seconds total. This general shape of what takes longest is consistent every time I've looked at it, and is roughly in line with what I've seen folks who work on compiler performance talk about.
    - hollerith 2y ago
      Have you heard of anyone proposing to add to rustc a flag or an attribute that would cause a generic type to be implemented by a dispatch at run time to avoid monomorphization and consequently decrease compile time?
      - steveklabnik 2y ago
        It’s been discussed, but not every trait is object safe, so it’s not a trivial task.
- deleted 2y ago
  [deleted]
api 2y ago
That's an interesting counter-take and it makes me wonder if Rust isn't a third thing... not the clean sparse MIT approach but also not the wild YOLO slop of C and Unix. Something correct but also complex and pragmatic. Maybe it's an attempt at a synthesis of the two -- Unix's gnarly pragmatism but with correctness. My heart loves the clean sparse MIT approach, but I'm kinda forced to work in the other world because that approach has so far decisively failed. I have my own thoughts as to why, and they're different from the typical ones: (1) Worse is free -- the "worse" stuff tended to be less encumbered by patents and closed source / copyrights. This is particularly true after GNU, BSD, and Linux. Free stuff is viral. It spreads fast and overtakes everything else. (2) Programmers like to show off, and "worse" provides more opportunities to revel in complexity and cleverness.
- dokyun 2y ago
  > That's an interesting counter-take and it makes me wonder if Rust isn't a third thing... not the clean sparse MIT approach but also not the wild YOLO slop of C and Unix. Something correct but also complex and pragmatic. I had supposed this in a previous thread, and I agree it is another thing entirely, however whether Rust is 'correct' or 'pragmatic', I think is a matter of contention. > (1) Worse is free -- the "worse" stuff tended to be less encumbered by patents and closed source / copyrights. This is particularly true after GNU, BSD, and Linux. Free stuff is viral. It spreads fast and overtakes everything else. At the time it seems that the "worse" stuff was actually more encumbered--GNU started to exist as a consequence of Unix both becoming an industry standard and solidifying the position of nonfree software in industry, and it didn't get that way by being free--they simply licensed it away en masse to universities. The free software movement was born out of the MIT hacker ethic of sharing software freely (GNU brought the design philosophy of MIT to Unix systems, and largely stands opposed to the "worse is better" approach. It originally sought to replace parts of Unix with superior alternatives, such as Info over man pages). BSD didn't become free until much, much later, at which point Linux had already become relevant. > (2) Programmers like to show off, and "worse" provides more opportunities to revel in complexity and cleverness. I think maybe C or C++ lets you show off by hacking around the compiler to do certain things that look impressive like preprocessor hacks or obfuscated code, but I think many would agree that this kind of style isn't "correct": languages like Go were developed as a consequence of this in order to suck any and all fun you might get out of hacking C, in order to force you to write more "correct" programs. Lisp, on the contrary doesn't tell you what a correct or incorrect program is, and gives you every facility to write programs that are infinitely complex and clever. To me, Rust looks like the result of trying to break the rules of industry languages, by trying to incorporate things like real macros and type systems into something that resembles a real-world language. But it's biggest flaw to me is that it doesn't break enough of them, rather it makes more in the process.

by dokyun 2y ago

steveklabnik 2y ago

> An observation of this idea is that Rust compilers are terribly huge and slow because they use static type-tetris for everything, Rust's typechecking passes are not the reason why the compiler is slow. Code generation dominates compile times. Type checking is pretty quick, and Rust makes some decisions that enable it to do so, like no global inference.

dokyun 2y ago
....so why is it so slow to generate code?
- steveklabnik 2y ago
  The compiler doesn't do a whole lot to try and minimize LLVM-IR, and monomorphization produces quite a lot of it. This makes LLVM do a lot of work. (EDIT: maybe that's being too harsh, but what I mean is, there's been some work towards doing this but more that could possibly be done, but it's not a trivial problem.) On my current project, "cargo check" takes ten seconds, and "cargo build" takes 16. That's 62.5% of the total compilation time taken by code generation, roughly (and linking, if you consider those two to be separate). In my understanding, there can sometimes be problems with -Z time-passes, but when checking my main crate, type_check_crate takes 0.003 seconds, and llvm_passes + codegen_crate take 0.056 seconds. Out of a 0.269 second total compilation time, most things take less than 0.010 seconds, but other than the previous codegen mentioned, monomorphization_collector_graph_walk takes 0.157s, generate_crate_metadata takes 0.171 seconds, and linking takes 0.700 seconds total. This general shape of what takes longest is consistent every time I've looked at it, and is roughly in line with what I've seen folks who work on compiler performance talk about.
  - hollerith 2y ago
    Have you heard of anyone proposing to add to rustc a flag or an attribute that would cause a generic type to be implemented by a dispatch at run time to avoid monomorphization and consequently decrease compile time?
    - steveklabnik 2y ago
      It’s been discussed, but not every trait is object safe, so it’s not a trivial task.
deleted 2y ago
[deleted]

api 2y ago

That's an interesting counter-take and it makes me wonder if Rust isn't a third thing... not the clean sparse MIT approach but also not the wild YOLO slop of C and Unix. Something correct but also complex and pragmatic. Maybe it's an attempt at a synthesis of the two -- Unix's gnarly pragmatism but with correctness. My heart loves the clean sparse MIT approach, but I'm kinda forced to work in the other world because that approach has so far decisively failed. I have my own thoughts as to why, and they're different from the typical ones: (1) Worse is free -- the "worse" stuff tended to be less encumbered by patents and closed source / copyrights. This is particularly true after GNU, BSD, and Linux. Free stuff is viral. It spreads fast and overtakes everything else. (2) Programmers like to show off, and "worse" provides more opportunities to revel in complexity and cleverness.

dokyun 2y ago
> That's an interesting counter-take and it makes me wonder if Rust isn't a third thing... not the clean sparse MIT approach but also not the wild YOLO slop of C and Unix. Something correct but also complex and pragmatic. I had supposed this in a previous thread, and I agree it is another thing entirely, however whether Rust is 'correct' or 'pragmatic', I think is a matter of contention. > (1) Worse is free -- the "worse" stuff tended to be less encumbered by patents and closed source / copyrights. This is particularly true after GNU, BSD, and Linux. Free stuff is viral. It spreads fast and overtakes everything else. At the time it seems that the "worse" stuff was actually more encumbered--GNU started to exist as a consequence of Unix both becoming an industry standard and solidifying the position of nonfree software in industry, and it didn't get that way by being free--they simply licensed it away en masse to universities. The free software movement was born out of the MIT hacker ethic of sharing software freely (GNU brought the design philosophy of MIT to Unix systems, and largely stands opposed to the "worse is better" approach. It originally sought to replace parts of Unix with superior alternatives, such as Info over man pages). BSD didn't become free until much, much later, at which point Linux had already become relevant. > (2) Programmers like to show off, and "worse" provides more opportunities to revel in complexity and cleverness. I think maybe C or C++ lets you show off by hacking around the compiler to do certain things that look impressive like preprocessor hacks or obfuscated code, but I think many would agree that this kind of style isn't "correct": languages like Go were developed as a consequence of this in order to suck any and all fun you might get out of hacking C, in order to force you to write more "correct" programs. Lisp, on the contrary doesn't tell you what a correct or incorrect program is, and gives you every facility to write programs that are infinitely complex and clever. To me, Rust looks like the result of trying to break the rules of industry languages, by trying to incorporate things like real macros and type systems into something that resembles a real-world language. But it's biggest flaw to me is that it doesn't break enough of them, rather it makes more in the process.