> This is factually impossible.

How do you outright deny something as subjective as my personal experience? Besides, I'm not the only one in this discussion that made the same opinion.

> For anything larger than (very) small programs, Rust requires an upfront design stage, due to ownership, that it's not required when developing in GC'ed languages.

While GC'ed languages allow you to skip a proper initial design stage, it's a stretch to claim that it's not required at all. In my experience using Python, while the initial stages are smooth, such design oversights come back and bite at a later stage - leading to a lot of debugging and refactoring. This is one aspect where Rust saves you time.

> This is not even considering more local complexities, like data structures with cyclical references.

I'm not going to dwell on cyclical references, since there's another thread that addresses it. They point out a way to make it as easy in Rust as it is in GC'ed languages.

Meanwhile, the upfront architecture and data structure design isn't as complicated as you project it. Rust is mostly transparent about those - even compared Python. How well do you understand how Python manages Lists, dictionaries or even objects in general? I often find myself thinking about it a lot when programming in Python. While you need to think upfront about these in Rust, there's actually less cognitive overhead as to what is happening behind the scenes.

This is possible if you are really slow in python

Or maybe they mean "fast to 1.0" rather than "fast to 0.1"?

They didn't specify.

That is also not shared by everyone. If you have written enough Rust to have internalized designing for the borrow checker, you don't have to spend much time in a design phase.

The only time I find I have to "fight the compiler" is when I write concurrent code, and you can sidestep a lot of issues by starting with immutable data and message passing through channels as a primitive. It's a style you have to get used to, but once you build up a mental library of patterns you can reasonably be as fast in Rust as you are in Python.

Of course it's possible. You just need to write Python very slowly :)

Everyone has their breaking point. I start to write Python very slowly around after 10k lines or so. Can't remember where I put stuff...

> For anything larger than (very) small programs, Rust requires an upfront design stage, due to ownership, that it's not required when developing in GC'ed languages.

Every language requires this (if you want robust code), most just let you skip it upfront ... but you pay dearly for doing so later.

I have to second the OP: ownership isn’t that hard. I just get used to structuring a program in certain ways. Having written a lot of C++ helps because the things Rust won’t let you do are often unsafe or a source of leaks and bugs in C++.

Having an editor with rust-analyzer running is massively helpful too since ownership issues get highlighted very quickly. I can’t imagine dealing with any language larger than C without a smart editor. It can be done but why?

I still find async annoying though.

My biggest source of friction with Rust (other than async) is figuring out how to write code that is both very high performance and modular. I end up using a lot of generics and it gets verbose.

Couldn't one use Arc and similar boxed types to avoid thinking about memory until later?

Why not just something like nim and that point, and straight up ditch 90% of the complexity?

I was answering to this other user:

> This is factually impossible.

> For anything larger than (very) small programs, Rust requires an upfront design stage, due to ownership, that it's not required when developing in GC'ed languages.

It seems that is not factually impossible.

Now, answering your question: It could be useful to use boxed types and later optimize it, so you get the benefits of rust (memory safety, zero cost abstractions) later, without getting the problems upfront when prototyping.

> This is factually impossible.

No it isn’t Both languages comprise much more than their memory management handling. Even if your premise is true, the conclusion does not follow.

> This is factually impossible.

Factually it's not. It may be true that in a very very idealized thought-experiment, when someone has a perfect knowledge, never makes mistakes, doesn't have preferences, can type arbitrary fast etc, python needs fewer keystrokes, fewer keywords or such, thus is faster. Who knows. But in reality none of the assumptions above hold, also literally everything plays a much bigger role in development speed anyway.

I mean, it’s easily the same for me. I am way more productive in Rust because I know it very well, and with Python I’m debugging all kind of gotchas.

> For anything larger than (very) small programs, Rust requires an upfront design stage, due to ownership, that it's not required when developing in GC'ed languages.

It's nearly the opposite. For larger programs in Python, you need an upfront design stage because the lack of static typing will allow you to organically accrete classes whose job overlap but interfaces differ.

Meanwhile, Rust will smack you over the head until your interfaces (traits) are well-organized, before the program grows enough for this to become a problem (or until you give up and start over).

How do I know? I'm stuck with some larger Python programs that became a mess of similar-but-not-interchangeable classes. RiiR, if I ever have the time.

RiiR: Rewrite it in Rust

> For larger programs in Python, you need an upfront design stage because the lack of static typing will allow you to organically accrete classes whose job overlap but interfaces differ.

You can also install pre-commit and mypy, and have static typing.

That's the entire point we're making. Rust's type system forces you to deal with the problem early on and saves time towards the end. It's not like that's impossible with Python with addons like mypy. But Rust's type system goes beyond just data types - lifetimes are also a part of the type system. I don't know how you can tack that on to Python.

> Rust's type system forces you to deal with the problem early on and saves time towards the end. It's not like that's impossible with Python with addons like mypy.

Definitely not - mypy's pretty good these days, and lots of people use it.

> But Rust's type system goes beyond just data types - lifetimes are also a part of the type system. I don't know how you can tack that on to Python.

Well, Python's objects are generally garbage collected rather than explicitly destroyed, so I don't think it'd make sense to have lifetimes? They don't seem a correctness thing in the same way that types do.

Lifetimes and borrowing are very much a correctness thing and aren't just for tracking when memory is freed. While you won't have use-after-free issues in a GCed language, you will still have all the other problems of concurrent modification (data races) that they prevent. This is true even in single-threaded code, with problems like iterator invalidation.

Lifetime analysis matters a lot for way more than just garbage collection.

File handles, iterators, mutex guards, database transaction handles, session types, scoped threads, anything where ordering or mutual exclusivity matters.

I don't know about all of those, but Python's context managers and built in constructs handle most of those, I think?

Only in the most basic cases. If your handle has to be passed into another function or outlive the current scope of your function, the guardrails end.

Mutability is a big one for correctness. In Python, any function you pass any (non-primitive) object to might be mutated right out from under you and you have no idea it's happening. In Rust, you have to explicitly provide mutable references, or you need to hand over ownership, in which case you don't care if the callee mutates its argument, because you no longer have access to it.

I think this is a very valuable comment, and the replies don't do it justice.

I strongly agree from my own and my peers experience with the sentiment that latency from zero to running code is just higher in Rust than Python or Go. Obviously there are smart people around and they can compensate a lot with experience.

You know what slows me down in Python? The fact that you need to actually go down a code path to make sure you’ve spelled everything right.

But nothing that Rust does slows me down because I’m used to it.

I disagree. I have similar observation. With modern editors and Language Server that are giving immediate feedback writing strongly typed languages doesn't differ than writing python.

Honestly I found myself coding very much the same way in Rust as I did in Python and Go, which were my go-to hobby languages before. But instead of "this lock guards these fields" comments, the type system handles it. Ownership as a concept is something you need to follow in any language, otherwise you get problems like iterator invalidation, so it really shouldn't require an up-front architectural planning phase. Even for cyclic graphs, the biggest choice is whether you allow yourself to use a bit of unsafe for ergonomics or not.

Having a robust type system actually makes refactors a lot easier, so I have less up-front planning with Rust. My personal projects tend to creep up in scope over time, especially since I'm almost always doing something new in a domain I've not worked in. Whenever I've decided to change or redo a core design decision in Python or Go, it has always been a massive pain and usually "ends" with me finding edge cases in runtime crashes days or weeks later. When I've changed my mind in Rust it has, generally, ended once I get it building, and a few times I've had simple crashes from not dropping RefCell Refs.

I would flip this around.

If you are only writing small programs where perf doesn't matter, crashing doesn't matter, design doesn't matter - Python will be faster than Rust, because the only thing that matters is how you can write the code from 0 to "done". You can jump right in, the design stage is superfluous & unnecessary. There is nothing to optimize, the default is good enough.

If you are doing slightly more than that, Python and Rust become about even, and the more you need those things, the better Rust becomes.