Personally, I find rapid prototyping much faster in Rust than Python, and I don't think I'm a "top expert".

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"

> We already have less powerful languages, like C.

I don't think this is a good comparison. C is a systems language and operates at a completely different level of abstraction than Python. Also, it's very powerful. It might not have a lot of language features per se, when compared to something like Python, but production-grade C code is just as complex (probably more so) than production-grade Python code.

I generally agree with the rest of your comment. But saying that C is the "less powerful" language rubbed me wrong :)

I agree that C lets you more precisely control what a CPU does. By that definition of "powerful", I think the assembly language of that processor is the most powerful language.

But the cost with which you must put up is also large (the intricacies of the CPU, memory allocation, types and such breed complexity). Some tasks are not worth that cost.

For instance, you want to print "hi" to the console. A shell script saying "echo hi" is perfectly adequate. No need to declare a main function or import anything.

By defining "power" as this "efficiency" or "sparseness" or "brevity" measure, strictly looking at this example, C is less powerful than bash.

I tried to take literal code length per Rosetta code task as a very rough measure of "terseness" (the x-axis), and I'm curious what you think.

https://danuker.go.ro/programming-languages.html

In any case, my definition of "power" is close to the opposite of what it means in the OP article.

There is no great difference between any of them. They're all essentially procedural languages with various bells and whistles bolted on.

The list comprehension is about the only high level feature in python in my opinion and it's still quite underwhelming.

Scala 3 feels like python++... sticking with the quiet syntax it feels very pythonic.

Indeed, including the ecosystem break between Scala 2 and 3. /s

Python++ sounds like it would be absolutely terrible.

Python with:

-types -modules -better encapsulation -compiled speed out of the box -more concise syntax for writing classes -real support for OO and functional programming

I think the kind of powerful the article talks about would pretty explicitly apply to C, as it is turing complete and lets you manage lots of stuff explicitly

This comment completely misses the point. C is not less complex than Python, Ruby, or even Haskell. In fact, it's much more complex. Complexity is here is not about 'how easy is it to write something'. Complexity is rather 'can I express problems that are difficult to reason about'. It is impossible to express intractible problems in HTML. There are problems that simply cannot even be expressed in HTML. Contrast this to any of the turing complete languages, in which it is possible to express problems difficult to reason about. Python, ruby, julia, javascript, haskell, etc fall into this category. Now contrast this to the turing complete languages riddled with undefined behavior like C and C++.

Your complextiy is inverted.

Problems difficult to reason about are big problems, so a big html document is such a problem.

Nope. An html document is statically analyzable by simple tools. Html parsing is very easy. Html rendering difficult to code correctly but very straightforward. It is very easy to generate in bounded time the result of an html render.

It is impossible to do that with C, haskell, rust, etc.

An html engine is such a simple tool microsoft gave up making its own. C compilers available for a wide range of platforms is said to be due to simplicity of C.

I don’t think this notion of complexity is meaningful/well accepted. Languages have expressivity as a more-or-less accepted concept (in which C is very inexpressive, Haskell, Ruby etc. are very expressive), and language complexity as perhaps another, where the concepts of the language are taken into account. For example something like Idris with dependent types would be a quite complex language, while C may indeed be relatively simple. This is usually the inverse of expressivity.

You seem to talk about the complexity of a program when written in a specific language. Here, a more expressive language would fair better, at usually the cost of a more complex language as mentioned above. But as we all know, essential complexity (of a problem) is non-reducible.