Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Credits
As someone who's relatively new to rust, i feel that the slogan is pretty accurate, even when programming in other languages, i see that I'm way less prone to anti patterns and and write a better api for modules while barely thinking about it.
Mostly because i copy what design patterns work and are prevalent in rust's libraries and api.
I like that I have to think in Rust before compiling, not after.
A nice patena on aged metal !
Cool parasitic fungus too!
"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.
Unfortunately, proc-macros need to be in a separate crate. It'd be great if we don't have to do that.
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:
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.
...and not just for performance-heavy stuff or embedded development, but for shell scripts...
WHAT
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.
As someone who uses a lot of shell scripts and learning Rust, do tell more.
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.
You can do this in all programming languages that exist...
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.
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.
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.
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.
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.
Kind of agree with you here.. I wouldnt reach for rust. Python gives much faster results than rust.
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.
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.
Did you read the post? It ends with several critiques of Rust.
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
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?)
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
Now that should be weighted against the amount of work the rewrite is, among other factors. But anyway the article does not give any specifics
That's the case of for any optimization work, really
Hence my question above