For any project where performance or correctness are significant concerns I'd much rather use Rust than Python. It provides a lot more tools to help you write correct code, and express invariants in a machine-checkable way. This means that they are maintained when the code changes, even when multiple contributors are involved. I'm must more confident in my ability to ship correct code in Rust and maintain that correctness over time.
Rust also doesn't have the performance ceiling (floor?) of Python, either for single threaded programs, or — especially — for those that benefit from concurrency or parallelism. Of course for some progames there's a clear hot loop that you could implement as a native extension in Python, but other workloads have relatively flat profiles where the performance bottlenecks are making allocations or similar.
As well as the actual language features, the commitment to backward compatibility from the Rust authors means that you don't get regular breakage simply from updating to a newer version of the language. I think Python 2 being 2.7 for such a long time gave people a false impression of how stable a foundation Python provides and the fact that point releases of 3.x often cause problems feels like it causes a lot of unnecessary makework for Pyton users and is rather offputting.
That doesn't mean I'd always choose Rust of course. You do require more upfront design to get something that works at all. Some projects also benefit greatly from not requiring a compile step and making use of the ubiquity of a Python interpreter. And I think I'd find it difficult to justify using Rust for a typical web backend that's mostly composing together various well-tested libraries to provide an API on top of a database.
It was a rough transition, to be sure. Python2 was released 20 years ago, and Python3 12 years ago. It is a pretty stable language.
The argument is that being on 2.7 for so long gave a false impression of the language being more stable than it is - developers just weren't using new versions.
So 2020 rolled around and the pypi libraries they were using were no longer supported even though RHEL would support python 2.7. So yeah, it was a really bad experience for everyone involved.
They manage this by allowing using a different epoch in a library than the application that uses it, and defaulting to the original epoch if you don't ask to use a new one.
The vast majority of rust 1.0 libraries should still work with modern rust programs, I vaguely recall that there was one minor backwards incompatible change as of a result of memory safety bug (an exception to the guarantee), but I can't remember what it was and I can't find it with google so it might actually be all rust 1.0 libraries still work.
The fix for https://bugs.python.org/issue40870 caused me some grief when upgrading from 3.8.3 to 3.8.4 (though to be fair, the ast module has different stability guarantees).
Any reason for why Rust over Ada/SPARK?
That said, Rust seems to have reasonably good performance compared to C/C++. Also the concept of lifetimes is interesting too.
Just because your program compiles in C++/Ada(no-spark)/C/Java/Rust doesn't mean it's correct. If it compiles in Rust, the compiler is telling you it's memory safe and thread safe.
Due to lifetimes it's easy to keep string slices as references into the original memory and if you do need to modify some strings, you can use CoW.
The way Rust deals with encoding also makes it much safer to use Rust. Since you need to be very explicit about which encoding you convert to what and if you want to allow lossy conversions.
I don't think there is much of an equivalent in ADA for this. ADA has other benefits, like the delta (fixed point) types which help a lot in embedded projects.
There's a bit of a progression with Rust, where at first you see the examples and you go "this language is so beautiful!" Then you try to write something nontrivial in Rust and you go "wow the compiler will NOT stop yelling at me, how does anyone write anything in this language?" Rust has a fairly austere learning curve in general, and it takes some getting used to.
That passes, though, and then you really do get to experience the elegance and power which sold you on Rust in the first place. There's a period where writing Rust feels substantially slower that writing in anything else, but that passes too.
It really is as good as it sounds, but it might take a while before you're accustomed enough to Rust's paradigm that it feels that way.
All those lifetime annotations are not sheer beauty or pretty, sure they are necessary but not nice to look at if you are comparing it to a higher level language.
You don't have to do it, but if you want to do it, being able to do so in a way that's verified and enforced by the toolchain beats doing so in a documentation comment.
Now every time I read a doc string saying that I need to "deepcopy" something in Python for some API usage pattern to work properly I cringe.
With a checker you're forced to think: do I really want to pass a copy/clone of this? Or do I want to let that function borrow it? Or borrow it mutably?
Assume you had some code that takes a file name and calls open on it. One day you decide you want to print that filename before you open it. Naive code will cause the name to “move” to print and unusable to the open in next line. Even though it is perfectly understood by all parties that there is no threading involved and print would finish before the next use of that string. Yes, I can create a borrow or clone, but having to think of it every single line of code even when there is only one thread of execution is really painful
Edit: I get print is a macro, but imagine a detailed logger for this case.
Here, if I have a `&T` and I try to call a function that has a `&mut T`, the compiler will tell me that's not gonna work - and then I can pick whether I want my function to take a `&mut T`, or if I want to make a clone and modify that, etc.
There's a learning curve, it's a set of habits to adopt, but once you embrace it it's really hard to go back to languages that don't have it! (See the rest of the comments for testimonials)
Bignum arithmetic is an example of the latter. You want to just work with numbers, and in Python you can, but in Rust you must clutter your code with lifetimes and borrows and clones.
Swift's plan to allow gradual, opt-in lifetime annotations seems really interesting, if it works.
let a = Integer::from(10);
let b = a + a; let b = &a + &a;
GC protects you against double-free and use-after-free, but memory leaks? Nope.
Foo* foo = new Foo();
...code that uses foo...
In a practical sense... is it your personal experience that memory leaks are equally prevalent in GC and non-GC languages? I've spent decades working in each (primarily C++ and Java, but also Pascal, C, C#, Smalltalk...) and my experience is that memory leaks were a _much_ bigger issue, in practice, in the non-GC languages.
It is my experience that when people work with GC languages, they treat the GC as a blackbox (which it is) and simply won't bother investigating: do they have memory leaks? Of course not, they are using a GC after all, all memory-related problems solved, right? Right... With code that relies on free(), I can use a debugger and check which free() calls are hit for which pointers. Even better, I may use an arena allocator where appropriate and don't bother with free() at all. With a GC I'm just looking at some vague heap graph. Am I leaking memory? Who knows... "Do those numbers look right to you?"
Memory management issues are usually symptoms of architectural issues. A GC won't fix your architecture, but it will make your memory management issues less visible.
It is my experience that most memory problems in C come from out-of-bounds writes (which includes a lot more than just array access), not from anything related to free(). A GC doesn't help here.
> In computer science, a memory leak is a type of resource leak that occurs when a computer program incorrectly manages memory allocations in a way that memory which is no longer needed is not released.
In most of your scenarios, e.g. "pushed to some queue", the object in question is still needed. Hence, this is not a leak. Presumably, the entry will eventually be removed from the queue, and GC will then reclaim the object.
At any rate, I think we're moving past the point of productive discussion. My experience in practice is that memory leaks are more common / harder to avoid in non-GC languages. Of course a true memory leak (per the definition above) is possible in a GC language, but I just don't see it much in practice. Perhaps your experience is different.
If I have a queue with elements and I won’t be accessing some of it in the next part of the program, is it a leak? Also, remember that certain GCd languages intern strings, is it a memory leak since it will not necessarily use it anymore?
To provide an example for a different case: programs written in Gallina have the weak normalization property, implying that they always terminate.
With a "proper" GC engine, anything that is no longer able to be referenced can be safely collected. Barring bugs in the GC, none of those can leak. But, you can unintentionally keep references to things for a lot longer (possibly unlimited longer) than you need to. Which looks like a memory leak, but is actually unintentional liveness.
And to prove the difference between "cannot be referenced" (a property that can in principle be checked by consulting a snapshot of RAM at an instant in time) and "will not be referenced" (a larger set, we will never reference things that cannot be referenced, but we may not reference things that are reachable, depending on code) feels like it is requiring solving the halting problem.
And for free()-related problems, I've definitely seen code crash with use-after-free (and double-free).
Both situations prevent you from reusing memory previously used by other objects, which isn't being utilized for anything useful at that point. The distinction is valid formally, but from a practical point of view sounds rather academic.
> And to prove the difference between "cannot be referenced" (a property that can in principle be checked by consulting a snapshot of RAM at an instant in time) and "will not be referenced" (a larger set, we will never reference things that cannot be referenced, but we may not reference things that are reachable, depending on code) feels like it is requiring solving the halting problem.
As usual, looking for a general solution to such a problem is probably a fool's errand. It's much easier to write code simple enough that it's obvious where things are referenced. Rust's lifetime semantics help with that (if your code isn't all that simple, it will be apparent in the overload of punctuation). If not Rust, then at least it would be good if you could check liveness of an object in a debugger. In C you can check whether a particular allocation was undone by a free() or equivalent. I'm not aware of any debugger for e.g. Java which would let me point at a variable and ask it to notify me when it's garbage collected, but it sounds like something that shouldn't be too hard to do, if the debugger is integrated with the compiler.
Often you don't need to care about the extra allocations and can just deserialize to owned types.
The code for owned deserialization certainly ends up looking more elegant.
I want to say that seems like a valid concern but in practice I've seen it come up only rarely.
Eg cloning a string leads to an extra allocation and a memcopy.
If you want to get a similar performance profile to GC languages, you have to stick your types behind a `Rc<T>>/Arc<T>` or `Rc<RefCell<T>> / Arc<Mutex<T>>` if you need mutability.
But modern allocators hold up pretty well to a GC, which amortizes the allocations. The extra memcopying can be less detrimental than one might think.
const obj1 = { a: 32, b: 42 };
function foo(ref) { ref.a = 0; }
foo(obj1);
console.log(obj1);
Basically all I was saying is one can not approach writing Rust with a Java/JavaScript mindset. (That a variable is just a bucket holding a value). Care needs to be taken when referencing a variable as it may need to be moved, copied/cloned or referenced. In the case of copying, another memory allocation is done. So if someone approaches Rust from the standpoint of "this word represents a value, and I'm going to use it all over the place", they can find themselves blindly allocating memory.
However when you take a high level feature like overriding operators which can be done elegantly in Python, for a complied language, Rust's way is quite concise, readable and to my eyes quite pretty.
Edit: Typos
Edit - actually I was probably thinking of this podcast with the same interviewee: https://rustacean-station.org/episode/004-rust-in-production...
Also reading Python code is easier (less syntax noise) on the eyes. The article above is very beginner Rust, and I won't rely on that to look at actual Rust code in the wild.
If you want to take a look at what actual Rust code in the wild, take for example, a web server Actix, and try to figure out what the documentation says.
At least idiomatic Python shuns wildcard imports that obfuscate where symbols are coming from (that drove me insane in Ruby).
On the other hand Rust code tends to be very strict about what your types are (even more so than a language like C++ where metaprogramming is duck-typed by default). It can lead to complicated code, but baring some weird operator overloading decision you should know exactly what calls what from whom when you look at any method or function.
Rust code can be tricky to write at times, but I generally find it a pleasure to read. Sure, ultra-complicated generic code can be overwhelming, but this complexity would be here in one form or the other regardless of the language, Rust just forces you to be explicit about it.
I don't agree with this, and, if anything, this reads very biased.
Insofar, Rust has made my life a lot easier, and I have not run into any major issues aside the borrow checker. And this was early on. Two years now playing with the language and I barely run into it anymore.
Majority of people will probably want to use Rust for web? Which makes async needs to be ergonomic enough if it wants consider wide adoption.
Disagree here. Like article Rust 2018 is very nice and ergonomic. Iterators, Lifetime Elision etc are nice to work.
Regarding noise many people consider those noise but I find noises like return types etc very useful. Because I can be sure the return type. Regarding actual code actix doesn't look that bad from examples also.
I use warp and its pleasant to work. The only thing I hate is compilation time other than that I don't think I have any major criticism against rust. But compilation time is near to cpp etc so ...
let re = Regex::new("(?P<min>[0-9]+)-(?P<max>[0-9]+) (?P<letter>[a-z]): (?P<password>[a-z]*)").unwrap();
re.captures_iter(&contents).map(|caps|
Input {
password: caps.name("password").unwrap().as_str().to_string(),
letter: caps.name("letter").unwrap().as_str().chars().next().unwrap(),
min: caps.name("min").unwrap().as_str().parse().unwrap(),
max: caps.name("max").unwrap().as_str().parse().unwrap()
}
).collect()If the code is supposed to be maintainable, you could also make something like a FromRegex trait for Input. It would be a good idea to try exercism's mentoring thing to get better at writing it the easier way the first time. The mentoring thing really is what helped me to think in ways that made this mess easier to avoid.
The really horrendous scenario was when I was trying to navigate pest iterators for parsing according to a grammar.
error[E0599]: no method named `parse` found for enum `Option<regex::Match<'_>>` in the current scope
--> src\main.rs:24:39
|
24 | min: caps.name("min").parse().unwrap(),
| ^^^^^ method not found in `Option<regex::Match<'_>>`I don't know what the structure Input looks like but I played around with your code and it seems to work with as_str()
https://play.rust-lang.org/?version=stable&mode=debug&editio...
This has been my, and a lot of my colleagues', experience with Rust. Never have I seen people fall in love with a programming language so strongly. And the love lasts for a long time.
That may not be what you meant but it seems like that’s what people are understanding.
This suggests experience far more than a single hour, does it not?
They didn't, though? They indicated that they had a similar experience of falling in love with it quickly. That says nothing about when that experience happened.
Semi-colons do make make possible multiple statements on a single line -- but surely there's a stronger rationale than that.
Sarcasm?
Some syntax is close to Python so some mental load is minimized, i.e use of snake_case, self, None and type annotation syntax, dict unpacking.
Some lines read like sentences i.e. for loops, single line if statements, impl Foo for Bar etc. Some design choices also read better I think, for example, let reads better than var.
Of course such preferences are personal. I've read other comments that mention that the tutorial covers only basic Rust features and it can get much more complicated when using more advanced features.
Edit: Added sentence about advanced features.
In other words, someone who doesn't have a CS background, never took theory of programming languages, etc. "Python programmer" is like the 2020's equivalent of a "HTML developer" from the 2000s.
At some point I just started writing these things in Rust instead. Describe what I want deserialized as a struct. List the fields I want as enum variants. What's that, rustc, the "name" field is optional? Ok, that makes sense, I'll handle this right away. Done. Hey, rustc, how come people talk about fighting you all the time when you're actually the world's greatest pair programmer?
That said...both languages read like close siblings to me to the point I find it annoying switching between the two because I keep trying to use each ones language semantics in the other subconsciously.
I'm curious what other what other developers who primarily use Python think of this article and Rust in general?