Can you write a function in a REPL and run it instantly? Can you easily inspect intermediate results?

In this regard I love Haskell's REPL mode, it's really productive for prototyping. It has a worse discoverability / autocompletion story than Python REPL though.

The only time I've ever needed a REPL is if I'm working with a badly architected codebase such that I don't know the shapes of my inputs. It's otherwise pretty easy to reason about well-architected code without needing to run it.

A lot of Lisp development is (or can be) REPL-based, Clojure(script) especially, but that's almost a whole paradigm in and of itself.

Having spent a lot of time writing both Clojure and Rust professionally, I think a lot of the benefit you get from a REPL is making up for the lack of a good type system and good IDE support. I also find that the support Rust has for unit tests partially makes up for the lack of a REPL.

Clojure has a bunch of other benefits over Rust when it comes to quick prototyping though.

In Haskell, you always know the shape of the input, so this completely misses the point of what the commenter above is trying to say.

For me the most interesting and non-obvious property of the code is how the whole thing interacts in the long run, but you can't possibly figure that out with REPL as preparation of inputs would be immense.

I heartily disagree with this -- anything I've tried to prototype in Rust has resulted in much frustration over lifetimes, types, etc.

I suspect it has a lot to do with your familiarity and level of experience with Rust. Probably also how much you’ve written code in languages with similar features/idioms.

I also find Rust to be quicker for prototyping than Python. However, I find Java quicker than Rust.

I loathe to say you must be doing something wrong. I mean objectively it really should not be the case! There is literally a ton more you have to write and do for the same thing in Rust. You get runtime safety and performance as a benefit, but those are not benefits in rapid prototyping.

Sometimes, not making mistakes can help your velocity more than it being quick to type out. It depends I think on what you're doing.

I'll give you that. And if someone is really in the 'zen' with a language, I can see them being quick on the draw. And it depends a lot on the project and deps. as well.

When I've prototyped in Python I mostly find myself using tuples, dictionaries, and lists. Generally the dicts and lists contain homogenous types but occasionally heterogenous types but they're really "variants" (variations on a theme). Writing the same types of programs in Rust usually proved straightforward by (ab)using the same basic types and operations on them. For handling the occasional heterogenous collection case, an enum of related variants sufficed and it wasn't a much slower effort than prototyping in Python would have been.

I would expect someone with more Rust experience than me (which is not much) to be at least as fast as I am with Python in Rust, especially if they know the tooling better. At least for these kinds of tasks.

Python is much easier to follow in 2023 with its optional typing support and fantastic libraries like Pydantic that make it easy to use. We are deeply missing a statically typed scripting language.

The optional typing in Python is pretty mediocre, especially in comparison to something like Typescript that just does everything so much better. The types are pretty limited and not very ergonomic (especially when using generics or functions), and third party support is hit-and-miss. The worst thing, I think, is that the Python typing community are trying to solve lots of the problems with plugins rather than by improving the capabilities of the type system. This might produce better results in the short run, but in the long run it makes things more complicated, as for a given project I need to understand (a) how Python works, (b) how Python types work, and now (c) how each of the plugins installed in this project work and how they interact.

I really want to like typed Python, but it's a pale shadow of what it could be, and what it really needs to be if people want to use it to describe very dynamic Python programs.

> There is literally a ton more you have to write and do for the same thing in Rust.

This is not true. Rust and python are about equivalent. Python is difficult to understand because the vast majority of library documentation is simply lists of examples, without any unifying theory. Languages like Rust and Haskell offer much more comprehensive documentation with obvious ways to fit things together based on a well-understood and rigidly specified compositional specification (types).

With rust you have to specify type, usually a container/reference type, and annotate lifetimes of everything you pass around. You literally do none of that in Python. You don't even declare variables. They are totally on the opposite ends of 'strictness'.

For rapid prototyping I (who you originally replied to) completely avoid lifetimes. If you think you have to "annotate lifetimes of everything you pass around", you should probably revisit Rust. This is simply not true.

I find type annotations to be a major benefit while prototyping - I know exactly what everything is, and can quickly refactor anything. The ability to use serde to deserialize/serialize into Rust structs is another huge benefit. Chaining iterators, collections, etc removes a lot of the boilerplate that I find myself doing in python.

I've also been using Rust as my primary programming language for 5+ years now, so I am definitely "in the zone"