6 ms·

I don’t think Rust syntax and patterns (no classes) are especially elegant for many tasks. I can’t express the behavior of a system as cleanly in Rust as TypeSc

• foota 1y ago
  This is a bizarre take to me, what do you want to do with classes that aren't supported by structs and traits? Imo the usability issues with rust arise from the borrow checker and associated complexity + restrictions on patterns, so I'm surprised that you're citing macros and classes.
  • the__alchemist 1y ago
    I'm confused too! When I write Python, I do it in a similar style as rust, but knowing the classes and enums are sloppier than rust's; regarding mutation for example.
  • AnimalMuppet 1y ago
    Access control. Here's a struct that maintains an invariant - say, that field a is less than field b. That invariant should be set when it is created. You find a bug where a is greater than b. Where is the bug? With a struct, it can be anywhere in the code - any line that touches the struct. But with a (well designed) class, a and b are private, and so you only have to look at lines of code within the class. The surface area where the bug can be is much smaller. The bigger the code base and the more well-used the class is, the more this matters.
    • foota 1y ago
      Ah, that makes some sense, although some reading says that struct member visibility is by default the module, which is a file if you don't do anything. If you wanted you could probably just wrap all the structs you want to be protected inside a module per file? It is a bit annoying though. I guess the issue here is that in rust struct fields need to be accessed for trait implementations. It wouldn't be backwards compatible obviously, but I wonder if they could have tightened that so that by default only trait implementations for a struct can access that structs members?
    • joshmarinacci 1y ago
      You can do exactly this in rust using non public fields and accessor methods.
    • Dr_Emann 1y ago
      Rust has access control. Fields are private by default.
    • 3836293648 1y ago
      Rust has exactly that. The difference is that rust considers the scope of private access te be the entire file it's defined in, not just its methods.
      • kibwen 1y ago
        Just the module the struct is defined in, not the file. Easy mistake to make, given that a file is implicitly its own module, but you can create submodules within a file with the `mod` keyword.
        • 3836293648 1y ago
          I thought it crossed into submodules as well, making it the entire file?
    • kibwen 1y ago
      Rust has privacy and encapsulation just fine. More than that, Rust's entire safety story is built on these mechanisms; being unable to (safely) access private fields outside of the module in which they were defined is load-bearing when it comes to safely encapsulating unsafe code.
• hu3 1y ago
  > If I clone a Rust repo, it’s actually easier to compile, test, and run the code than any other language. I beg to differ because Go has a large standard library which means less dependencies than Rust on average.
  • AlotOfReading 1y ago
    It's not usually the standard library or dependencies that create the issues I've seen. The teams I work with producing Go tools (across multiple companies) invariably require carefully orchestrated dev environments that are nigh-unreproducible. It's 50/50 on whether I can actually build a random project first try without reading the instructions if CGO is involved, which seems to be all of them. My experience with random rust projects is that they usually "just build", with limited exceptions like weird embedded stuff.
    • 0x696C6961 1y ago
      Rust projects which depend on C libs have very similar issues.
      • timschmidt 1y ago
        Well yeah, because C has those issues. People like to clown on the Rewrite It In Rust attitude, but it comes with real benefits.
      • treyd 1y ago
        I haven't experienced this. Rust's build system allows you to automate most of the pain in building/bundling those dependencies, so it's just up to the builder to have the right headers (if they're not bundled). That makes it no worse than meson C/C++ builds. In Go, it doesn't have any of that so it depends on the end builder of the binary to be aware of all the C dependencies and manually manage integrating the cgo configuration into their build process.
        • estebank 1y ago
• sitzkrieg 1y ago
  > If I clone a Rust repo, it’s actually easier to compile, test, and run the code than any other language zig is very comparable, and much faster at doing so. zig also comes with a build system, libc and can compile c programs. its a better c compiler and build system than most, lol.
  • treyd 1y ago
    But Zig doesn't have the very sophisticated type system that Rust has. Nor does it, importantly to DARPA, have the memory safety that Rust does.
    • jmull 1y ago
      A type system in programming languages is a way to express and enforce compile time constraints (conventionally, anyway). zig's type system is pretty straightforward, but its comptime is very powerful and, among other things, can enforce arbitrary compile time constraints. It's not the same as rust's types, but I wonder if it isn't better in many ways.
      • treyd 1y ago
        It's not comparable, comptime is more of an alternative to macros. You can build complex systems with it, but they don't natively give you the algebraic reasoning abilities that the typechecker does, at best you'd have to reimplement it yourself in an ad hoc way. Rust's proc macros are also fully programmable and have comparable expressive power to comptime.
        • Rendello 1y ago
          I used Zig in the past (after my "why don't we just write everything simply in C" phase). I don't think I used comptime too much, but I understood why it would be useful. Now I write Rust and absolutely love it, except for the damn macro edge cases, like not being able to use a known-at-compile-time string for format!() unless it's a literal (I even tried to fake it with more macros, no dice). I think Zig's Andrew Kelley mentioned this exact scenario, if I recall correctly. It's funny because I do write a lot of code that generates code, but I avoid macros if I can.
• mrheosuper 1y ago
  >dep hell As a C programmer, i'm always a little panic how a small Rust Program can pull in that many crates when compiling.
  • james7132 1y ago
    Once you understand that a crate is the translation unit in Rust, it doesn't feel as bad. Most medium to large Rust project's will separate out their code into separate crates for both organization and compile time. I've definitely cloned down my fair share of C projects, mashed the make command into my terminal, and watched the gcc/clang logs fly by and never batted an eye beyond checking the sha256sum on any downloaded tarballs. There's a valid argument to be made about supply chain attacks, but there does exist tooling to lock that down, and I would argue that any serious software development firm should be auditing every third party dependency they take on.
• AbuAssar 1y ago
  > It avoided the fragmentation of JS/TS (npm, yarn, pnpm, bun, deno) just use npm, the others are just more options, thersr is no "fragmentation"
• iberator 1y ago
  Not everyone likes OOP you know? Some people love low abstraction code.