Anyone else get completely side tracked as soon as you saw the shebang (self-executing rust scripts)? MY mind kind of exploded in a similar fashion to when I discovered Go could do the same. It's definitely a nifty feature and can see it getting a lot of basic usage. I've seen a couple projects that do similar with rust to control build and testing pipelines, this could be a good alternative in those cases.
That said, I mostly just use Deno + TS for my shell script needs beyond simple bash. Mostly in that JS is hands down the language I know the best (28 years), close would be C# (24 years) for me. I was also an early adopter of Node. I also think that dealing with shared/centralized packages is an easier option for Deno than Node, Python or other languages/environments. The cargo front-matter here seems to work similarly.
As the person designing and implementing cargo script integration into cargo (there have been many third-party implementations in the past), I was both glad to see it in the wild and surprised and glad to see it called out like this!
Yes, there has been a long road to this in defining what this should look like, how it should interact with the language, what is the right scope for the initial release, and so on.
At this point, I'm doing what I hope is the wrap up work, including updating the style guide and the Rust reference. The big remaining work is in details I'm working out still for rustfmt and rust-analyzer. Other than those, I need to get to a bug fix in rustc and improve error reporting in Cargo.
For myself, I use cargo script nearly daily as I write a script whenever I'm creating a reproduction case for an Issue I'm interacting with.
Just to add, I literally meant sidetracked... started searching for the "-Zscript" feature in cargo, apparently in progress since 2023 with an open issue that's close to complete. Along with looking back into ZomboDB's repo, where I saw Rust being used for the build pipeline stuff, not that I completely understand it in context.
Not to mention how useful the cargo front-matter handling is in terms of portability for these kinds of scripts... one file to share, and no extra "install/init" step to bring in dependencies (such as with say Python or Node.js).
> That said, I mostly just use Deno + TS for my shell script needs beyond simple bash. Mostly in that JS is hands down the language I know the best (28 years), close would be C# (24 years) for me
I sympathise, but in 2025 that is a terrible reason to choose a system.
A lot has changed, mostly for the better, much better, in the last twenty years
I know it, understand it, it's easy for me to use, modern, can run without complex initialization/setup, a massive amount of module support including plugging into almost every kind of backend under the sun, and portable as a single file/script.
Those aren't good reasons to choose something?
I mean, sure, I COULD use Python or Go, or actually build small programs in a number of other languages instead of scripts altogether... But Deno+TS is actually a pretty good and capable shell scripting option. I'm not bashing on Python or Go here.. but given that I KNOW one of these options better than the others, it definitely is more than enough to tip the scales.
Unless you're making the assumption that my starting with JS so long ago means I don't understand modern/current conventions?
Your choices are modern. Not sure what the person arguing exactly about, but new C# is as modern as it can be, and .ts is pretty damn modern as well. Same for deno in 2025.
In fact, in 2025 I tested same setup for better scripts: deno+ts.
I know .ts pretty ok, but the pattern didn't stick to me with deno, especially when Python received uv.
But both options are fine. Saying that in 2025 you should so something different and more modern and not elaborating makes 0 of an argument.
PS C#/.NET just introduced "run", won't be much sense to use deno+ts once it gets up to speed as native integration.
Yeah, I saw the dotnet run option in the v10 notes... currently working on a project with preview 5. Need to update the latest, but the locked down environment means getting the helpdesk involved for everyone to update across the team, which is ironic as I do have admin privs on our app servers, just not my assigned laptop.
Lol, yeah, most of the times on the server we have more perms than IT assigns on our laptops. I am not in that environment anymore, but in banking was very much the case.
I want the dotnet run to work out, that means I could start using C# more. We have a mixed bag now Go(biggest chunk), C#, Python, JS/TS, and lots of .sh. Some powershell(in search for better shell scripting). Some very little Rust.
Do you do any GUI apps with C#? If yes what you go for? Did MAUI took off already, or it's not being well adopted? The promise was nice. I still miss Delphi and drag and drog components. Well there is Qt now, but that's a different story.
As mentioned, mostly Deno+TS if I need more than can easily be done in (git/msys)bash, not fond of Powershell, though I've used it where necessary/available.
I don't do a lot of desktop gui apps, I've thought about Tauri wrapped web-based apps, mostly in that the tooling seems pretty nice, there's also Leptos and a few other options that can work with/similarly. If going with C# I'm more inclined to use Uno, Avalonia, Etp Fprms or maybe embedding Blazor. MAUI is kind of DoA for me, only because of a lack of Linux target. I know it's only 5-6% of desktop market, but IMO, it's still worth having given a developer audience.
I know web-based desktop apps are a bit higher overhead than native, but they can operate relatively well with good skinning (CSS) and accessibility features that tend to work better, or at least more consistently than a lot of cross-platform UI tooling. I find MUI + React to be a pretty good mix for UI, and have played with async state mgt similar to Redux in managed (backend) code with it a bit, and it's worked pretty smoothly in my experiments. You have to think a bit more about state vs. events, but it's been a rock solid experience.
I saw an example about a year ago and can't find a specific article... but something along the lines of...
#!/usr/bin/env -S go run
I'm not sure if/when go ignores a shebang on the first line... otherwise, there are a bunch of articles I've seen that have a slightly differing format to do the same.. but google results feel off/old.
searched for: go shebang scripts
shebang is the term for a text/script file beginning with "#!" with the executable and parameters to run.
I know this... my point was in that Rust didn't have this feature 5-8 years ago when I first started reading/learning about it. A lot of languages haven't had an active scripting-capable usage that can do this until fairly recently. C# even has it in .Net 10, though I'm not sure about dependency handling in that case.
I like and was commenting that rust has the cargo frontmatter instead of a separate cargo file, same for deno in that it can reference the repo/url directly instead of requiring a separate modules file/folder (like node package.json/node_modules) or even with python. You can reference the modules you need directly.
I remember when I saw this in F# interactive (C# didn't have a REPL at all at the time) when I first started using that language around 10 years ago. I thought it was immediately useful as a easy to write, but static typed Python replacement without all of Pythons dependency headaches for quick scripts. Because back then as compared to say C#/Java which required a lot of class files, boilerplate, etc F# read more like a scripting language which made it more suited to this. When they added the ability to pull in packages/dependencies inside the script directly that was great as well. e.g. Pull in a type provider, parse some JSON, make some API calls, create quick CSV's, whatever. Useful for quick scripts, data mangling or quick prototypes - you could just cut and paste the single script with a shebang, message it to someone on your team and it would run dependencies and all without the equivalent venv issues with a simple pasting into a text file. Install .NET SDK and that's it - it would run. In the team I was in at the time it was a quick productivity boost - seeing features implemented in quick scripts and seeing the data workable in a REPL session which could then could be promoted to an actual project was a great workflow.
I think those features have since spread to C# interactive (probably inspired by the F# incubator IMO), as that language has done things to simplify its syntax to make single file apps easier. From your comment Rust seems to be taking a similar approach.
A bunch of third-party Python package manager clients, most famously uv, support this now. They all use the same front-matter format (PEP 723). Unfortunately, pip (the first-party package manager client that's usually distributed with Python) doesn't support it yet: https://github.com/pypa/pip/issues/12891
Interesting... I'm not really involved in much/any Python development, but cool to know there are options out there. I've mostly just run existing projects as needed.
To be precise, Rust files have supported shebangs since well before 1.0, there just wasn't really any built-in tool to point the shebang at. The new stuff in the relevant RFC is actually about Cargo, not Rust; the "Cargo frontmatter" syntax doesn't need to be added to Rust, it can just be stripped by Cargo before it hands off the file to rustc.
Most languages currently do not support this in a way that lets you specify dependencies from a package manager. And some don't support it at all; most C and C++ toolchains, for example, don't have a way to compile and run a single source file in a single command.
Exactly, that alone makes it far more useful/portable in practice than a lot of other languages for this type of thing. A python file can have a shebang, but it'll need a bunch of other files around it for module references, etc. Not to mention initialization/setup, etc.
The fact that dependencies are referenced in the file and automatically handled at runtime (first or repeated) is a really nice feature to have... it's expressly why I started using Deno over other options for this.
I would argue that third-party tools don't really cut it, because a lot of the value is being able to include a script inline in, e.g., an email or chat message, and that's undermined if the recipient has to download and install a separate tool. (uv gets half credit because adoption is rapidly rising and it has a shot at becoming a de facto standard, but I'll only award full credit to Python when pip supports this.) They're good for exploring the design space, though.
That said, I mostly just use Deno + TS for my shell script needs beyond simple bash. Mostly in that JS is hands down the language I know the best (28 years), close would be C# (24 years) for me. I was also an early adopter of Node. I also think that dealing with shared/centralized packages is an easier option for Deno than Node, Python or other languages/environments. The cargo front-matter here seems to work similarly.