2016 Rust Commercial User Survey Results
internals.rust-lang.org
internals.rust-lang.org
That's not a survey, that's a focus group.
I'm impressed with Rust. The borrow checker is the biggest advance in memory safety since garbage collection.
But there's a lot about Rust that's unnecessarily weird.
- The type system is unusual, and complex. It's hard to do anything without templates.
- The template libraries are heavily biased towards closure-oriented functional programming. This is cool, but hard to read. Parts of expressions are nameless and have no visible type. This is terse but hard to maintain.
- The hacks needed to avoid the need for exceptions are uglier than exceptions.
This creates major obstacles to adoption. Unlike the borrow checker, none of these things are clearly improvements. They're just different.
I would have gone for Python-type exceptions rather than error enums and macros, single-inheritance OOP rather than traits, and Python-type with clauses rather than RAII.
Do you mean the generic types and functions that stop you having to reimplement a whole pile of common patterns and data types yourself? You're welcome to write your own VecInt and VecString and VecMyStruct and VecYourStruct and OptionInt and HashMapIntString, but I'll go out on a limb and say that would be more annoying than <>'s in a few places. For one, not having generics would make it far more annoying to create reusable zero-cost abstractions around `unsafe` code, resulting in your other favourite criticism: more unsafe code for "unnecessary" (i.e. performance) reasons.
> - The template libraries are heavily biased towards closure-oriented functional programming. This is cool, but hard to read. Parts of expressions are nameless and have no visible type. This is terse but hard to maintain.
This isn't true: most generic types go via other schemes, and only use closures for simple combinators (making one line manipulations simpler and easier to read, but like with anything, can be abused), or when they're required to achieve the desired semantics (iterator pipelines).
---
In any case, (some of) your proposed replacements don't make sense as the only built-in for their given functionality, for a systems language. If the task in question can take the loss of control, then Python (or similar) seems like a better choice for you.
> would have gone for Python-type exceptions rather than error enums and macros,
True Python-style exceptions require allocations to handle errors.
> single-inheritance OOP rather than traits
This forces dynamic dispatch everywhere and loses type safety (when passing types through functions and storing them in data structures), rather than being able to specialise functions and data types, and track exact types through code.
Also, only offering single-inheritance has significant semantic problems, e.g. what happens when your type is both equatable and cloneable?
> Python-type with clauses rather than RAII
What exactly does this address? It seems just like a syntactic rephrasing of `let x = foo()`, given it would have to be compulsory for certain types, or else guarantees are lost.
---
Rust is, as you say, different to other languages, but very little of it (and none of the features you call out) was chosen just to be gratuitously different. The new features of course might just take a little time to get used to if one is coming from mainstream imperative/OOP languages.
For example try writing even a basic function accepting two scalars of type T and U and performing arithmetic on them. The way the Rust compiler works it isn't possible without specifying various bounds on the traits (which I appreciate, actually, for explicitness). And even then there are limitations around casting that require non-trivial workarounds (it is ridiculous, frankly, that the num crate isn't in the standard library, but that crate has its own problems).
And there is no specialization, which is a severe limitation.
Can't disagree with your comments re: python.
That's a feature! It works the same way in every language other than C++ or D that implements generics.
I much prefer explicitly typed generics to untyped generics as in C++. Not only are the error messages far more comprehensible, but it lets us avoid having to introduce confusing name resolution rules like ADL.
> And there is no specialization, which is a severe limitation.
There is now [1].
Also, huzzah for specialization. I'll try that out asap. Thanks for the heads up.
Just wait for C++20 and STLv2, you will also get that explicitness everywhere with concepts.
> The way the Rust compiler works it isn't possible without specifying various bounds on the traits.
This is an explicit choice: C++-style check-at-use-site results in some seriously ridiculous error messages, and there's no boundary between implementation and signature, meaning a change to some small detail (and even syntax, in C++) in the implementation can accidentally cause downstream code to fail to compile. It is definitely annoying some times, but Rust, and most other languages with some sort of templates/generics, thinks the benefits outweigh the cost.
> And there is no specialization, which is a severe limitation.
Indeed, it is a limitation that the team recognises and is working on: https://github.com/rust-lang/rust/issues/31844 (Parts of which are already available in the nightly releases.)
Some people want nice, simple, dense multidimensional arrays. Some want the ability to extract a square section from an array as a subarray. Some want that for N dimensions. Some don't want the overhead for that generality slowing down their matrix multiply. Some are content with arrays of arrays. Some want ragged arrays (rows not the same length). Some want arrays in a format a GPU can use.
Passing the buck to each package, though, results in recopying arrays as matrices move from a function in one package to a function in another. One reason people use MATLAB, FORTRAN, and Python's NumPy is that they at least have a standard representation and matrix functions interoperate. I'd argue for supporting dense arrays in the language (and the optimizer) and doing the fancy stuff in packages.
You mean generics not templates?
Nothing forces you to use generics, you can pass traits by pointer and avoid the code generation. It's actually a really nice property that lets you determine static vs dynamic dispatch independent of implementation
WRT Exceptions, this has been widely debated. I personally prefer error codes. I hate unchecked exceptions, ruins the whole idea.
Also I'm not a huge fan of OOP hierarchies. They tend lean more towards Is-A vs Has-A when the latter is more common across the domains I've worked in.
You need generics to have the borrow checker that you praise above. Otherwise references would be basically crippled.
> The template libraries are heavily biased towards closure-oriented functional programming.
No, they aren't. I use for loops all the time in Rust, and it's totally natural to do so. My general guideline in my own code (which is followed in projects like WebRender and Servo layout) is that if it's one line, I use the functional idiom; if it's more than one line, I use a for loop.
> Parts of expressions are nameless and have no visible type. This is terse but hard to maintain.
Are you thinking of unboxed closures here? If so, they're necessary to avoid unnecessary heap allocations in normal code. If we didn't have that, then we couldn't compete with C++11 closures.
> - The hacks needed to avoid the need for exceptions are uglier than exceptions.
Unwinding is the single most divisive issue in Rust. We would alienate most of our community (I'm not kidding) if libraries required it. For a time, there was a language fork over the issue until it was resolved.
> Unlike the borrow checker, none of these things are clearly improvements. They're just different.
No, they're needed for the borrow checker and most of the other features to work.
> I would have gone for Python-type exceptions rather than error enums and macros
Then, as above, you instantly alienate all embedded developers.
> single-inheritance OOP rather than traits
This doesn't work in practice unless you introduce interfaces: it's way too inexpressive. This is why Java and C# have interfaces. Traits are just interfaces.
> Python-type with clauses rather than RAII.
You want to force an extra layer of indentation for every Box or Vec you create, and leak memory if you forget to write "with"? No thank you!
No, no, Python like with clauses, for opening files and such.
Presumably a data type that contains a "with resource" would itself have to be a "with resource" (or else why bother?). This makes "with"-ness abstraction-piercing and infectious, so, for backwards-compatibility, if there was any chance of a type eventually containing a "with resource", the programmer would have to mark the type as such a resource preemptively, or else be forced to make a breaking change to their library. All for a minor syntactic difference in how one constructs values.
Also, how does one return values from `with` clauses? It's useful to be able to write a function that returns a file, so one would need yet more machinery, just to be able to cancel the normal with-cleanup. Again, all for a relatively minor syntactic distinction.
On languages that support currying, or leaving the last parameter out of the call if it is a lambda, you can create high-order-functions for resource management.
The effort is no different than implementing RAII classes.
withDBConnection {
r = db.execute ("SELECT....")
}
There are more fancy ways to improve on this, specially if the language also allows for macros.
So I find a bit sad, that the discussions of with/using/try don't focus on the FP way of doing resource management.
The resources are only available via the lambda parameters, so the wrapper function controls the lifetime, arena style.
Last expression in the block is the return value.
It all comes down to: how do you write a fn connection() -> DB? You can't (or, at least, it doesn't make sense to) return the parameter from withDBConnection: the whole point is the wrapper function does the clean-up when it is done, invalidating the connection object. The only way to pass the value along is to have `connection` also take a closure, i.e. manual continuation passing style/node.js's "closure-hell". This can, in some cases, be addressed with async/await style sugar, but there's still semantic (mainly around composition) and performance issues with it.
Anyways, going back to the data type: if one has a type Foo with a constructor like fn create() -> Foo, and Foo is updated to contain a database connection, that constructor no longer works, and needs to also be converted to use CPS. That is, the interface of the Foo object has be infected by "private" details, meaning needs to to preemptively decide whether there is any chance of each datatype needing to hold one of these CPS objects.
(Of course, the code you suggest works fine in Rust now, and is even used for certain special cases, but that is very different to baking it into the language as a whole new syntactic construct.)
> No, they aren't.
I think that came off more combative than you meant it to :)
>> Parts of expressions are nameless and have no visible type.
>Are you thinking of unboxed closures here?
I think Animats is complaining about the functional style in general, which is at least more common in Rust than in C++ or Python. And if that's right, it's a complaint I mostly agree with. Functional programming can cram quite a bit into one line, and that's all well and good, but a lot of the savings comes from omitting the variable names that are usually there in imperative code, and some clarity gets lost when you don't name things.
I agree with your rule of thumb. Functional stuff is great when what it's doing is obvious.
Are you talking about point-free style? Point-free style is rare in Rust, partially by convention, partially due to the fact that references and values are different and often you need to wrap in a closure to convert one to the other.
I felt like this when I read the scary documentation: https://doc.rust-lang.org/book/error-handling.html
However, in the total 4 hours or so that I have been programming in rust the way of handling errors seems very sensible.
- Match expressions instead of "if (error) dosomething()"
- Match expressions with destructuring gives the error message.
- Match expressions are exhaustive which forces errors to be checked.
Its simple and elegant. I think the documentation is a little overwhelming when it comes to error checking and introduces non-essential craziness without warning.
Like what? (Disclaimer: I originally wrote that chapter as a blog post[1], so I'm curious to hear what I could have cut out. I tried to find things to cut, but given my target audience, I couldn't find anything substantial.)
Here would be my suggestions, I hope they are useful:
1. Its about error handling. Options are conceptually similar but they're not error handling. Options can go somewhere else, maybe a previous chapter.
2. From what I understand from my almost zero experience of rust, the match/deconstruct with a Result type will do 99% of error handling -- even though it might be verbose or ugly to some. Its also the basis for the combinators. This can be the short and simple error handling chapter.
3. The combinators are nice constructs to make code more linear looking and are convenient when working with the std library. If they are stated as an optional convenience then they become less scary. Error handling is so fundamental that I should not have to learn about combinators to do it.
What I suggest is a rearrangement of the material. The documentation itself is clear -- its just too much.
With that said, in a book, I totally agree that the chapter could be broken up into more manageable pieces. But I do think all of the content there is essential for understanding how to do error handling in Rust. I feel pretty safe in saying that I use all of those concepts in most crates I've published.
Thank you for replying by the way. I'll continue to noodle on your thoughts and see if there's a happy place between us. (I kind of suspect that happy place is the new book, with content delivered in more manageable chunks. Alas, my blog is not book. :P)
Hence the reason I said that it abstracts control flow.
> It's only useful if the appropriate error action is to immediately bail out of the function.
Which is exceptionally common.
> It implies that your program should be structured as functions which either succeed or fail, and that you don't need to log or display errors where they occur.
None of this is true, and I do log errors when they occur in Rust programs. (See ripgrep.)
`try!` is a convenience. Since errors are plain old values like anything else, you don't actually need to use it if it doesn't fit.
[1] - http://rust-lang.github.io/book/ch09-00-error-handling.html
If you don't put in exceptions, you seem to end up re-inventing "longjmp".
Their purpose is to recover from panics when embedding Rust in code written in other languages, where you don't want the panic to try and cross the ffi boundary (or to stop applications that should never crash from crashing at the toplevel, or for better reporting before a crash). Many FFI-based applications turn panics into aborts anyway. Firefox does.
The unwind-recovery functionality in Rust is just enough to get you these useful features if you need them (zero cost if you don't; turn them into aborts), without needing a full on exception system. The reason Rust avoids an exception system isn't the cost of unwinding, it's because it considers exceptions to be an inferior pattern compared to return value based / monadic error handling.
Rust doesn't have a mailing list anymore. I haven't seen much annoyance with panic recovery. There used to be some with panics in general because in the past they couldn't be turned off or recovered from without a new thread, but this has been addressed for ages with panic=abort and recovery. What the hell are you talking about?
Personally, I find error enums with macros, traits over traditional OOP and RAII to be strictly positive features, and all three are among the (quite numerous) reasons that I love Rust
This is the worst side of this place.
Rust usage is very low. It isn't even in the TIOBE Top 20 for 2016.[1] (In the detailed listings, it's at position 46, just above Awk.) Why is market penetration so low? I'm arguing that there's too much gratuitous new stuff for Rust to be acceptable to the C/C++ community.
I think that the simple fact is that ownership, lifetimes, and borrowing are unfamiliar. They have a learning curve, period. We can't expect a language with them to take over the world in a year. Programming languages are a mature market. Progress will be slow.
Rust is doing far better than 95% of new programming languages after a year. Most programming languages are dead after a year.
That's not a decision you make. That's a decision your customers make. Time will tell.
FWIW, I think a few explainer pieces would help bring about more enlightened discussions. For example, there is a lot of bikeshedding around Rusts' decision to wrap overflows and potential future improvements. But the rationale and interesting technical challenges each alternative brings is scattered across blog posts, forum threads, and Github issue tickets.
1: http://huonw.github.io/blog/2016/04/myths-and-legends-about-...
If you are; sorry you weren't included in the survey. I don't think everyone on the friends page was included, it was more of "everyone we know who uses Rust and we have an easy way of contacting over email"
I think it would also be useful to survey people who looked into using Rust but decided against using it, as responses from people who suffered through the warts is analogous to looking at the damage to bombers that made it back to base. Still relevant, but not the whole picture.
I'd expect to see mobile/cross-compilation (which I know is getting better) to rank pretty high among people who didn't stick with it, but maybe I'm projecting.
I cannot wait. I cannot wait until this happens. Rust will become my main language.
Moreover, moving to Rust would require investing in ports of some large-ish C++ libraries we use.
I think Rust is here to stay. It's a great language without a runtime that should be able to match C++ in performance when the compiler frontends catch up.
We'll start using it in some new projects but I doubt we'll port critical infrastructure for a few years.
Eclipse has by far the best autocompletion for Java.
PyCharm has the best debugger I've ever used or could dream of.
While by no means a perfect language, I enjoy it much more than writing C++.
Also rust has some more modern functionalish constructs like lambadas and pattern matching.
For those times when you have to use C++, SaferCPlusPlus[1] should help.
[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus
If the answer is code review, it will never work.
But in other circumstances, another valuable feature would be to be able to make your co-workers' (and predecessors') existing code retroactively safer. The easiest way to do that is probably by enabling the llvm/gcc sanitizers when compiling. But unfortunately that is often not a practical solution for several reasons[1], not least of which is the performance penalty.
So the more practical solution may be to use SaferCPlusPlus to replace (in a straight-forward but not quite automated manner) all the potentially dangerous C/C++ data types (pointers, arrays, etc.) with safe, fast compatible direct substitutes. Thereby salvaging existing code bases.
Wrt preventing the use of C/C++'s unsafe data types in new code, currently SaferCPlusPlus does not provide any mechanism for such enforcement. But you could imagine the effort required to implement such an enforcement mechanism might be small compared to rewriting some large code bases in, say, Rust. And in the mean time, even existing C++ static analyzers seem to be getting better at flagging potentially unsafe code.
[1] http://duneroadrunner.github.io/SaferCPlusPlus/#safercpluspl...
The majority of C++ programmers I meet at enterprise projects don't even know what is CppCon.
I specifically like the immutable-by-default, borrow, and move semantics. I can write safe code without bloating up my source with 'const &', std::move, '&& ...' and the like.
The safety issue for me is about the least important thing. Touting it as the big reason to use Rust is a distraction from my point of view.
For real. Rust is a great language, but for the love of god, all you hear is safety safety safety. I give about 2 out of 10 fs about safety. The worst part of C++? Dependency management. Cargo is sick -- hype that up more!
The worst part is people using it as if it was C with a C++ compiler.
I lost count the amount of times I had to create a nice C++ wrapper for "C++" libraries that are just a pile of C functions and data structures, due to copy-paste compatibility.
And yes, the respective lack of safety by not making use of C++ improved type system and standard library.
I don't know about 'main goal' but rust is fun to write. Far more than c++ for me.
Compile times. Traits. Generics that aren't templates. A package manager. Functional constructs. Cross platform. It's got all the shiny toys.
The state of the art in C++ is what? One file drop in headers, no package management and STL hell? Have you read the UE4 engine code base? What are horrific mess.
There are certainly problems with rust (imo tooling and libraries), but I don't think for a moment how enjoyable to write it is, is one of them...
C++ is a bloated language and I hate writing code in it. I hate that the mix of C++14/11/?? You get is different is every project. I despise that my C++ code from QT, UE, win32 is virtually incompatible, and the header/code legacy divide (or not if you happen to be in a system that allows it).
I guess your milage may vary, but I've not talked to many people who didn't like programming in rust... Mostly just people who found it hard, or didn't know why they would bother vs. their current 'good enough' language (eg. C#).
I bet you if UE5 would get rewritten in Rust, it would just look as messy.
(I just finished implementing a parallel recursive directory iterator that respects gitignore files. No unsafe. No data races. No mutexes. Blazing fast. So I'm particularly over the moon at the moment. :P)
When will Rust get
1. function head patterns like other languages in the ML family, although Rust isn't really part of the family, but rather a distant cousin from another continent, which once played with ML and family during a summer vacation
2. support for naturally writing recursive functions
Regarding semantics, without having thought about the Rust semantics too much, I'd suggest to check out the most prominent uses for recursive functions in OCaml, SML or Haskell, then try to consider that as the sweet spot to support in Rust.
It's actually more of a sibling in the family who ran away from home at the age of 6 and fell in with the crowd on the wrong side of the tracks.
Initially Rust was very much like ocaml. It isn't anymore :) Many of the normally-in-functional-languages features in Rust come from these days. Others were lost and re-added later. It's a very complex history.
> function head patterns like other languages in the ML family
could you elaborate? I'm not familiar with this feature (only have dabbled in sml).
> support for naturally writing recursive functions
yeah, I wish we had TCO.
> Initially Rust was very much like ocaml. It isn't anymore :) Many of the normally-in-functional-languages features in Rust come from these days. Others were lost and re-added later. It's a very complex history.
Yeah, having tried Rust in those days, I kinda stopped when it broke every week, and was then surprised with the surface of 1.0. It seemed like a different person to talk to.
I've made my peace with the C'ification of Rust as the price to pay for attracting a large crowd of developers who grew up with C, C++, C#, Java, JavaScript, Ruby, Python, the list goes on. It's a reasonable sacrifice to make, but the two mentioned basic features aren't complex things to wish for.
> could you elaborate? I'm not familiar with this feature (only have dabbled in sml).
Imagine being able to hoist your match clauses into function head (signature?).
oldEnoughToDrink :: Int -> Boolean
oldEnoughToDrink 21 -> True
oldEnoughToDrink _ -> False
OldEnough = fun(21) -> true;
(_) -> false
end,
I don't think Rust will get support for that. You can simulate it with macros (and, later, syntax extensions). Of course, that isn't as clean as pure language support. I know why it makes recursion (esp tail recursion) easier to use though. You could always bring it up on the forums and try though.
Say you have a function that should will tell you a file extension is likely to be that of a text file:
isTxt("txt") -> true;
isTxt("org") -> true;
isTxt(_) -> false.
If Rust is planned to get HKT, then I don't see why I cannot get pattern matching in function heads when there's also guards as found in ML languages.
Oh, I know that it's useful; I've used it in Haskell often. And the `fn foo (x) { match x {}}` pattern isn't uncommon in Rust.
> If Rust is planned to get HKT then I don't see why I cannot get pattern matching in function heads when there's also guards as found in ML languages.
The HKT proposal logically extends existing associated types syntax so that you effectively have HKT. It's particularly elegant in that it's something folks (who are unaware of what HKT is) on learning about associated types expect associated types to support. I've had folks ask countless times as to why you can't `type Foo<T>` in an associated type.
It also opens up access to patterns that weren't possible in the past.
OTOH function heads would just be sugar for fn + match. It doesn't open up new possibilities, it just makes some patterns easier to type. And frankly, with blocks being expressions, it's not much easier to type. You have to provide the function signature somehow, and it's there. The match arms are also there in both the Rust and haskell versions. The only thing exclusive to the Rust version is that you need to explicitly say `match`. Meh.
Languages have a "complexity budget" -- spend too much of it and folks won't learn your language because it's too complex. Rust has spent a lot of it on the borrow checker. Adding random bits of syntax spends this budget, and you need a compelling reason to do so. This is why I'm quite fond of the current HKT proposal -- I'd always thought HKT in Rust was pie-in-the-sky, but the current proposal ends up with a very unsurprising and natural-looking syntax (and doesn't feel "new"), which makes me think that it has a good chance of succeeding.
If you can come up with a good proposal for function heads, who knows, it might happen! But it will have to be good; I don't think just proposing function heads without tons of justification and/or a syntax that fits in naturally will work.
For a “systems programming language”, Rust doesn’t let you do anything i’d expect, like let you specify whether a signed integer is 2s compliment, and how it behaves when it wraps. Instead the programmer is at the whim of the compiler writer, same as in C, and its “undefined behaviour” which is a source of real, hard to track bugs. Rust doesn’t even have support for modern features like wide registers, or any features that help you deal with raw memory, it just marks it as “unsafe”. There aren’t even any basic meta programming features like struct introspection.
What problems does Rust actually solve that C and its copycats have been suffering from since the 70s.
A quick analysis I did showed that half of the critical security vulnerabilities in Gecko would have been prevented by writing content and layout code in Rust. The other half were mostly JS issues, often having to do with built-in APIs that would also be safe if appropriately written in Rust (or self-hosted).
> For a “systems programming language”, Rust doesn’t let you do anything i’d expect, like let you specify whether a signed integer is 2s compliment, and how it behaves when it wraps.
Well, this definition of a systems programming language excludes C.
> Instead the programmer is at the whim of the compiler writer, same as in C, and its “undefined behaviour” which is a source of real, hard to track bugs.
Nope. Rust defines signed overflow. http://huonw.github.io/blog/2016/04/myths-and-legends-about-...
> Rust doesn’t even have support for modern features like wide registers
What is a "wide register"? Do you mean SIMD? If so, it sure does [1].
> or any features that help you deal with raw memory, it just marks it as “unsafe”.
Sure it does. Rust helps you deal with raw memory by freeing you from the need to deal with raw memory in the vast majority of occasions. For example, in C you have to mess around with char pointers to operate on strings. In Rust you don't.
> There aren’t even any basic meta programming features like struct introspection.
That's what custom derive is for.
Though, still wide registers aren’t a language feature. I don’t care, nor do i think any other seasoned programmer does, about the language “freeing me from the need to deal with raw memory”. It doesn’t. The types of problems you solve by introducing built-in string types and vectors aren’t problems in the first place. The problem is writing custom allocators for the data you have, and needing some basic bounds checking. Problem is working with structures of arrays instead of arrays of structures, because that can get messy and introduce basic typing bugs. I’d love to see any modern programming language at least make an attempt at making working with raw memory easier.
I do. Am I a bad programmer?
> The types of problems you solve by introducing built-in string types and vectors aren’t problems in the first place.
Buffer overflows aren't problems?
What i’d want is a generic support for preventing buffer overflows, or bad memory access where i need it. Writing my own growable data type using malloc and free is something i can do once, and i just have it, it’s not something that i have to worry about for more than 5 minutes at the beginning of a project.
You have that.
For example, if you have contiguous memory, the various forms of the [T] slice type can be used, they don't impose any allocation expectations. (And, once the standard library allows pluggable allocators, you'll likely be able to use Vec directly, for a growable vector type.)
If you don't have contiguous memory, then it's a bit more work, but one can still use features like generics and privacy to spend a few lines building abstractions that bounds check in the right places. It's not like using a proof language to extract a program that is guaranteed to have no out of bounds accesses, or a compiler that some how deduces what the bounds of your data structure is, but the former has its own complexity downsides, and the latter seems infeasible, in general.
Generics and privacy are definitely language features, and they're core to the ease with which one can create abstractions. Rust is a systems language, it tries to give programmers the power to create their own safe abstractions as needed.
> though i don't see how that differs from a generic accessor method or an overloaded operator
Err, it does all the bounds checking automatically? I thought you wanted these features without having to implement them yourself, but apparently writing accessor methods or an overloaded operator is OK too?!?
We actually used to implement Vec as a language feature, and it was a lot of work to write things like growth in raw LLVM IR (which is a miserable programming language) instead of just using a real programming language—Rust—to do it.
Rust is all about memory safety. The borrow checker gives you compile-time memory safety guarantees (sans unsafe blocks). The address of the struct you passed to some function which then took the address of an inner field and populated a value in a returned object? Yeah... Rust knows whether that's safe or you've set yourself up for a dangling pointer. Bounds-checking is child's play to Rust.
The bulk (if not the majority) of high-impact security vulnerabilities are related to memory safety in some form. Rust eliminates those as an entire class of problem.
- Haskell doesn't eliminate memory safety issues, they happen when using unsafePerformIO (or Foreign.*Ptr, or inside the runtime, your choice),
- Python doesn't eliminate memory safety issues, they happen when using ctypes,
- JavaScript doesn't eliminate memory safety issues, they happen when calling into the C++ code of the browser,
- Java doesn't eliminate memory safety issues, they happen when using JNI.
All languages have some sort of escape hatch that can be used to drop to a lower level, in order to actually interface with the operating system (etc.), Rust is slightly unique in that it makes this escape hatch fairly explicit/prominent at the language level and also provides the power needed do that interfacing/implementation itself (additionally, one gets all the normal benefits of Rust inside `unsafe`, the feature just lets one do more, not change the semantics of existing code).
It works really well in practice, even if it isn't bulletproof... there's nothing to stop a programmer typing 'unsafe' to side-step the safe interfaces in random places, but one quickly learns this is usually just heaping unnecessary debugger work on oneself, to track down little mistakes that the compiler would normally point to directly.
Const is nothing like references, not even close. I would suggest you spend a bit more time with the language to better understand exactly what Rust brings to the table.
I never said that const is like anything, i just used it as an example.
Also, sure the implementation of another allocator might use a smattering of `unsafe`, but I'm guess that it will be less than you probably expect: one of Rust's biggest is strengths is the ability to build safe interfaces for things without performance cost. One can see an example for this in http://os.phil-opp.com/ where the author is slowly describing creating an operating system, all while concentrating on how to exploit Rust features to let the compiler help the programmer, such as http://os.phil-opp.com/modifying-page-tables.html .
In fact, "how to to either of these things" is such a common question for new rust programmers trying to solve their borrow checker complaints that it constitutes pretty good evidence people are doing these things all the time with little understanding of why they are problematic.
And even if you _do_ know better, circumventing the borrow checker is fairly trivial.
How's returning a pointer to stack ever safe?
To begin with, "safety" isn't solved by just using const. It simply isn't feasible to write safe code in C without restricted feature usage to the point of being crippled. It's much easier in C++, but requires an incredible level of focus and "cruft constructs" like ' 'const &' and such. Arguably until move semantics were standardized with C++11 it was a challenge to write safe code.
I will agree that Rust's developers have perhaps come down too far on the side of "YOU ARE DOING SOMETHING DANGEROUS BY USING A POINTER." But I think you're exaggerating a bit about how hard it is.
"It" doesn't do anything. But some of its fans conflate "prevents memory safety bugs" with "panacea", at least by implication, as I perceive it.
Besides, right now a lot of the "memory safety" of Rust has much more to do with selection bias (it is used primarily by people who are explicitly interested in using its safety features). When one uses exclusively (or almost exclusively) the "memory safe" features of the language, of course things implemented in it will be free of "memory safety" bugs. Rust helps make doing unsafe things explicit. It doesn't prevent one from doing unsafe things.
Here's how I see Rust: it's far and away already superior than C++ for a certain class of systems application programming (e.g. performant desktop/native application code that sits at the systems boundary). Rust code that seriously competes with C or C++ for "low level" systems programming is going to have to make use of plenty of Rust's "unsafe" constructs. If it gains traction "in the wild," my prediction is we'll start seeing plenty of "memory safety" bugs in that area. The question then is how easily they're spotted and rectified.
While you may be right, I have never seen this happening (and I participate a lot in online discussions about Rust); people seem to be very careful about saying that Rust prevents memory safety bugs, not bugs in general. People do say that the type system _helps_ prevent general bugs, but that's only to the extent that any similar or more powerful type system (Haskell, xML, etc) can.
> Rust helps make doing unsafe things explicit. It doesn't prevent one from doing unsafe things.
I mean, yeah. No language can (unless it avoids FFI entirely). See https://news.ycombinator.com/item?id=12877136
Rust gives you the tools to prevent yourself from doing unsafe things (and still be able to write software).
You can get a lot of stuff done in safe Rust. When you need to drop down to unsafe Rust, you can design safe abstractions around the unsafe code, and manually verify the safety of the abstraction. This has a human component, so it's not perfect, but it's pretty close :)
The unsafe feature isn't just there for explicitness, it is designed to provide the ability to do this -- the ability to design safe abstractions.
> for "low level" systems programming is going to have to make use of plenty of Rust's "unsafe" constructs.
Designing an operating system low level enough? There are a bunch of initiatives to write an OS (both serious and as a learning project) in Rust. As far as I've seen, all of them avoid unsafe code like the plague and design safe abstractions around everything so that they only need a smattering of unsafe code. os.phil-opp.com has a bunch of blog posts on OS design in Rust, some of which explicitly demonstrate this pattern (e.g. the page table one).
When you say "When one uses exclusively (or almost exclusively) the "memory safe" features of the language", you're talking about basically the entire target audience of Rust, and this includes low level users. Rust isn't supposed to be used with lots of unsafe everywhere; and folks have tried hard to make it so that this isn't necessary even for low level applications (the Zinc project, while no longer maintained, is an example of this for embedded software). Of course there are areas where you'll be using more unsafe code than others, but you're still supposed to be "almost exclusively" using safe Rust code. If you need unsafe everywhere for your low level application then that's something you should bring up with the Rust community. (To be clear, the Rust ecosystem and language right now has some issues that crop up in low level development, but these are being worked on)
In fact, there is only one place where I've seen unsafe code being sprinkled around liberally, and that's when binding to a C/++ library. Currently my job involves a lot of this, and I'm trying to make it safer (largely succeeding!), but it's still has a higher density of unsafe code than, say, Phil's Rust OS (or I think Redox, but I haven't looked at that in a while). In this case, though, you're already talking to C/++ and there's inherent unsafety there (plus an impedance mismatch), so you can't always blame Rust for it :)
------
I guess you're right that "Rust prevents memory safety issues" isn't 100% accurate because `unsafe` exists. "Rust gives you the tools to prevent memory safety issues" might be more accurate, but still misses nuance. I think for a soundbyte on Rust it's accurate enough to say (because it prevents these issues more or less as much as possible without being useless for writing software), but it's a caveat that we should probably mention more.
I'm curious how either approach will work out in the long run. I understand why Rust made the decisions it did wrt ditching built-in GC/non-GC support but it will definitely hamper its adoption for writing GUI applications. If Swift manages to thread the needle in supporting systems-level / kernel programming with borrow-checked types while not imposing that mental and maintenance cost on GUI apps it will be an amazing thing.
In any case it is exciting to see high-level languages with memory safety proving you can have something much better than C without going full-on virtual machine, runtime, and JIT.
Check Modula-2, Oberon, Component Pascal, Modula-3, Eiffel, Ada, Delphi...
It was a mistake to have Java and .NET go JIT only on their first days, instead of AOT/JIT from day one.
They are finally steering the boat in the right direction, but it will take a couple of years, assuming they don't loose focus.
Can regex libraries written in C say the same? I don't think so.[1]
[1] - https://www.cvedetails.com/vulnerability-list/vendor_id-3265...