4 ms·

> At this point, I'm about as fast in Rust as I am in Python. This is factually impossible. For anything larger than (very) small programs, Rust requires an u

> At this point, I'm about as fast in Rust as I am in Python. 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. This is not even considering more local complexities, like data structures with cyclical references.

goku12 3y ago
> 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.
- Ylmaz 3y ago
  This is possible if you are really slow in python
  - ParetoOptimal 3y ago
    Or maybe they mean "fast to 1.0" rather than "fast to 0.1"? They didn't specify.
raincole 3y ago
Of course it's possible. You just need to write Python very slowly :)
- actionfromafar 3y ago
  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...
steinuil 3y ago
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.
pg_1234 3y ago
> 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.
- deleted 3y ago
  [deleted]
api 3y ago
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.
mejutoco 3y ago
Couldn't one use Arc and similar boxed types to avoid thinking about memory until later?
- TylerE 3y ago
  Why not just something like nim and that point, and straight up ditch 90% of the complexity?
  - mejutoco 3y ago
    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.
avgcorrection 3y ago
> 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.
bmacho 3y ago
> 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.
Ar-Curunir 3y ago
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.
persnickety 3y ago
> 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.
- chrisweekly 3y ago
  RiiR: Rewrite it in Rust
- robertlagrant 3y ago
  > 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.
  - goku12 3y ago
    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.
    - robertlagrant 3y ago
      > 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.
linza 3y ago
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.
- deleted 3y ago
  [deleted]
thecodedmessage 3y ago
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.
sp0ck 3y ago
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.
julianeon 3y ago
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.
awused 3y ago
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.

goku12 3y ago

> 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.

Ylmaz 3y ago
This is possible if you are really slow in python
- ParetoOptimal 3y ago
  Or maybe they mean "fast to 1.0" rather than "fast to 0.1"? They didn't specify.

raincole 3y ago

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

actionfromafar 3y ago
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...

steinuil 3y ago

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.

pg_1234 3y ago

> 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.

deleted 3y ago
[deleted]

api 3y ago

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.

mejutoco 3y ago

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

TylerE 3y ago
Why not just something like nim and that point, and straight up ditch 90% of the complexity?
- mejutoco 3y ago
  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.

avgcorrection 3y ago

> 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.

bmacho 3y ago

> 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.

Ar-Curunir 3y ago

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.

persnickety 3y ago

> 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.

chrisweekly 3y ago
RiiR: Rewrite it in Rust
robertlagrant 3y ago
> 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.
- goku12 3y ago
  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.
  - robertlagrant 3y ago
    > 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.

linza 3y ago

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.

deleted 3y ago
[deleted]

thecodedmessage 3y ago

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.

sp0ck 3y ago

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.

julianeon 3y ago

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.

awused 3y ago

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.