I haven't used Rust, but generally speaking wouldn't you say that safety in some sense includes the other nice features? For instance, if it were safe but not fast (like, say, a GC language) it wouldn't be useful. So it has to be safe and fast (which it sounds to me like it is). Okay, so what if it were safe, fast, but a real hassle to use? Well that's not very useful either. So it has to be safe, fast, and usable. Just like Moxie's approach to security: focus on usability, so people actually use the damn thing. And it sounds like all the other nice features make Rust more usable.
Rust is mostly safety
281–290 of 474 posts
Re: Rust is mostly safety
#282I think Rust is mostly about safety in the same way that skydiving is mostly about safety. Having safety features that you know you can rely on allows you to take risks that you normally wouldn't in order to accomplish some really awesome things. (I guess in this analogy C is a parachute that you have to open manually, while Rust is a parachute that always opens at exactly the right altitude, but isn't any heavier th…
Have you done much skydiving? I used to go three days a week, for a couple years, between 4-10 jumps a day at a place that had world class experts. My experience is that only beginning skydivers are constantly preaching safety. They go around (vocally) judging everything they see, and I think they do it because it alleviates their own fear. Instructors would teach safety, but really only to their own students.
I think the safety aspect of Rust appeals to a lot of beginning programmers. They can feel safer looking down their nose at us dangerous C or C++ programmers.
> Rust is a parachute that always opens at exactly the right altitude
This isn't a good metaphor. Frequently it's safer to pull higher, and on some occasions, you're safer opening lower than you had planned... I think a canopy that always opened at the prescribed height would cause many unnecessary deaths. That doesn't say anything about Rust, one way or the other.
Re: Rust is mostly safety
#283Earlier quoted context omitted.
I am still skeptical that "excessive use of unsafe" is actually a thing happening in Rust. Almost all the unsafe I see is for doing FFI (either for interfacing with a library or OS primitives). There's a bunch of it for implementing datastructures and stuff, and extremely little unsafe being used "for performance". Off the top of my head nom and regex do this in a few places, and that's about it. Grepping through my…
You keep making that claim without backup. Two days ago I posted links to extensive use of "unsafe" in matrix libraries. (Some of that code was clearly transliterated from C. Raw pointers all over the place.) That's entirely for performance; all that code could be safe, at some performance penalty. I'd suggest using only safe code for whatever matrix/math library gets some traction, and then beating on the optimizer…
I just gave you backup; I grepped my whole .cargo cache dir (both the one used by servo and my global one). You have also made your claim without backup -- you have repeatedly claimed that this is an endemic problem in Rust, with only individual crates (most of them obscure ones) to back it up, and I only usually make my claim in response to claims like yours -- the burden of proof is on you. Anyway, I do provide some more concrete data below, so this isn't something we should argue about.
Marices fall under the abstraction umbrella IMO. This is precisely what unsafe code is for. However, I totally agree that we should be fixing this in the optimizer, with some caveats. Am surprised it doesn't get optimized already, for stack-allocated matrices. I'm wary of adding overly specific optimizations, because an optimization is as unsafe as an unsafe block anyway, it just exists at a different point of the pipeline. If there's a general optimization that can make it work I'm all for it (for known-size matrices there should be I think), but if you have a specific optimization for the use case imo it's just better to use unsafe code.
The raw pointers thing is a problem, but bad crates exist. They don't get used.
I recently did start going auditing my cargo cache dir to look for bad usages of unsafe, especially looking for unchecked indexing, since your recent comments -- I wanted to be sure. This is what I have so far: https://gist.github.com/Manishearth/6a9367a7d8772e095629e821...
That's a list of only the crates containing unsafe code in my global cargo cache (this contains most, but not all, of the crates used by servo -- my servo builds use a separate cargo cache for obsolete reasons, but most of those deps make it into the global cache too whenever I work on a servo dep out of tree)
I've removed dupe crates from the list. I have around 600 total crates in my cache dir, these are just the ones containing unsafe code.
Around a 70 of these crates use unsafe for FFI. Around 30 are abstractions like crossbeam and rayon and graphs.
I was surprised at the number of crates using unchecked indexing and unchecked utf8. I suspected it would be less than 10, but it's more like 20. Still, not too bad. It's usually one or two instances of this per crate. That's quite manageable IMO. Though you may want to be stricter about this and consider those numbers to be problematic, which I understand.
I bet you're right that many of these crates can have the unchecked indexing or other unsafe code removed (or, the perf penalty is not important anyway). I probably should look into this at some point. Thanks for bringing this to my attention!
Re: Rust is mostly safety
#284Earlier quoted context omitted.
Which is something I never understood. Since you are mainly wrapping OS API, why not take a higher level langage ?
What language you have in mind?
Anything that is robust, dynamic, with a big ecosystem. Python, Ruby, whatever have you. You don't need raw speed since the OS API does most of the work, and the ease of programming would make it more productive. In the end, they added Python anyway for stuff like "compose", so I'm missing the point of using Go for this. The Go code is not even network bound, the ability to get multicore easily is not a bit advantage here since you spawn a new process anyway, so really, why ?
Re: Rust is mostly safety
#285Earlier quoted context omitted.
Which is something I never understood. Since you are mainly wrapping OS API, why not take a higher level langage ?
For all the benefits of higher-level languages. Remember that the designers of C had to agree on every feature that went into Go: a language they co-designed for better programming experience & results. Wirth-style languages also compile ultra-fast for quick iterations.
My question is really why not choose something really higher level ? Go is like stuck in the middle. If I need very low level, I'd choose rust. If I need high level, I'd choose Python. Go is kinda filling a weird niche between the two and I rarely find a case where I feel like it's the best choice.
Re: Rust is mostly safety
#286If you're a C++ programmer, Rust is mostly about memory safety. If you're a Java programmer, Rust is mostly about tighter resource usage. If you're a Python programmer, Rust is mostly about type safety and speed.
I'm a polyglot programmer and for me Rust is mostly about the awesome abstractions and the great community.
> If you're a Javascript programmer, Rust is mostly about the awesome abstractions and the great community.
;)
Re: Rust is mostly safety
#287Earlier quoted context omitted.
Well there is this famous Ada failure: http://www.math.umn.edu/~arnold/disasters/ariane.html Although that was not a failure of language safety, but an overflow issue. The software was designed successfully for another rocket, and was reused for a rocket that didn't match the original specification.
It's a specifications issues, not a programming issues.
I disagree. The programmer is the expert in types, so it is the programmers duty to ensure that the possible values stored in a variable of a given type are compatible with the type selected. Particularly when it comes to these sort of critical applications.
Programmers blindly following specs put together by people who have no claim to expertise in these matters without questioning the assumptions behind the spec is the cause of all manner of disasters. And "but that's what the spec said to do" is all to common an excuse when the problem is with subtle runtime behavior issues that fall squarely in the programmer's domain of responsibility.
Re: Rust is mostly safety
#288The 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…
> The issue with safety is that nothing is really safe. There is a trade-off between safety and expressiveness. Clearly you can always shoot yourself in the foot if your language is expressive enough (like any Turing-complete language). But I think that is beside the point here. This is about eliminating whole classes of errors. A good type system (e.g Rust's, Haskell's..) can eliminate all type errors from your prog…
> A good type system (e.g Rust's, Haskell's..) can eliminate all type errors from your programs.
It depends what you call a "type error". Is calling `car` on a `nil` instead of a `cons` a type error?
Re: Rust is mostly safety
#289The original Rust author make great points about safety. I think this new thrust on marketing emerges from Rust Roadmap 2017 which puts Rust usage in industry as one of the major goal. Currently Rust is about Go's age but nowhere close in usage. As the roadmap says "Production use measures our design success; it's the ultimate reality check." I agree with that.
> Currently Rust is about Go's age but nowhere close in usage. Citation? I see a lot of people talking about both, but not very many public projects in either. Rust at least has a "killer app" on the way in the form of Servo, whereas I haven't heard of any user-facing programs in Go.
Rust code is also going into Firefox, slowly for now, but it will speed up over 2017.
Re: Rust is mostly safety
#290Earlier quoted context omitted.
I know and I would also try Rust if I can make some small but useful things at work. But I mostly deal with various combinations of XML, SOAP, HTTP, LDAP etc. Rust does not have anything over Java, which I use currently, in my usecases.
It's perfectly reasonable to say "Rust isn't appropriate for my use case". Your comment higher up was more along the lines of "Rust isn't appropriate for anyone" which is far less reasonable.
If you're going to put words in his mouth, you should make them much stronger words. It's not a valid argument either way, but it'll seem more dramatic. (He didn't say either of your quotes...)