4 ms·

I feel like we're seeing a bit of push-back today against worse-is-better in the area of languages. Rust in particular feels more like the MIT approach, albeit

by api 2y ago

I feel like we're seeing a bit of push-back today against worse-is-better in the area of languages. Rust in particular feels more like the MIT approach, albeit with an escape hatch via the explicit keyword "unsafe." Its type system is very thoroughly specified and correct as opposed to C's YOLO typing.

djha-skin 2y ago
I actually take this as evidence that Rust will always remain niche. It's just a very complicated language. Go or Zig is much easier to learn and reason about. In Go you can immediately tell what the fields are in a config yaml file just by looking at struct annotations. Try doing that with Rust's Serde. Super opaque in my opinion.
- busterarm 2y ago
  Exactly! Rust will only protect me from things my customers don't care about and don't understand. By not using Rust and just dealing with it, I'm making more money faster than if I started with Rust. Rust only matters in environments where that calculus comes out the other way.
  - warkdarrior 2y ago
    > Rust will only protect me from things my customers don't care about and don't understand. That's the wrong kind of protection. Rust should protect you from things people other than your customers (who presumably are well behaved) care about.
  - crabmusket 2y ago
    I'm pretty sure your customers care that your software doesn't segfault!
    - busterarm 2y ago
      My customers aren't running my software, I am. They don't know if it segfaulted or not. If your customers are running your software you might have a business model problem instead of a software quality one.
  - morning-coffee 2y ago
    > Rust will only protect me from things my customers don't care about and don't understand. Are you suggesting your customers don't care about CVE's, even indirectly when it affects them?
busterarm 2y ago
Disagree. I think this is a self-delusion experienced by Rustaceans because they overvalue a certain type of software correctness and because Rust gets that right, the rest of its warts are invisible.
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.

by api 2y ago

djha-skin 2y ago

I actually take this as evidence that Rust will always remain niche. It's just a very complicated language. Go or Zig is much easier to learn and reason about. In Go you can immediately tell what the fields are in a config yaml file just by looking at struct annotations. Try doing that with Rust's Serde. Super opaque in my opinion.

busterarm 2y ago
Exactly! Rust will only protect me from things my customers don't care about and don't understand. By not using Rust and just dealing with it, I'm making more money faster than if I started with Rust. Rust only matters in environments where that calculus comes out the other way.
- warkdarrior 2y ago
  > Rust will only protect me from things my customers don't care about and don't understand. That's the wrong kind of protection. Rust should protect you from things people other than your customers (who presumably are well behaved) care about.
- crabmusket 2y ago
  I'm pretty sure your customers care that your software doesn't segfault!
  - busterarm 2y ago
    My customers aren't running my software, I am. They don't know if it segfaulted or not. If your customers are running your software you might have a business model problem instead of a software quality one.
- morning-coffee 2y ago
  > Rust will only protect me from things my customers don't care about and don't understand. Are you suggesting your customers don't care about CVE's, even indirectly when it affects them?

busterarm 2y ago

Disagree. I think this is a self-delusion experienced by Rustaceans because they overvalue a certain type of software correctness and because Rust gets that right, the rest of its warts are invisible.

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.