221–230 of 323 posts
Earlier quoted context omitted.
The easiest way to build graphs in Rust is to store all your graph nodes in a Vec, and use indices instead of references to refer to other nodes. Also a cache locality win.
This is really the only practical way to do it, yes. But it's gross and means that you have to write custom code to print the data structures. That might sound trivial, but the ability to autoderive pretty printers is super useful when debugging.
Earlier quoted context omitted.
> Ah, it sounds like you're using traits as types directly, which is very much discouraged by Rust (especially in conjunction with taking references to those traits). What the language really prefers for you to do is to use traits as bounds on generic types Can you write an example?
Sure thing. [Preemptive postscript: damn this got long. TL;DR don't use trait objects, just use generics. You'll thank me.] Here's the setup: we have several different types, and those types implement the same trait (think of it like an interface from other languages). // Define two different types struct Chihuahua; struct GreatDane; // Define a trait with a method trait Bark { fn bark(&self); } // Implement that met…
As someone who has been programming in Rust for nearly a year, even for commercial purposes, this article is baffling to me. I've found the compiler messages to be succinct and helpful. The package system is wonderful. It's dead easy to get something off the ground quickly. All it took was learning how and when to borrow.
That's disingenuous. It's really not as simple as you're trying to make it sound. But I don't understand the point of this guy's blog post, unless it's just to whine. There's so little real content in his post.
Earlier quoted context omitted.
This is really the only practical way to do it, yes. But it's gross and means that you have to write custom code to print the data structures. That might sound trivial, but the ability to autoderive pretty printers is super useful when debugging.
Or just use petgraph, which does this for you.
Earlier quoted context omitted.
Yes, slower than modern GC, but predictable and deterministic. Note that the parent comment never claimed it was faster, just that it avoids 'stop the world' which can be a problem in realtime contexts (e.g. games, audio).
Reference counting can also lead to big cascades of objects being freed, which can make it impractical in realtime context as well. This makes RC useless for systems which have hard constraints here (e.g. automotive). And of course, once you are multi-threaded, you can more or less forget about "predictable and deterministic" with RC, too. In contrast, there are real time capable garbage collectors.
Besides, the real time capable garbage collectors are basically just backed in implementations of exactly that. With reference counting, it can be written in the language itself, rather than as a tunable external part of the implementation, which is useful.
Earlier quoted context omitted.
Writing Rust code isn’t that hard, sure. The annoyences start when you try modifying code or moving things around. Prototyping and editing code makes for most of my work, and Rust makes that a chore. That’s my main gripe with the language. It’s more like moving through molasses than encountering a brick wall.
It's interesting how perspectives differ; I love refactoring Rust code more than any language I've ever used, as it catches so many of my errors when doing so for me, at compile time.
> universally terrible documentation Wait, what? Rust has what I consider the best documentation I've seen of any language. The docs explain things at a high-level, but concisely, and have numerous examples. The formatting is good, the keyboard navigation support is good, it's well-linked, and it has convenient features like links to the source and the ability to collapse everything but method headers for easier brow…
(Author here.) I wrote this piece hastily, and it really wasn't intended for this broad of an audience — I won't redact the existing wording I still think it's roughly right, but I do regret a lot of it. Rust's docs are amazing in certain contexts — the book is great, the built-in support for documentation on types/functions/etc. is amazing, and compiling code examples are a very laudable idea. What I'm speaking to h…
Don't even know how many times I've had to dig into the python sources to figure out why something wasn't working as intended...
My favorite: I was trying to get memory buffer working for an object (following the official docs) using the C-api and it just didn't work no matter how much I fiddled with it so I go digging through the python sources and find out the fully documented feature I was attempting to use wasn't even implemented. Well, half the PEP was implemented.
I'm probably just funny that way since if I can't figure something out from docs I just go read the sources.
Earlier quoted context omitted.
Doubly linked lists are impossible in safe rust by definition since the only safe way to modify a memory location is via a &mut reference. And Rust guarantees that that any memory location can only be pointed to by only one &mut reference. A doubly linked list by definition has two pointers pointing to each node, so no, your example will not work.
The example uses raw pointers, which aren't safe Rust. Note the *mut, not &mut. It's the direct translation of your C, which is why I mentioned that specifically.
Earlier quoted context omitted.
The example uses raw pointers, which aren't safe Rust. Note the *mut, not &mut. It's the direct translation of your C, which is why I mentioned that specifically.
If it has no protections then why even use rust? You cannot both claim safety and then claim versatility by abandoning said safety. Because without your claimed safety, I might as well use C and not do battle with my compiler.
Clinging to an exceptional case and pretending it's the rule doesn't hold in practice.
Earlier quoted context omitted.
But ? only worked if the function it was used in had the same error type as the function you called, which was mostly not the case... ... I think. I don't remember it that vividly.
? calls a conversion function. It only won't work if the error you're trying to return won't convert to the error that's in the type signature. Even then, you have options, like .map_err.
Having to implement a bunch of From traits (unless you need io::Error, because everything seemed to have conversions from/to that), or having to implement inline error conversion through map_err, is such friction. I might go as far as consider it the most cumbersome error system I have used. Clean idea, cumbersome implementation.
My comment about '?' not working with mismatched types was mostly just to say that it doesn't fix anything, it just adds a bit of convenient syntactic sugar.