421–430 of 511 posts
Earlier quoted context omitted.
How are you trying? What are you getting stuck on? I'd love to improve things.
I'd get excited and go through some tutorial on their website, probably the main? tutorial, bu then when you get to the lifetimes section is seemed to get really complicated instantly. I tried twice and think I hit the same problem. Maybe some more good examples would help?
Earlier quoted context omitted.
Right, so you implement them with unsafe. While you can implement doubly linked lists safely with refcounting, you're perfectly free to implement them with unsafe code. This is what unsafe code is for , designing low level abstractions with clean API boundaries. (Also I don't see how this is relevant at all)
Right, so you implement them with unsafe. If you need unsafe code for basic operations within the language, something is wrong with the language. This isn't about talking to hardware, or an external library. It's pure Rust code. (Some pointer manipulations can be built from swap as a basic operation. That may work for doubly-linked lists. The other big problem is partially valid arrays, such as vectors with extra spa…
Building custom back-referencing data structures is not a "basic operation" anywhere outside programming classes. Adding significant complexity to rust Rust to make a 2% case marginally safer would be make the language worse. As long as the vast majority of code is not unsafe, then it achieves its goal.
Earlier quoted context omitted.
Rust itself can't, but you as the programmer can. It's not quite C, but you can do a lot of reasoning about what the compiler will do with your code, and avoid pathological cases.
Absolutely, you have to be aware of the ownership graph depth in both C and Rust if you want to bound latency. You don't have to do this with tracing GC though, you just need a runtime that implements latency bounds.
I'd love to see someone write a game engine in Rust to compete with the "big boys" like Cry or Unreal. C++ game code can be such a nightmare.
Cry/Unreal? Unlikely. But something in the lines of LOVE( https://love2d.org/ ) would be awesome!
Earlier quoted context omitted.
> However it does nothing, and probably cannot, address the security i.e. the impact on my own safety or that of my assets. Sure it can. It actively prevents certain type of errors (buffer overflows, integer overflows), which are prime security exploits. Less exploits == more security.
My standpoint is that: - Less exploits is an improvement in frequency - More security is a question of limiting impact
Earlier quoted context omitted.
> The problem is that you still need extra annotations. Namely lifetime annotations Well, the idea is not to have the static analyzer verify typical C++ code. Just some practical subset. So for example I think it's quite practical to write C++ code that uses only "scope" pointers (basically pointers to objects on the stack) and (not-null) refcounting pointers, that intrinsically don't outlive their targets. Lifetimes…
> So wait, what more does Rust's static analyzer give us again? Does it somehow remove the need for refcounting heap objects? Refcounting is rarely needed because most sharing is done via "borrows", which usually work via scope-tied "references" which may point to either the stack or the heap. Implementing and enforcing local scope pointers in C++ via static analysis is not hard. Making it possible to thread borrows…
> I guess I misunderstood your proposal. This sounds doable. But, again, you'd be using a weird subset of C++ that doesn't seamlessly integrate, and you're just better off using Rust at this point.
My proposal is sort of language independent. I'm just suggesting a better way to address the code safety/correctness issue might be with runtime asserts, because it's more general. Some of the runtime asserts (like the ones regarding memory safety) will be automatically generated by the compiler, and others would be user defined (but compiler placed). And the static analyzer (I guess "the borrow checker" in Rust) would be repurposed to strip out the unnecessary runtime checks. And the compiler/optimizer would tell you which runtime asserts it was unable to optimize out. (Presumably good Rust code would result in all the memory runtime asserts being optimized out.)
This allows for programs that are not just memory safe, but "application invariant" safe as well. Right? I mean it's not really a totally new concept, I guess it's kind of "design by contract" or whatever, but with a slight performance bent because the optimizer tells you what runtime checks it's having trouble getting rid of. And maybe there would be a way to indicate that you expect the optimizer to be able to get rid of certain runtime checks, and instruct it to generate a warning (or error) if it doesn't. I'm just sayin'...
Earlier quoted context omitted.
Speaking of HTTP clients, just yesterday the person behind Hyper announced their new high-level HTTP client crate: http://seanmonstar.com/post/153221119046/introducing-reqwest
Not sure what to think of that. Does everything have to be async I/O now? How often do you need massive numbers of client connections?
Earlier quoted context omitted.
.unwrap() is only the right choice if you need to optimize for binary size and can't afford the cost of the precise error message you would pass to .expect(). There are situations where you can't possibly continue running the application if an error occurs, but you shouldn't rely on a backtrace (which you might not manage to capture, e.g. if RUST_BACKTRACE is unset or you don't have symbols) as your only method of co…
This is not true. For example, consider this code: if foo.is_some() { let foo = foo.unwrap(); } else { // other code } Here, I _know_ that foo is some. The extra error message from expect will _never_ be seen. Now, this is a contrived example, and would better be written with `if let` in today's Rust, but this is the _kind_ of situation in which unwrap is totally, 100% cool, but the compiler can't know.
If the author knows it's safe, they should be able to express how they know in a way that the compiler can understand. Certainly I think there's a large space of use cases where the extra guarantee provided by forbidding unwrap would be well worth the cost of outlawing some "legitimate" cases, especially if we're just talking about doing so on a project level. (Though maybe they're not the rust target audience).
Earlier quoted context omitted.
> So wait, what more does Rust's static analyzer give us again? Does it somehow remove the need for refcounting heap objects? Refcounting is rarely needed because most sharing is done via "borrows", which usually work via scope-tied "references" which may point to either the stack or the heap. Implementing and enforcing local scope pointers in C++ via static analysis is not hard. Making it possible to thread borrows…
> Right, but at this point you have a very weird looking subset of C++ It's a little weird looking at first glance, but ultimately it's not really that weird. The main unfamiliar thing is that objects that are going to be the target of a (safe) pointer need to be declared as such. So { std::string s1; auto s1_ptr = &s1; } becomes { mse::TXScopeObj s2; auto s2_ptr = &s2; } s2 acts just like a regular string. It's just…
Readability is important for maintainable code. And safe coding patterns tend to involve a lot of sum types (which you can model in C++ with the visitor pattern, but it's significant overhead in code length and possibly even at runtime), and a fair amount of generics (which are cumbersome in C++, and the error reporting is awful). If you're not going to get the existing tool/library infrastructure either way, so you're just evaluating on their merits as languages, I don't think you'd ever want to pick C++ over Rust.
> modern C++ code is mostly safe already.
I've been hearing that for about a decade now (and I suspect the only reason it isn't longer is that I wasn't programming before then). And yet we still see bugs, all the time. Not subtle bugs, but stupid, obvious bugs.
> Is the language stable now?
Yes, as of 1.0.
> Is it time to jump in? Has it vanquished D as the successor to C++? Are we happy with Rust's solution for exceptions?
Yes.
> Even if Rust is the future, and the future is here, I'm still stuck with existing C++ projects. And I'd feel better if they were (at least mostly) memory safe.
My belief is that no amount of whack-a-mole is going to make those projects memory-safe, and none of the linters/checkers/dialects is ever going to reach a point where it offers actual guarantees. If it were possible it would have happened by now. The only way you're going to get to memory safety is by rewriting those projects, bottom to top (which is probably what you'd have to do to use one of these C++ dialects anyway). If you want to do the migration gradually (and you should!) rust has pretty good interop.
Earlier quoted context omitted.
Being able to cut corners with code hygiene works both ways though for productivity: you don't want to realize a week before a deadline that you have a hard-to-find memory leak or crash. A lot of the time it feels like rust development is slow because you are fighting the compiler. On the other hand once you run the program you often get that Haskell-y "it worked because it compiled" feeling. With a normal OO languag…
I haven't experienced that feeling for anything but toy programs. But concerning productivity: fighting the compiler sometimes means abandoning perfectly reasonable (and efficient!) designs just because the compiler doesn't like them. I'm not aware of any type corsets that I think force good designs. In a really clean design mistakes are not terribly hard to fix, even in a language like C. Granted in C they are in so…