231–240 of 474 posts
Rust is about letting the compiler slap you for your mistakes in the privacy of your own Xterm, instead of letting Jenkins do it 10 minutes later, in front of all your co-workers.
Maybe it will change in future. Currently slaps seems so hard that developers are still smarting and not producing code for production
Earlier quoted context omitted.
No, because if you explicitly converted to another type, that's what you wanted.
Sometimes you want it to be lossy, but not most of the time, and yet there is no choice. I had a bug caused by that, that's why I remember it. Silent explicit type conversions are essentially unsafe.
This is a contradiction, something cannot be both silent and explicit.
Earlier quoted context omitted.
I absolutely agree. If you look at Rust from a systems programmer perspective and compare it with the systems languages OP lists then, yes, safety is THE most radical feature. But Rust can compete on so many more levels. Web services, user facing applications for example. Languages competing in that space usually bring memory safety, so it's kind of a non-issue. Safety enables Rust to be a viable choice for these tas…
IMO the biggest plus for rust is actually cargo. Building, versioning, and sharing modular code is essentially copy/paste in C/C++, and compared to that cargo is lightyears ahead. I actually wish rust would accept its systems niche even more and move the stdlib to crates and make nostd the default mode. Personally, I see no reason to market rust for webapps or gui stuff, it cant/wont compete with Rails/QT for years t…
Earlier quoted context omitted.
I'm sorry your comment has gotten the response it has. The looming dark cloud of stable vs. nightly only looks like a dark cloud to those outside the Rust community. The article that made its way up Hacker News awhile ago ( https://news.ycombinator.com/item?id=13251729 ) got pretty much no traction whatsoever in the Rust community.
I have found the split has only gotten better with time. It used to be most package maintainers assumed you were using nightly/beta. The last holdouts I see are diesel and serde which have instructions for using nightly. Even then they realize no one wants to ship code on nightly so they provide directions for making a building using stable rust. Once the procedural macros stuff is stabilized they can stop. I have be…
Earlier quoted context omitted.
Ada still requires manual heap management, although it can be mostly automated. So you might occasionally see the unsafe package being used to deallocate memory, even though there are better ways to do it, e.g. controlled types. The other point, is that Rust prevents data races via the type system, while you can deadlock Ada tasks if the monitors aren't properly implemented.
> while you can deadlock Ada tasks if the monitors aren't properly implemented. It's not clear to me if you're suggesting otherwise, but you can definitely deadlock Rust as well (although it's true that Rust statically prevents data races).
What about stack overflows? I heard that rust no longer protects against those for benchmark reasons.
There is a reason Rust has debug and release builds as well to what other commenters have said. In the debug builds there are safeguards against almost everything at performance cost, the way you are supposed to use it is to test your debug builds thoroughly and then you can trust the release builds to be safe because your code doesn't change, the compiler just doesn't insert as many guards.
Rust is about letting the compiler slap you for your mistakes in the privacy of your own Xterm, instead of letting Jenkins do it 10 minutes later, in front of all your co-workers.
Maybe it will change in future. Currently slaps seems so hard that developers are still smarting and not producing code for production
Earlier quoted context omitted.
And there's a tired security crowd watching Rust with great hope; C++ and C have created innumerable security holes at the expense of "convenience". Cryptographic libraries, codec libraries, image conversion libraries, OS kernels, sandboxes, virtual machines, browsers, (the list is endless) have all suffered glaring security holes from the lack of memory hygiene afforded by C and C++. Any time your code takes in untr…
Exactly. Which is why I've been so critical, in Rust discussions, of the excessive use of "unsafe". The reply is usually something equivalent to "it's not unsafe the way I do it". Sometimes the claimed performance gain isn't there. I had a link yesterday to a forum post where someone was complaining that using an unsafe vector access function didn't speed up their program. Optimizer 1, programmer 0. (Early in my care…
I agree that we should avoid unsafe as much as possible and be sure that unsafe blocks are justifiable (with stringent criteria on justification). I'm don't think as-is this is currently a problem in the community.
It's good to be wary though :)
Earlier quoted context omitted.
Well, if no one is tracking it, there is no count and that would thus be countless. But in all seriousness, I am curious about this as well.
It's not "countless" it's "uncountable" because we couldn't agree on what a software caused death was. In my CS program we had an ethics class that included stories of bad X-ray machine software that overdosed people. Bad, bad bad. I don't think many people died as a direct result, but 10 years later there was probably a spiked cancer incidence. Did software kill people? Well yeah....kinda. In airplane systems, there…
I was just thinking about this the other day when using Spotify in the car. Spotify's UI is pretty good, but after they lost all my saved songs, I've had to resort to only using playlists, which require 3x as many clicks to add a song.
The issue with safety is that nothing is really safe. Once you have some level of safety in your programming language, you realize that there are still a lot of other sources of hazard (hardware errors, programming logic errors etc.) So I guess, it would be better to say that Rust is about decreasing unsafetyness or whatever the correct word for that is. edit: since I see posts about Go, this is evidently another app…
As you consider higher (application) level notions of safety, it generally becomes less practical to achieve that safety statically (at compile-time), so you'd want your language or your framework or whatever to facilitate the implementation and performance optimization of dynamic (run-time) safety. At the moment I'm thinking about automatic injection of run-time asserts (of application level invariants) at appropriate places in the code. (At the start and maybe at the end of public member functions for example.)
If you subscribe to this idea, then it sort of follows that Rust's borrow checker may be "in the wrong place". That is, rather than forcing you to write code that is memory safe in a particular statically verifiable way, Rust could have instead enforced memory safety by injecting run-time checks into the code and optimizing them out when it recognizes code that appeases the borrow checker. (Of course the optimizer could report what run-time checks it was not able to optimize out, if you wanted to self-impose static verification.)
(Statically optimized) dynamic safety is more scalable than statically verified safety. As a "systems language", Rust may be less concerned with higher/application level safety. But I think this might be a little short-sighted. The definition of "system" is expanding, and the proportion of "higher level" safety concerns along with it.