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.