I use Rust a lot for my generic scripting around the office. Small tasks like copy a few thousands files, selectively re-naming them based on a group of regexes.

The Regex crate (which I think is being merged with std) uses the same syntax as Python's regexes.

The Path/PathBuf type in std makes manipulating paths easy (and type safe). No more slicing notation/regexes to find where extensions start. Also it handles unix/windows / vs \ for you.

Python DuckTyping slightly drives me insane. What interfaces are/aren't typed feels like Russian roulete. Nothing like the 4000th processed file crashing your script

The real win is compatibility. If you avoid unsafe you don't need to think to port to Linux/MacOS/Windows.

Lastly it's a binary. So to share with a coworker, just copy it. No module management.

> (which I think is being merged with std)

It's on that path, but it's unclear if and when a literal merge into std will happen. Right now, the design of 1.0.0 has been accepted, and once that lands and is released, it will move from "the nursery" to the regualr rust-lang org. From there it could go into std, or it may just stay there forever.

regex has some dependencies, though.

aho-corasick, memchr, thread_local, simd, utf8-ranges

That functionality would have to be in std.

Regex in std would sure be nice, though.

Can be in std without being exposed. libc does this IIRC; the stdlib depends on libc but doesn't expose it.

Right, so this would be one of the questions with moving it into the actual distribution. All of that would have to be replicated in-tree and stabilized separately...

> The Regex crate (which I think is being merged with std)

To add to what Steve said: there are currently no plans to export regex from std.

> I've also heard it's for systems programming, which makes me think of C and has kept me away from it.

One of its major goals is making systems programming more accessible. So you shouldn't dismiss it because "systems programming = C", it's trying to change that! :)

That's not to say it won't involve learning some systemsy concepts. But it won't be as scary as C.

You can't necessarily bang out scripts quickly. A type system tends to make this task verbose. However, larger applications benefit a lot from that type system.

We've often had feedback from Python/JS shops using Rust that learning Rust had the side effect of teaching them systems programming. I think that's pretty awesome.

I guess I'm contrasting Python with my Java experience so far as banging out prototypes quickly.

In Java, I don't think the type system gets in the way so much as its classpath. It's been a long time since I've done Java, but you'd have to get your jars in order and write an ant or maven script to do the compile/run steps (or at least a bash script).

I like that with Python I can just do pip install whatever and begin using the module immediately in my main method. In Java, It's not standard practice to copy jars into the system classpath IIRC, so you'd have to copy them around every time you want to do something new.

I need to investigate Rust's command line interface. Obviously, the more it can get close to

python main.py

vs.

javac -cp foo/Bar.jar:baz/Quux.jar Main.java; java --classpath foo/Bar.jar:baz/Quux.jar Main

the better it will be for this use case I mention.

Thanks to both of you for responding!

Calling `cargo run` has made it easier for me to treat it as a scripting language since it combines the build and run steps in a single command. Good luck with it!

I believe Rust's package manager, Cargo, is quite similar to pip in functionality. I haven't used it myself, so I could be wrong.

In some ways. It's also got the features of https://github.com/pypa/pipfile

It is way better than pip on the sense it works everytime. pip is not painless. It is close but miss by little. Got to hate it because of numpy.

> We've often had feedback from Python/JS shops using Rust that learning Rust had the side effect of teaching them systems programming. I think that's pretty awesome.

I'm a self-taught developer who only practiced memory-safe languages before and I never dared trying C because of its reputation of being too difficult. Rust taught me a lot of things about system programming I never though I will learn one day.

A big thank you to the whole Rust team for that !

There's nothing that makes typed languages inherently more verbose; a Haskell script will tend to be substantially shorter than the equivalent Python.

Rust gives you much more control over how your program runs, but this necessarily means paying a price in expressiveness.

I didn't say typed languages are inherently more verbose. I said that a type system tends to make things more verbose (in some cases), e.g. having to bang out types in function signatures, etc. When writing small scripts you usually just write down what you want to happen, and it works. There's some extra mental/typing overhead in a typed language in many cases. For larger programs, this overhead isn't important since you get many other benefits, but for small scripts sometimes it can be problematic.

It's not a hard-and-fast rule. It's something that I've experienced when trying to write small scripts in all kinds of typed languages. I keep going back to Python.

For larger scripty things I've found typed languages to work just as well.

> but this necessarily means paying a price in expressiveness.

I don't think this is true. You can have higher level abstractions in Rust too.

Not type systems per se.

But lack of garbage collection and the need for lifetime annotations for references and memory management with Box, Rc, Cell, Mutex, etc, combined with the type definitions makes Rust a lot more verbose than any dynamic language or even statically typed languages with GC like Scala / Go.

That can't be avoided, but you have to be prepared. Rust code can be short and elegant, but it can also be tediously verbose.

>a Haskell script will tend to be substantially shorter than the equivalent Python.

someone offered a counter-example where a JSON parser had more lines of type definitions in Haskell than total lines of code in Python

I wouldn't be surprised if the Python solution were shorter than Haskell version that doesn't use lens.

If you link me the example maybe I can provide a Haskell version using lens.

I've been using rust to as a more performance-oriented tool alongside python. It _is_ a different tool: there are certain tasks (for an irl example: taking a Unicode data file, parsing its contents, transforming it in some way, and writing it to disk) where python works very well and Rust feels like overkill.

That said, Rust is very elegant for the work it is doing. Rust iterators and iterator adapters are a powerful and clean way of manipulating collections, and the `match` syntax is an elegant way of handling errors and Option types.

Rust isn't a scripting language in terms of its strengths, but it isn't far away in terms of how pleasant it is to read and write. I would definitely suggest taking a look at it next time you run into performance constraints in python: it's easy to create python-native modules & interfaces with tools like rust-cpython (https://github.com/dgrunwald/rust-cpython).

Sounds like http://lucumr.pocoo.org/2015/5/27/rust-for-pythonistas/ is a thing you'll want to read. It's from right when 1.0 was released, so some things may have improved in the meantime, but given our backwards compatibility guarantees, nothing should be flat-out wrong.

And some more recent writing from him as well: https://blog.sentry.io/2016/10/19/fixing-python-performance-...

I started out as an assembly programmer and before Rust I was using C/C++ for systems and embedded, Typescript for browser frontend, and Python for everything else. I still use Typescript for the browser and Python for Jupyter (prototyping and ML) but Rust has largely replaced C/C++/Python for most of my work. Elegance and simplicity mean different things to different people but I'll give it a shot.

Unfortunately, Rust doesn't have an interpreter so it's not as great as a general scripting language but realistically, there's only a few extra lines you have to learn (extern crate and fn main() {...} mostly) along with the compilation step. Imports work more or less the same in both languages but I find Cargo to be far superior to pip as a package manager. You won't run into dependency hell very often and deploying a Rust project is very easy.

As far as writing Rust, it has static typing so if you want to carry over your programming style from Python it will take some getting used to. The extra type information in definitions can be annoying at first (especially with generics and iterators) but overall provide an intangible productivity boost with type inference filling in the gap. Rust objects are basically pure data structures without inheritance so you have to get used to thinking in traits. That said, with conversion traits like Into/From and generics with trait bounds, I can write code as if it were a dynamic language with duck typing (once I've defined my types) with just a little extra boiler plate to tell the compiler the similarities between this duck and that duck. For example, you can write a function fn foo<T: ExampleTrait>(T bar) and call it with any argument that implements ExampleTrait or Into<T: ExampleTrait> for quasi duck typing.

Finally, I feel I'm far more productive in Rust than in Python, assuming I don't need any functionality in the Python stdlib not yet implemented as a crate. On average, Rust crates are slightly lower level than Python's libraries but I find that using them is no less ergonomic, albeit more verbose. Most of the time, if I haven't made a logic error, any Rust code I compile just works and i don't spend countless hours debugging silly errors like variable name typos or magic object changes. More importantly, in Rust, you can encode a significant fraction of your logic into the type system which will be enforced by the compiler. For example, in my STM32 motor controller, I encode physical units as types so I can't accidentally feed the motor a 1000 volts when I mean 1000 millivolts because the Into<ControlSignal> trait calculates the signal based on the input type.

I would definitely give Rust a shot but don't expect to be as proficient in Rust as quickly as Python. The community is younger (but no less helpful) and the ecosystem is still catching up. Most importantly, don't let Rust's status as a systems programming language deter you. It is a low level language but is a modern language that was designed from the ground up by very smart people who incorporated the lessons of the past. Rust's zero cost abstractions, compiler plugins, and tooling have started to bridge the ergonomics gap between high level scripting languages and system development.

Thanks I look forward to checking it out.