What do people love about Rust? | Rust Blog
blog.rust-lang.org
Empowering everyone to build reliable and efficient software.
  • Ephera@lemmy.mlEnglish
    8·
    2 天前

    “I think proc macros are a really big superpower for Rust.”

    Yeah, been working on a framework and proc-macros are really useful to simplify the API.

    For example, previously I needed users to define a struct and then an impl block with a function inside. Well, and they need to do that a lot, so it was genuinely a bit of a pain to write out, but it also made the code feel more complex than it really was.

    Now I’ve got an annotation, which you can slap onto a function and then it generates the struct from the function parameters and puts the function into the impl block.
    And while you do need to be aware that the function parameters will be put into a struct and therefore you want owned parameters, all-in-all it still feels really nice to just delete dozens of boilerplate lines and an indentation level in the codebases where I’ve introduced it.

    • Matt@lemmy.ml
      2·
      13 小时前

      Unfortunately, proc-macros need to be in a separate crate. It’d be great if we don’t have to do that.

      • Ephera@lemmy.mlEnglish
        1·
        11 小时前

        Yeah, as I’m implementing this, I’m also now noticing how problematic that crate split is.

        If you want to generate code which uses (non-generated) types that your crate provides in its public API, you have to re-export the macro from a separate crate that also re-exports the types.
        That in itself is clunky, but it’s just complexity for the implementer, not the user, so it’s fine.

        But where it stops being fine is that this means you cannot easily provide a usage example in the macro’s documentation.
        If you try to use it like normal, it has to generate code referring to your API crate, which will not be defined in your macro crate, so the documentation test won’t compile.

        So, basically your choices are:

        • Do some hacky horseshit, where you try to re-define the public API in the usage example.
        • Provide a usage example, which is not checked for compile errors.
        • Provide a usage example on the module that re-exports the macro rather than on the macro itself.
        • Don’t provide a usage example.

        And yeah… if you’ve coded Rust for long enough, you will recognize these patterns of bad/missing usage examples, which is particularly problematic, because proc-macros are rarely terribly obvious to use. Really hope they can fix this sooner rather than later.
        As far as I can tell, it would even be a valid fix, if editors and such consistently showed the documentation declared on top of the re-export, then you could write out your usage example there.

    • FizzyOrange@programming.dev
      17·
      2 天前

      Yeah it’s great for little scripts. There’s even a cargo script feature that’s being worked on so you can compile & run them using a shebang.

      I’d use a shell script if it is literally just a list of commands with no control logic or piping. Anything more than that and you’re pointing a loaded gun at your face, and should switch to a proper language, of which Rust is a great choice.

    • 5C5C5C@programming.dev
      34·
      2 天前

      Honestly yes. If I need to manipulate the filesystem or manage processes with any amount of conditional logic or looping, I’d much rather do it with Rust than shell scripts.

      The only thing I use shell scripts for anymore is completely trivial sequences of commands.

        • Ephera@lemmy.mlEnglish
          13·
          2 天前

          One of the simplest tricks is that you can throw down a function, which you can call with a command like e.g. this: run("cat /etc/os-release | grep NAME")
          by constructing a Command like so:

          Command::new("sh")
    .arg("-c")
    .arg(command) //the string passed as parameter

          There’s proper libraries to make running commands even easier and more robust, but if you don’t want to pull in a library, that’s really easy to write out ad-hoc and gets you 95% of the way there, with shell piping and everything.

            • FizzyOrange@programming.dev
              6·
              15 小时前

              That’s kind of the point. You can do it in most languages, so why use a shitty one like Bash? Use a good language like Rust!

              Also there are aspects of languages that make many languages less suitable for this application though. For example Python, because you can’t use third party dependencies (or at least you couldn’t; I think uv has an equivalent of cargo script now). Java would be a pretty awful choice for example.

              • 1984@lemmy.today
                1·
                13 小时前

                Python is actually super known for its batteries included approach, it has modules for everything. Simply do pip install anything. But best practice is to use a python virtual environment and install packages into that one. Cargo does this by itself in each project and doesnt install modules globally.

                But python code is so much easier to write. Its basically almost English and the syntax is easy. Rust… Not so much. Its quite ugly.

                Its a systems programming language. Designed to be fast to execute. Its one of the slowest to write code in. But sure, with Ai, you can just ask for a rust script and it will run.

                • FizzyOrange@programming.dev
                  3·
                  12 小时前

                  it has modules for everything

                  Not everything. PyYAML, Pydantic and Typer are things I commonly want in scripts that aren’t in the standard library.

                  Simply do pip install anything. But best practice is to use a python virtual environment and install packages into that one.

                  It’s more than “best practice”. It’s mandatory on many recent Linux distros. And yeah setting up a venv and installing dependencies is not something you want to have to do for each script you run.

                  Its one of the slowest to write code in.

                  It depends what your goal is. If you want robust code that works reliably then I would say Rust has the edge still. Yes it will take longer to write but you’ll spend way less time debugging it and writing tests.

            • Ephera@lemmy.mlEnglish
              11·
              2 天前

              Oh yeah, I’m not saying this is what makes Rust special. Rust’s strength in comparison to Bash is that it’s a lot more competent at control flow and structuring programs. But yeah, virtually any programming language is at least better at that than Bash, so whichever one you’re most comfortable with, is probably the best choice. This trick just allows you to make use of Bash’s biggest strengths, which is easily running commands and piping between commands, while also having the competent control flow and structuring of your programming language of choice.

    • 1984@lemmy.today
      26·
      2 天前

      Kind of agree with you here… I wouldnt reach for rust. Python gives much faster results than rust.

  • BB_C@programming.dev
    414·
    1 天前

    /me putting my Rust (post-v1.0 era) historian hat on.

    The list of (language-level) reasons why people liked Rust was already largely covered by the bullet points in the real original Rust website homepage, before some “community” people decided to nuke that website because they didn’t like the person who wrote these points (or rather, what that person was “becoming”). They tasked some faultless volunteers who didn’t even know much Rust to develop a new website, and then rushed it out. It was ugly. It lacked supposedly important components like internationalization, which the original site did. But what was important to those “community people” (not to be confused with the larger body of people who develop Rust and/or with Rust) is that the very much technically relevant bullet points were gone. And it was then, and only then, that useless meaningless “empowerment” speak came into the picture.

    • subversive_dev@lemmy.mlEnglish
      21·
      9 小时前

      I’m a rust stan but honestly, I think your comment is correct. I remember the website change at the time, but what I didn’t notice then was the catastrophic loss of information density.

      The old bullet points really are the the money, they explained to anyone who knows programming languages what makes rust actually special. By contrast the new website suffers severely from buzzword-itis and design over content.

  • Billegh@lemmy.world
    610·
    2 天前

    It kinda feels like cheating for rust to publish a list of reasons why rust people like rust…

    I like rust too, but this feels more like advertising than useful commentary on the language and its tools.

    • Shanmugha@lemmy.world
      12·
      8 小时前

      Well, it really is. Went for Rust from Python and gained faster execution - wooow, no waaaay. No other language can do that (sarcasm, and to add more to it: did they ever try to actually optimise code first?)

      • fruitcantfly@programming.dev
        2·
        1 小时前

        The way to really optimize Python code, is by reducing the amount of Python code in your program, since Python itself is dog slow. Instead, you want to offload as much of the work as possible to modules written in compiled languages. So completely switching to Rust, or another compiled language, is simply taking that strategy to its logical conclusion

    • communism@lemmy.ml
      15·
      1 天前

      Why not? Of course people who make something (in this case, a programming language) are going to promote what they make and share praise they’ve received. It’s a pretty normal thing to do. They’re not trying to obscure the fact that they’re the Rust Foundation—it’s on the Rust blog.

      • Shanmugha@lemmy.world
        22·
        8 小时前

        Honestly, I could not make myself read till that critique part. As much as I would like to hear what Rust actually is good for, that article is yet another cheap advertisement