321–330 of 511 posts
Earlier quoted context omitted.
There's been a few; this one is built on top of mio, one of the most popular previous ones.
I meant this one which I saw mentioned recently: https://github.com/alexcrichton/futures-rs
Earlier quoted context omitted.
Correct me if I'm wrong, but it looks like this just provides some 'safe' alternatives to unsafe C++ things. It's still up to the diligence of the programmer to not use those things and nothing is getting statically verified. By contrast, when I write Rust, memory safety (and type safety) are verified by the compiler.
Sometimes I think Rust people lose the forest for the trees. The end goal isn't for the compiler to verify the safety, the end goal is for the software itself to be safe in a way that's cheaper. It doesn't really matter if they both end up at the same place, which is safe software.
I think the contention is that, unless you're applying NASA style rigor, you don't end up in the same place without verifying the safety automatically, because in practice it's too expensive to verify the safety manually (without getting squeezed out of the space by your competitors.)
SaferCPlusPlus's goals are noble, but approaching the problem with a library-only solution is problematic. None of the huge swaths of legacy and third party code I'd like to sanitize uses it - and a large scale rewrite to 'fix' that may very well introduce more bugs than it fixes. A library cannot 'fix' fundamental language constructs either, short of telling you to please remember to perfectly avoid those language constructs even if you're very very used to them. Frankly, I'm skeptical of how useful I'd find SaferCPlusPlus even for new projects - especially when modern SC++L implementations already have a lot of error checking code built into them as well, at least for debug builds.
Meanwhile, I already credit these to saving me at least a month of debugging time: http://clang.llvm.org/docs/ThreadSafetyAnalysis.html
I'm interested in Rust because it takes the same approach to securing code from bugs as seems to help a lot when I apply it to C++: Static analysis and annotations, designs to make edge cases impossible to ignore, and where static analysis cannot perfectly find all problems, let it error out reliably at runtime instead of randomly corrupting memory unless I really really really mean it.
Earlier quoted context omitted.
I very strongly believe exceptions are a lot closer to optimal than Result is. Exceptions remove the need for inline error checking code and make it possible to implement types with value semantics. You can't have reasonable value types that own resources if you need explicit error checking. The need for explicit error checking makes OOM handling in Rust awkward at best. I've ranted about this side effect before. Als…
I think I know what this trend is, more generally. It has to do with how explicit our code is. We've been through an era where you have some very powerful and compact indirection constructs(event callbacks, polymorphic objects, dynamic types, exceptions) in common parlance and the trend has turned against these lately. Their utility in many instances is mostly to enable technical debt, by worrying about the edge case…
Earlier quoted context omitted.
Seriously? Rust's error handling is great, and frankly I'm glad that exceptions have gone out of favour. I tried them but they never really delivered their promise. At their best they do is give you nice stack traces. At their worst they make error handling stupidly verbose, they erase the context you need to properly handle errors, and they make it much more difficult to even know which errors can occur! Rust's solu…
I very strongly believe exceptions are a lot closer to optimal than Result is. Exceptions remove the need for inline error checking code and make it possible to implement types with value semantics. You can't have reasonable value types that own resources if you need explicit error checking. The need for explicit error checking makes OOM handling in Rust awkward at best. I've ranted about this side effect before. Als…
The proper place for the period in that sentence is before the "if"; owning resources is not a reasonable thing for a value type to do.
Earlier quoted context omitted.
Why would you use libc embedded? Most of libc kind of expects an OS to be there.
Uh? There are definitely trimmed libc's (not GNU libc!) that run on bare metal. Such as the one used by avr-gcc for example...
Earlier quoted context omitted.
I very strongly believe exceptions are a lot closer to optimal than Result is. Exceptions remove the need for inline error checking code and make it possible to implement types with value semantics. You can't have reasonable value types that own resources if you need explicit error checking. The need for explicit error checking makes OOM handling in Rust awkward at best. I've ranted about this side effect before. Als…
> You can't have reasonable value types that own resources if you need explicit error checking. The proper place for the period in that sentence is before the "if"; owning resources is not a reasonable thing for a value type to do.
Earlier quoted context omitted.
The error message in this case might be something like "foo became None after verifying it to be Some". This could happen, for example, if incorrect unsafe code in another thread concurrently mutates foo through a raw pointer. My point is that of course while writing them you don't think your unwraps will fail, but if they do, it's good to have a reminder of what's going on. Even if the expect never fails, the messag…
You'll like Rust, because concurrent mutation of a value is impossible if you hold a `&` or `&mut` to the value. So this can in fact be ruled out by the programmer.
Earlier quoted context omitted.
C seems to be going through yet another renaissance. C is a smaller language to learn. There is tons of legacy code even for embedded systems.
C is a smaller language to learn. There are engineers with 20 years of C programming experience that will still make security errors while handling basic strings. "Small" does not mean "good" and "learning" a language doesn't mean you'll write good code with it.
It's like comparing x86 to, say, m68k (or most things, really). One was designed. The other is an ungainly mess of hacks on top of hacks, which has a good, elegant design in there somewhere, desparately trying to get out. Guess which one is x86.
Now guess which one is C.
Worse really is better. Or at least, good enough.
C isn't a complete mess, and you can write good code in it if you're very careful, but it's not great.
Although I am not against improving the safety of languages we use for system programming, the model that Rust advocates are pushing of "preventing mistakes" as a way to make systems secure doesn't convince me. Mistakes (and security breaches) happen. A system should be written in such a way as mistakes are few, indeed, however it is essential to also efficiently protect our users' assets (data) first, assuming that…
#2 is up to the engineers making the product. #1 is why Rust exists: it eliminates whole classes of errors. No, it won't stop you from screwing up badly, but it just might stop the buffer overflow or race condition that would have helped a hacker steal your users' identities.
Earlier quoted context omitted.
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?
Asynchronous nonblocking interfaces are more general-purpose than synchronous blocking interfaces. I can't speak for this library or Rust specifically, but in my experience well-designed asynchronous libraries allow you to interact with them in a synchronous style as well, if you wish. Netty is an asynchronous, event-driven network framework for Java, and it's perfectly possible to expose synchronous blocking abstrac…
(When I moved from UNIVAC mainframes to UNIX, things seemed so sequential. No threads. No async I/O.)