We've been really happy with Rust. Our Rust programs tend to be fast and resource efficient, and they tend to have few bugs (and most of those are cases of misunderstanding the problem or the spec).
The learning curve tends to be pretty rough for the first week or two, but you can reduce that by pairing with a more experienced Rust developer. And after that, it's pretty smooth sailing. Certainly any C++ programmer should be able to make the leap fairly quickly--it helps to have used at least one non-GCed language.
The third party library situation is better than you might think for a young language (the database clients, RabbitMQ clients, HTTP clients, compression, etc., are all basically usable), but I normally expect to fill one or two library gaps per project.
Overall, I find it difficult to articulate why I like Rust. It's pleasant to write (now that I know how), it runs fast, the CLI tools are pretty solid, and has enough abstractions to keep the boilerplate in check. And I can throw cluster-sized workloads at it and trust it to work, and work fast.
I think at some point, Rust will have enough tooling that people will try to start using it for graphics and videogames -- the applications where C and C++ shine but their "safer" rivals Fortran and Ada can be a headache to work with. It's in this arena -- where Go is too slow -- that Rust will really sink or swim. And it has barely even started to make headway. Maybe GNOME 5 will be written in Rust, or maybe the GNOME 5 developers will try Rust and conclude it's not suitable. Whoever they are, they haven't even started yet.
The game developer community is actually one of the communities that jumped onto Rust really early, well before it hit 1.0.
* Destiny's Multithreaded Rendering Architecture: https://www.youtube.com/watch?v=0nTDFLMLX9k
* Multithreading the Entire Destiny Engine: https://www.youtube.com/watch?v=v2Q_zHG3vqg
The problem (speaking as someone working on a console game at a AAA studio) is more likely that it's not officially supported. Console SDKs include C++ toolchains and C++ libraries, and there's a lot to lose by trying to bypass that, especially on a game project schedule.
The support thing makes total sense. Do you think it's fundamentally insurmountable? I'm pretty sure this is an area where the team itself has a blind spot, or maybe rather, just doesn't have the necessary expertise to even know what we'd need to do to make this possible.
A move away from C++ would probably be significantly higher-effort than the move to it- C++ can not only trivially call C APIs but can also compile most C code without modification. To support Rust would require not only porting the toolchain (though this wouldn't be too bad on current-gen, since e.g. the PS4 even uses Clang), but really working well with the console SDKs, and third-party libraries and middleware, which are all written in C++.
It would probably also be a much tougher mindshare hill to climb- even C++ took a long time to be accepted, and its standard library still isn't. Vulnerabilities are not really an issue for games the way they are for, say, browsers, since games' inputs and environments are so constrained and there's often no real consequences worse than a player losing their save file.
So from my perspective (which to be fair is relatively new to the industry) these might be the most important features for getting Rust into games:
* Visual Studio integration, including code completion and debugging. Though console support would have to come from the console vendor, anyone could work on supporting things like variable name hovering and data display.
* C++ support- though maybe different from what application developers need. DirectX (Windows/Xbox One) is all COM-based, which is strongly related. If it's handled through bindgen, it still needs code completion support.
* SIMD, inline assembly, etc. This stuff gets used all the time for performance, and for a lot of it portability is not a concern, because things are handled differently per-platform anyway.
Similarly, Rust might just not be a good fit for games because of some tradeoffs it makes:
* Games can't get by with just malloc-style memory management- and while it's easy to mess up, C and C++ handle arenas/pools/etc with far less friction than Rust, where you'd want to package up every little pointer thing behind a safe API. That's a good tradeoff here because the bugs are mostly harmless and easy to track given the constrained environment.
* Maybe error handling? (Mostly devil's advocate at this point.) The games I've worked on tend to just assert in debug mode and ignore errors in production. Carefully handling every case could legitimately be a needless time sink for some situations. On the other hand stuff like `unwrap_or` could make that much clearer without slowing anyone down.
* I don't agree with all of tomaka's points (e.g. https://www.reddit.com/r/rust/comments/616rc8/rcpp_discusses...) but they would certainly be an issue for many game developers.
I don't see why this isn't fixable? It's just a lack of library support AFAICT.
>* Maybe error handling? (Mostly devil's advocate at this point.) The games I've worked on tend to just assert in debug mode and ignore errors in production. Carefully handling every case could legitimately be a needless time sink for some situations. On the other hand stuff like `unwrap_or` could make that much clearer without slowing anyone down.
I don't know much about this in C++ but I know that error handling in Go is at least as bad. Rust's fancy type system should in theory make error handling easier if you use it correctly (that's supposed to be an advantage of type systems after all) but it requires not just understanding how the type system can be used for error correction but a way of integrating that knowledge into development methodologies. This has to be developed by the teams themselves although it also forms a part of the collective knowledge base of the programming community (most of us are familiar with unit tests in imperative languages at this point).
>* I don't agree with all of tomaka's points (e.g. https://www.reddit.com/r/rust/comments/616rc8/rcpp_discusses...) but they would certainly be an issue for many game developers.
Just guessing:
>The biggest is probably the fact that it's impossible to safely put a borrowee and a borrower in the same struct. This has very deep consequences on API design.
You should probably use `unsafe` for this. As noted, you're flying blind if you do this in C++ as well. It's possible that some partial solutions will be implemented but I doubt that the project will cover every possible use case. The reason that this isn't in safe Rust is that it's very hard to reason about when this is and isn't safe. An issue is that people have difficulty reasoning about the behavior of unsafe Rust because of its unfamiliar semantics.
>No decltype is really a deal breaker as well. The core team has recently added the -> impl Trait syntax because iterators and futures were too annoying to deal with. I'm manipulating types that are ten times worse than iterators, and I have to put them in my structs.
Holy pretty printer Batman! Let me see:
>When you write struct Foo<T: Trait> it's the user of the struct that choose what T is. In my code I have a very precise type that I want to put in the struct, I just can't express it in the source code because it's too long. I don't want the user to choose this type for me, this is totally difference.
I think this could be fixed in exactly the way that tomaka wants it to be fixed, by allowing type aliasing which is limited to a particular lexical scope. Since this is basically equivalent to creating a trait which is only implemented by a single type (which he could in theory do but it's very awkward) it shouldn't introduce any new complexity to the type system.
Tomaka's other points are being fixed. Rust is a very large undertaking...
Libraries could help, but game often have a lot of one-off memory stuff too that you can't put in a library and you can't do in safe Rust. Maybe there are some more creative solutions that nobody's had to come up with yet because C makes it so frictionless.
> error handling in Go is at least as bad
The thing is that style lets you ignore errors in cases where the error isn't gonna happen. That's usually bad, but in games it's often fine because you control everything. The equivalent in Rust requires an `unwrap` of some kind which introduces performance and syntactic overhead.
I guess all I'm getting at is that beyond the implementation, there is still design work to be done if we want Rust to work well for games.
The contradiction in your logic here is that if you don't want to handle errors, then don't design your functions to return errors. In addition, many of the larger time game studios write and use their own standard library, so they could devise an efficient 'game stdlib' where they don't have to pay such costs.
> Memory safety is not a problem in game development, they will just patch the bugs.
You must not have played any Bethesda titles. That said, there is much more to Rust than memory safety. That's just a side effect of the safe parallelism -- it's a minor story.
Did you ever seen AAA game source code?
> You must not have played any Bethesda titles.
I've played. Most bugs I've seen were logic errors, doesn't matter which language you would pick.
I (and I presume many others) would appreciate it if you would stop making grand, unfounded assertions about what Rust is good for. Games do make very different tradeoffs from most software- type and memory safety aren't an obvious, uncontested win there.
> stop making grand, unfounded assertions about what Rust is good for
You are basically stating that everything that I have done in Rust is a lie. I will not stand for that.
Nobody here, least of all me, has claimed that Rust cannot be used for any game at all, nor have they disputed your own experiences. Grow up.
> I would love to use Rust in games (I currently work in games) but it's not clear that it would work out.
There are many contradictions in your posts on here.
The borrow checker was brilliant. Any future language that doesn't use garbage collection will have to have one. That was the big advance in Rust.
But the object system (yeah, they're called structures and traits) is too weird. The enum approach to variant records is too weird. The error handling is too weird. The half-functional style is too weird. The widespread use of closures for simple stuff is too weird. There's too much unnecessary originality. Trying to port something from another language to Rust is difficult because Rust's ways of doing things are so different from other languages.
I have the feeling that Rust is destined for a niche like Haskell - cool, but not mainstream. That's sad. I really thought early on that Rust meant the end of the decades of hell from the lack of memory safety in C and C++. But that's not happening.
The Go crowd knew when to stop. The Rust crowd didn't.
If you don't like Rust, that's A-OK. If you can't quite put your finger on why you don't like Rust, that's fine too. But please don't pass off your vague concerns as substantive criticism.
Sure, you've got to know about Option and Result to do anything with Rust, but you've got to know about exceptions and null pointers in the rest of those languages. But you can write coherent Rust using for loops everywhere instead of stupid closure tricks.
Rust is productive, efficient and a joy to use. For things we required C/C++ before, we will be using Rust now.
It's equivalent to writing C++ with:
* No structural inheritance (i.e. no inheritance of data)
* Inheritance only from pure virtual interface classes
* MyCppPureVirtualClass * pointers in various interfaces
This isn't the most common style of C++, but it's not uncommon either, and I happen to like it a lot; it's all over Cef's and Chromium's code, for example.
> The enum approach to variant records is too weird.
What's weird about it? It's just the same as e.g. Haskell, ML, but with a different (arguably slightly overloaded) keyword. Swift uses the same terminology.
> The error handling is too weird.
Eh. I certainly like the way that explicit error handling is "forced" on the caller with mechanisms like Result<T,E>::unwrap. But I agree that magical things like the question mark operator are a little too cute.
> There's too much unnecessary originality.
FWIW, I can't think of much real originality in Rust. It just brings together "exotic" features from lesser-known languages.
I think you're right. Except for the borrow checker, which was a major breakthrough.
Edit: As an aside, I found a Reddit post the other day asserting that the Cyclone developers knew that it would never become mainstream but thought it was important because other languages would adopt it's ideas. It's amazing that they predicted that regions would be picked up later on by Rust.
You can find it here: https://twitter.com/tmccrmck/status/850465514807631872
1: http://www.vala-project.org/doc/vala/Overview.html#Memory_ma...
Vala's wiki has a page all about its ownership mechanism: https://wiki.gnome.org/Projects/Vala/Ownership
Thanks for the link, I'll dig in!
Yes, Apple's weight helped Swift tremendously. But people are switching from Obj-C to Swift because they think it's better, not because Apple's making them.
> How much of Swift is written out of Apple ecosystem? Not much.
Not much yet, because the Linux support is still missing a lot, but it's being filled in quickly, and a lot of people seem to be excited about being able to start using Swift on Linux.
So you praise Go for having structures and interfaces, but you criticize Rust for having structures and interfaces because that's "too weird".
> The enum approach to variant records is too weird.
Why? Because of the keyword? Swift uses that keyword too!
> The error handling is too weird.
What would you rather see?
> The half-functional style is too weird.
I can't think of any way that Rust differs in this regard from, say, Ruby. Or JavaScript.
> The widespread use of closures for simple stuff is too weird.
Again, it doesn't differ from Ruby. (Actually, Rust uses closures/blocks quite a bit less than Ruby does, because of the pull-style iterators...)
> There's too much unnecessary originality.
Such as? None of the features you've mentioned are at all original.
>What would you rather see? Exceptions
If exceptions are just "an option" that a library can choose when designing its interface, then you'll get a split ecosystem: a bunch of libraries that do use exceptions for error-handling, and then a separate bunch of libraries that do the same thing, but don't use exceptions for error handling, which is wasted, redundant effort.
Agreed. Point in case: Have a look at D and the discussions about their GC.
I haven't kept up much about the last year, but my general impression runs down to: If you want to use their standard library. There's gonna be garbage collection. Period. If you want to avoid it, enjoy implementing its functionality all by yourself.
With rust and exceptions you would likely not have a problem with the main ecosystem, but the same problem is bound to pop up with some big & famous library.
Edit: Similarly, exceptions are one of the reasons C++'s SG14 exists.
Go also backed into adding most of the machinery for exceptions by adding catch with unwind for panics. If you're going to have the unwinding machinery, why not have real exceptions?
Exceptions aren't so bad if you do them the way Python does, using a predefined exception hierarchy. Catching an exception catches everything in its subtree. Catching RuntimeError catches most of the things one can induce from outside the program. Python's WITH statement also has one of the few mechanisms which can gracefully handle an error on releasing a resource. Exceptions in C++, Java, and Javascript are more troublesome.
[1] https://github.com/rust-lang/rfcs/blob/master/text/1236-stab...
In any case, panics are not guaranteed to unwind or be catchable: they can be turned into aborts (yes, on the stable compiler). This means an arbitrary library using them for recoverable error handling is incorrect.
A WITH clause mechanism implies no dynamism.
Please be more specific with your complaints. Thanks.
Additionally, unless one is using explicitly typed exceptions (i.e. Java-style checked exceptions, very much unlike Python), it requires allocations, as it's not possible to statically determine the size of the error object to be returned.
Similarly, from an assurance/reliability point of view, the dynamically typed nature of non-checked exceptions is unfortunate.
(These second two are, I believe, the points I made last time we discussed Python's exceptions.)
"We'll also need a way to handle out-of-memory (OOM) conditions. The standard library calls the abort intrinsic, which just calls an illegal instruction to crash the whole program. The reason we abort and don't panic is because unwinding can cause allocations to happen, and that seems like a bad thing to do when your allocator just came back with "hey I don't have any more memory"."[1]
Allocating is definitely a big deal for a pervasive error handling! For instance, parsing a number might not succeed. Both the actual parsing and the failure cases are cheap, but not if the latter has to be indicated by allocating and unwinding and doing a pile of the dynamic checks up the stack.
Additionally, whether the language is able to operate in OOM isn't the only reason to choose an error handling scheme. However, even if it was, I don't think it applies directly to Rust: Rust-the-language (and Rust-the-core-library) can operate in an OOM condition, e.g. people run Rust code without needing a dynamic allocator at all. You are correct that some parts of the standard library don't handle OOM, but, using exceptions pervasively means that there is one error handling scheme for things that can rely on having an OS/malloc and one for things that don't need them.
> Besides, unwinding already causes allocation
Yes, and that is one reason why unwinding is not used as a pervasive error handling scheme in Rust: there are various fairly fundamental problems with it. It is one of the reasons why panics can be switched to abort.
Exceptions are not meant for "pervasive error", they are for exceptional execution paths. If an execution path is frequent enough, wether it's an "error" or not, then it should not be an exception.
I think this is the part of the argument that the "no exception camp" usually misses : there are multi type of errors (recoverable vs fatal, frequent vs unfrequent, expected vs unexpected), having exception is not about using exceptions for all of them
If Rust is going to bill itself as a systems programming language, it needs these. I added them for my app:
extern {
#[link_name = "llvm.setjmp"]
pub fn setjmp(a: *mut i8) -> i32;
#[link_name = "llvm.longjmp"]
pub fn longjmp(a: *mut i8, b: i32) -> ();
}
Sure, but what I meant is that most of the time userspace programs have nothing interesting they can do with the bus error (and, as I noted, standard C does not actually provide this option anyway). Regardless there are existing signal handling libraries that aren't that hard to use in Rust (you now describe one in your post), so I'm not sure why you're pointing to that as "something... that Rust lacks."
There's no way I'm aware of that setjmp / longjmp could possibly be integrated with safe Rust, but I agree that they should be available to unsafe code (in a way that doesn't require invoking llvm intrinsics).
And that's okay. There is a ton of space outside of that context, and still within the "systems" space that C and C++ could use a high quality competitor in, and Rust fits that bill nicely, in my view.
Rust the language is really composed of two almost identical subsets, "safe" one and "unsafe". Safe Rust is what you will normally see, governed by normal safety rules and abstractions. Unsafe Rust is not what you will normally see, but still governed by safety rules and abstractions, only with an escape hatch. What I feel is that safe Rust covers the higher-level subset of "systems programming" (predictable performance, strong abstraction and safety), while unsafe Rust covers the lower-level subset of "systems programming" (excellent performance, near-complete control over everything). And still they are almost identical, so that the abstraction made in unsafe Rust is usable in safe Rust, and that's ideally how it covers the entirety of "systems programming"---the only border is the abstraction itself. Of course, provided that we have enough supply for appropriate abstractions (the community is trying hard with several promising results though).
Rust programmers do like the safety guarantee of safe Rust and rarely talk about unsafe Rust, but I think unsafe Rust plays a large role in the possibility of Rust. It's much closer than the border between, say, "glue" languages and their implementation languages. We don't change the fact that we will sometimes have to bend the rules (it's probably impossible). Instead we let you bend the rules, but only when you are in the cage. And that cage is, while not immunable to every attack, really strong.
[1] The advocacy naturally advocates for something's possibility and not for something's success. So it is still correct that Rust still lacks some solutions for existing problems, though it's not inherent.
I think that's a misunderstanding of meaning. Rust's safety and unsafe are intrinsically linked. It's not that Rust is always safe, but that you have a well defined way to compartmentalize safe and unsafe portions of the program, and can use that to reason better about what's going on. In a way, talking about the safety of Rust is specifically talking about unsafe.
Catchable with: https://hackage.haskell.org/package/base-4.9.1.0/docs/Contro...
Rust's uses algebraic types to make things checked at compile time and uses operators like `?` to give you expressiveness while removing the overhead and annoyance of manually checking everything. It is a huge improvement.
> then all of my carefully crafted error-handling routines would go up in flames
No just sandbox the code inside a try catch...
> pattern matching is the best method of clearly displaying intents and possible downfalls.
You are stating an opinions as a fact here.
This works fine if it's just a matter of rolling back a database transaction or releasing file handles (b/c someone else is doing all the work for you). But if you have more complicated invariants, your try catch has to handle restoring those invariants, no matter what path your code took.
The most important feature is that catch blocks are executed before the stack is unwond, providing the ability for a handler to signal back to the context where the error occurred how it should be handled.
It's sad that no other languages implement this and instead simply decide that exceptions are bad.
The code expander has an entry point which allows the caller to be informed about what variables and functions are free in a block of code. The implementation of this entry point works by intercepting warning exceptions about unbound symbols, and accumulating them in in lists, which are then returned to the caller.
This is a useful thing which reduces the need for users to write their own code walker in certain kinds of advanced macros.
This sounds like a general errors handling issue that nor exceptions nor monadic errors types can prevent.
* panic + catch_unwind, but that's special and not meant or used in practice for error handling
Sometimes I think CRust would be a good idea, the minimal ideas that I like from Rust just layered on top of C as a linter.
The point is that these ideas are not "weird"—they're just decisions taken straight from other languages.
I can't believe we have to defend closures, of all things, from the charge of being "weird" because a language from the 1970s didn't have them, but here we are.
> Sometimes I think CRust would be a good idea, the minimal ideas that I like from Rust just layered on top of C as a linter.
That is not possible. You can't just graft the borrow check from one language onto another language that was not designed for it. For example, C doesn't even have generics, and the lifetime system is designed around generics.
Honestly, I'm tired of responding over and over to the suggestion that we should have done Rust as a static analysis on C++. If you actually try to design such a system, it becomes obvious very quickly that it cannot work for systematic reasons.
Rust is a systems programming language that runs blazingly fast,
prevents segfaults, and guarantees thread safety.
Us systems programmer types, we tend to drag our knuckles a lot. Still we do have opposable thumbs for grasping tools and we're damned proud of that. Perhaps if and when we sufficiently evolve and attain an upright, high level posture we'll see the light. But for now, be happy that we're trainable if not educable.
Now please excuse me, but I have to go pick some low hanging fruit. That and worse is a lot better.
1. Removing structs and interfaces (in favor of what? Java-style classes and interfaces?) would make Rust more verbose, less of a systems language, and slower at runtime due to the indirect dispatch.
2. Changing the keyword "enum" to something else is a cosmetic change which would make as many users unhappy as it made happy. (We know, because we solicited feedback on the keyword before selecting it!)
3. I've addressed error handling in the sibling comment. There's basically no other way to do it that would be in line with Rust's goals as a systems language.
4. Rust would be a worse language if it lacked closures. Closure support is a basic feature in a modern language.
"Everything is an expression" is pretty different. You can say ML/Lisp, but those are non-top-10 languages/styles.
> "Everything is an expression" is pretty different.
No, in Ruby, everything is also an expression; this is sometimes unrecognized because some constructs that are cognates to constructs that are statements in other languages are frequently (but inaccurately) referred to as statements in Ruby (the most frequent example I've seen is "case statements").
Also Ruby is a kitchen sink language, so I don't know if we should be using it as the baseline for a language with a small surface area.
Thinking about it in that sense, classical inheritance has always been based on a fundamentally flawed abstract model.
(Admittedly, purely noun-to-noun inheritance does have its place in a well-structured abstract model, in cases like "every Teacher is a Person", but I stand by Rust's decision to omit it... at least in the near term, because developers are too used to overusing/abusing it out of habit.)
This. I've spent some time researching Rust but it's just ugly language for me, really. When I read D everything is so clean, so readable. When I need to read/write Rust, it's just not enjoying for me. There are people that will enjoy it for sure, that came for example from Haskell.
Create language like Rust with D like syntax, no GC, no additional indirection, RAII, less strict rules or possibility to turn off some of them and I am sold.
I think that language will end up looking a lot more like Rust than you think. You can't just compare a language that wasn't designed for zero-cost memory safety to one that was, as if the zero-cost memory safety features have no learning curve.
I disagree, I think you could pick different way based on Cyclone coupling with some modern static analysis techniques, it would not have so many features as Rust have but it would be less invasive and more "C/D'ish".
This I think is where a lot of the pushback comes from. People say want a new C replacement, but some portion of them look at what that actually means, and find they actually want C with a new feature or two because actually learning something new, even new looking, is work. Rust is not C or C++ with a few new features, it's a new language, and some people really want that, and some people are put off by how different it is.
It's perfectly fine for people to have a preference, but people should be aware of what it is - a preference. It's not some inviolate law that C's syntax and way of doing things is good, and we should make sure a successor follows that. It's importance to distinguish the familiar from the good. C has a huge advantage in that it's familiar, through it's own popularity and history and in those languages that it influenced. That doesn't mean it's inherently better though.
Alternative view: the clean separation of data from API has a nice analogy to the manipulation of data in C, and a powerful way to maintain that separation while still allowing for powerful object oriented programming where appropriate.
> The enum approach to variant records is too weird.
I disagree. The tagged union is an oft-used pattern in C and C++ code. Maybe calling it "enum" is a bit off, but the concept is incredibly useful, and Rust's compile-time support for it is incredibly useful and powerful in my opinion.
> The error handling is too weird.
It's very C-like, but more strongly typed and, thanks to the Rust developers' efforts, quite clean. A C programmer, or a C++ programmer who sets the "no exceptions" flag as a matter of best practice should feel quite comfortable with Rust's error handling.
> The half-functional style is too weird. The widespread use of closures for simple stuff is too weird.
I would substitute "cute" for weird, but overall I don't mind it. I do agree that emphasis on making these features more prominent, especially at the expense of more explicit (e.g. explicit for-loop) constructs, might hinder traction.
I thin kit depends on both where the new users are coming from, and how much they've modified their thinking to a specific programming style. If you are a C or C++ programmer and already think in conceptualized for loops when planning steps, then it seems odd. If you haven't gone that far into letting that style define your thoughts, or continued to use other languages that were a bit more functional, you might find that that conceptually it's easier to reason about.
I.e. "I'm going to transform each of these items by doing X, Y and Z and store them here" as a concept is neither directly a for loop nor a map a the basest level, but you might start thinking in maps or loops after a while if that's your only option.
Case in point, in the Ion shell that I am working on, I have a shell expansion module within that takes a structure containing closures that are used to grab and expand array variables, string variables, tilde variables, and process expansions.
Because of this, the module can live as an entirely separate piece of software with no dependency on the specifics of Ion, and I can write reduced unit tests that extensively test every component. I could strip it out of Ion and use it with a completely different shell project. That shell would just have to provide the batteries (closures) that define what to do with certain tokens.
That's the whole reason to have a new language; if we just wanted a language that works like elcurrent popular languages, we wouldn't need a new language for that.
> I have the feeling that Rust is destined for a niche like Haskell - cool, but not mainstream.
Becoming a Haskell or a Lisp -- never an industrially dominant language but one from which later and more industrially popular languages are continuously mining for some subset of their ideas because they solve problems long before most users of industrially popular languages even recognized the problem, much less the value of the particular solution, is not a failure.
And it makes the language one that is valuable to learn even if you don't often get to use it anger.
With it's borrowing semantics and steep learning curve, Rust will never gain significant market share in the world of web development. And why should it? Time to market matters more than speed. It's much easier to ramp up new hires on a C# or Go code base than on a Rust one. And the borrow checker will always create friction for people new to the language. As someone with a C++ background, it still took me over a month before I stopped fighting with the borrow checker and with lifetimes. I can't imagine how long it would take to get a completely new programmer up to speed.
Unfortunately, Rocket does not appear to be on track to work on stable Rust for the foreseeable future.
The website stores all the content in a database, uses handlebar templates to generate HTML pages, stores the generated HTML pages in a concurrent hash map compressed with the native Rust implementation of Zopfli, and only regenerates pages after a set amount of time -- all in pure Rust. I can serve an unrealistic amount of requests per second -- just bottlenecked by a consumer-grade network connection.
If the timestamp has expired and a user requests expired content, only then will that page be re-generated, re-compressed and updated. Without this, I would have to re-generate and re-compress the content each time I get a request.
Yesterday there was a story about Rust here on HN: "Programming ARM Cortex-M Microcontrollers with Rust." Among the replies was a complaint; someone couldn't figure out how to write a static buffer and was discouraged. Someone else provided an example of how to do this. Finally, another person noted how unfortunate the solution was. Here is the code, reworked by me just a little:
use std::io::Write;
use std::str::from_utf8_unchecked;
static mut S1: [u8; 17] = [0; 17];
fn main() {
unsafe {
write!(&mut S1[..], "Hi: {}", 5).unwrap();
println!("string: {}", from_utf8_unchecked(&S1[..5]));
}
}
That is a lot of friction. I know (as in I understand with precision) the reasons for this and they're entirely legitimate. But damn... the pain is just more than the bulk of the world is ever going to tolerate. You can do the same task with zero friction in C/C++ and go fast/be small, or you can do it with a "managed" language with zero friction and handwave at the bloat and cycle eating cache killing GC, or you can don the hair shirt, focus on your breathing to keep the panic at bay and use Rust.
It is inescapable human nature that the "mainstream" will avoid the latter.
Unfortunately, the reason that's a problem is because most management doesn't even know what it means. And that's not likely to change.
So saying "We have a language that might take a bit longer but solves X" is a difficult conversation when the reply is "Wait, what is X?"
I've been using Rust heavily for 10 months. I think that if you want to use it for web stuff you very much can, but the language is more immature than it might first appear. If the community keeps going the way it is, I hope to work with it commercially by 2020.
The most promising things I've read about it as a serious systems language are from Cambridge Consultants [1,2], but there's a lot of ongoing work to make it ready for embedded work.
[1] http://blog.cambridgeconsultants.com/wireless-product-develo...
[2] http://blog.cambridgeconsultants.com/wireless-product-develo...
Java, C#, Go, Haskell, OCaml are much easier to ramp people up with and hire for.
At the moment a lot of hobbyists are doing web stuff in Rust. Commercially I think usage would be in the same vein as the common pattern of rewriting Ruby services in Go if it starts to limit performance.
If you've got a particularly hot lambda function, rewriting it in Rust is a pretty simple way to save a bunch of money.
And then there's the environmental cost of slower code. How many tonnes of CO2 emissions are higher level languages responsible for daily?
Sure. If it's just as easy for the task then why not?
But I wouldn't recommend Rust for web development for the same reason I wouldn't recommend C++ for web dev: complexity. Obviously, this is entirely subjective but I don't think either language will ever be easier to write than Java or C#, especially for beginners.
I used to TA a freshman data structures class. I can't imagine ever going to a class of new programmers and trying to explain to them when to use Rc<RefCell<Vec<T>>> vs. Rc<Vec<RefCell<T>>>.
I'm interested - how do you teach it? I would have thought that the type system could make these things easier to visualise rather than harder, but then I don't have teaching experience.
Idiomatic Rust makes single-threaded interior mutability very, very rare. I don't remember ever once encountering the dilemma of "Vec<RefCell<T>> vs RefCell<Vec<T>>", in my own code or elsewhere.
In fact, my current project (https://github.com/team-worm/spice) involves an HTTP server written in Rust. Like you suggest, managing state across requests was one of the harder parts (both for myself to work out fully and for a team member who started with no Rust experience to grasp).
However, much of that difficulty was intrinsic to the problem- the HTTP library we use is multithreaded, so for correctness we have to synchronize access to the state. Instead of discovering this by way of race conditions or hard-earned experience, Rust enforces it for us. Team members who have never used Rust before can be trusted to go in and work on the server without worrying about causing subtle concurrency bugs. They hit the brick wall of error messages instead.
The only problem is that the compiler is very slow now, so it doesn't scale to large code bases, which is a no-go in my company. Hopefully the Rust team understands that this is not only a would-be-nice to have feature (I see learning the borrow checker as a smaller problem)
The way of working with that is use cargo check command which is much faster and splitting your problem into multiple crates so you don't have everything in one giant project. Which is what tends to happen in large code bases anyway.
Also they are putting quite a lot of work into making it faster. Before you get to that large code base it will be better.
https://www.wired.com/2015/09/google-2-billion-lines-codeand...
Rust is a modern language with very good concepts and features. It's quite complicated to learn.
My answer is it will be a good language, but won't be a top language.
Rust is better than C++, but it's not extremely better than C++.
As for "complicated to learn" ... Rust does have a significant learning curve. However, so does C++, and the C++ learning curve never ends: http://whereswalden.com/2017/02/27/a-pitfall-in-c-low-level-... https://bugs.chromium.org/p/chromium/issues/detail?id=683729... I've been programming in C++ for over 20 years, plus I have a PhD in programming language tech, yet there are many dark corners of the language I don't understand, and more keep getting added all the time. "Complexity budget" is not a phrase you hear in the C++ community.
I suspect many C++ fans aren't bothered about this because their knowledge has grown with the language. I pity someone trying to "learn C++" in its full glory.
Give me a single, self contained, executable any day!
I'm not shy about my dislike of Rust. I like C, I don't think avoiding buffer overflows and memory errors is that hard, and I chafe at the idea of a language I dislike aesthetically taking over systems programming.
But even I have to admit the arguments for using C instead of Rust are niche. Sure there's probably always going to be some instance where C makes sense technically, but if we could wave a wand and convert the world's C/C++ code to Rust, we'd immediately fix millions of memory errors and data races. It's impossible to overstate that benefit.
Think of the things the Rust team has to deal with:
"Is Rust a good web language?"
Is C or C++? Is Ocaml?
"Is Rust a good language for an OS?"
Is Python? Is JavaScript?
"Is Rust too big?"
Is C# or Java? Rust is a pretty small language, both in terms of features and implementation size.
"Is Rust powerful enough?"
Is Go? Go deals with this all the time ("Go ignores decades of PL research"). Rust's feature set is pretty good, but more importantly it's well thought out.
"Is Rust fast enough?"
Is Java? Is C#? Is Go?
"Does Rust compile fast enough?"
Does C++? Does Clojure?
"Will your Rust program be memory safe and free of data races?"
It sure will be. This is a monumental achievement. Your options for a memory-safe language without GC are... Rust and Ada?
"Does Rust have a good concurrency/parallelism story?"
Rust has one of the best, actually. It doesn't use segmented stacks so it doesn't achieve the M:N performance of Go, but it has memory and data race safety, OS threads, and futures, so no problem.
"Is Rust too hard?"
Honestly, programming is hard, other languages just let you ignore it. There's an example about manipulating a string as a global array in this thread somewhere, which is not really something you should do, and the argument was "this was wildly difficult". It is, yeah, because safely managing concurrent access to a global, bounded section of memory is wildly difficult.
Again, I'm not a Rust fan and I sort of can't believe I'm writing this. But look at what Rust has:
- memory and data race safety
- scripting language ergonomics (after you internalize the borrow checker)
- the speed and memory usage of C
- a low surface area
- advanced features
- great community outreach and documentation
- familiar structure (as opposed to something like Erlang or Haskell)
If a language like that doesn't succeed, you have to start wondering what will.
My personal belief is that it is succeeding, but I think success looks a lot different than most expect: new projects that need a systems language are far more likely to be written in Rust than in C/C++.
Actually, if you use Tokio or similar approach, you achieve better performance than Go (no need to re-allocate stacks) while code is still quite readable and boilerplate-free.
However, futures are certainly not boilerplate-free. They destroy your ability to use native control flow the way you can with threads (M:N or 1:1). You can get some of that back with async/await, but Rust doesn't have that and it's still not boilerplate-free.
As big as C++/C? Too early to tell for that.
Though not a flawless datapoint I'd rather use something like the TIOBE[1] index, which puts Rust at 0,37% rating, or position 41, right below Erlang.
I hope that'll change, I think Rust has some interesting concepts and could be a notable step forward for some things that we've always done in C. But I can't find a datapoint that would make out Rust as being mainstream today.
/plug :-)
Example of usage outside of company like in question from arstechnica:
"Outside of Google, companies like Wrike, Workiva, Blossom and others have also been using Dart to develop their products, so there is definitely still a Dart user community outside of Google, too."
This is how everyone interpret that question.
> And you would reply that almost everyone use it, because everyone is shipping their apps with Docker.
Seems reasonable. Docker is a pretty compelling data point for the viability of Go for writing systems tooling.
This argument still seems strange and very petty.
Those are not an arguments for anything. What I wrote still stands. It's clear that author asked which company use (writes) Rust besides Mozilla, not which company integrate third party tools that was written in Rust - it's logical.
Well, you cherry picked my comment. I had other thoughts---specifically disagreeing with your analogy---but I guess that wasn't important to you?
If you (or anyone else) had a different interpretation than me, then that interpretation should have been immediately clarified by the link I provided and subsequent clarifying comments. Readers can decide for themselves whether it "counts" or not because they have all the information.
> I thought you are not part of "rust evangelism strike force" but seeing what you are writing now, I need to reevaluate that opinion.
Questioning biases is important. I encourage everyone to form their own conclusions. I personally think questioning my character and my intellectual honesty over what I said in this thread is extraordinarily petty.
Purposely interpreting something differently while there is social majority consensus on interpreting it the other way looks like having an agenda, especially by someone that is heavily involved in topic in question like you are.
> I personally think questioning my character and my intellectual honesty over what I said in this thread is extraordinarily petty.
We are not bug free. When more than one random person questions my behavior same way I do not find that "extraordinarily petty", maybe there is something to it, maybe I should look at it. I am human, I have faults, denying that is another fault.
> Questioning biases is important. I encourage everyone to form their own conclusions.
I agree with you here. Anyone reading this discussion can make their own conclusions, some already did and were vocal about it - that's why we have this discussion in the first place.
> Purposely interpreting something differently while there is social majority consensus on interpreting it the other way
I did no such thing.
> When more than one random person questions my behavior same way I do not find that "extraordinarily petty"
You're the only person accusing me of purposefully misleading people.
> that's why we have this discussion in the first place
I'm in this discussion with you because you're assaulting my character, not because we disagree about whether Microsoft is actually "using" Rust or not. I don't care what you think about the latter, but I am not going to let unsubstantiated bullshit about me personally go uncontested. Now, please either show some evidence that I've purposefully tried to mislead others, or---and I mean this in the nicest way possible---shut your trap.
"Assaulting my character" - wow. Don't be so defensive, pride is talking through you, not reason.
> Now, please either show some evidence that I've purposefully tried to mislead others,
You provided all evidence that would point to that conclusion already in your comments and I already discussed those in my previous comments. You have any proofs that state otherwise? No.
> You're the only person accusing me of purposefully misleading people.
I am not the only one that challenged what you replied, I am just describing possible reason behind it after connecting dots. Read about defense mechanism, psychological repression, bias, denial and thought suppression and especially narcissistic defenses. Doing something purposely doesn't mean it was consciously.
> unsubstantiated bullshit about me personally go uncontested
"unsubstantiated bullshit" - This are conclusions I made analyzing your comments. I do not call what you wrote bullshit because I don't agree with it. Please be more civilized in this discussion.
> shut your trap
Clearly this one shows no one should contest your character. You are without any faults, I am sorry I dared to think otherwise.
Source: We had an email thread about using Rust on the MS Rust mailing list about a month ago.
Imagine if Ford mandates its suppliers to use Rust for the software in its car and it faced little problems after a few years out on the road.
Which is fine, nothing wrong with Ada.
You might be interested in some publicly available coding standards for the Joint Strike Fighter (C++) and the NASA JPL (C):
See: http://blog.regehr.org/archives/213 (particularly part 3)
http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
The problem with aerospace, automotive, etc. is that there's substantial physical risk associated with errors. So there's not a lot of incentive to go with something brand new. Things like network security, etc. are a place where people are maybe a bit more concerned about safety than in some other areas, but also need performance, and notions of risk are more vague.
The interest of Tor developers in Rust is not surprising to me at all, for example.
Nothing is going to happen overnight, and I don't see C/C++ going anywhere, but I wouldn't be surprised at all to see Rust gaining a foothold in certain places, and expanding from there. I could also see it being a flash in the pan too, but it's unpredictable really.
Rust's complexity is equivalent to, but distinct from C++'s. I prefer it over C++, and I'm one big fan of the latter.
Being dishonest about Rust is not going to help anyone no matter how good it is.
OTOH, I don't think this makes it harder to learn in net, because it saves down-the-road learning needed for high effectiveness of a likely greater magnitude than what is frontloaded. But it does raise the learning cost of getting to basic proficiency, in the same way as static typing (which, done well, has the same kind of down-the-road savings) does.
It is all a matter of mindset, and so if you think it is hard, then it will be hard. However, you must remember that like many things in life, learning is like a Chinese finger trap. The more you struggle and resist, the harder it seems. Rust is a Chinese finger trap. Until you change your point of view and use a different, simpler approach, you will have hard time.
Pushing back on the Rust-is-hard "misconception" where it is wrong is good, but calling the language universally easy just because you happened to learn it quickly... is wild: it incorporates ideas from a lot of different languages, so many people will be encountering more than one completely new concept. It can often take a while to "click" onto a new concept, because one isn't used to framing problems in the way that makes the concept simple. For one, saying Rust is easy so stridently, without nuance, makes people who are struggling feel stupid and demeaned (yes, I'm sure you don't mean it that way, but that's how it comes across), and makes you personally sound rather arrogant (/r/iamverysmart material).
In any case, with such ardent advocacy and combativeness, your technical arguments need to be 100% perfect: people will remember reading wild assertions they know to be wrong ("some Rust guy was talking about how ..., it wasn't even close to correct") more than they remember normal discussion about Rust. And this applies to both the people directly commenting, and the orders of magnitude more who are just reading the threads.
The point is claiming it's easy dismisses the very real obstacles that exist for others, and does worse than nothing at convincing people to try Rust. So I second dbaupp's sibling comment here- your comments embody the aspect of the Rust community that turns people away.
Please, just slow down in your advocacy. It's not helping.
Possible benefits:
* users not going "gack, this is written in an obscure language that we have to install to build it".
* the implementation quality being better: the thing I write now will benefit from the language being less of a moving target and with fewer bugs, better performance.
Maybe a lot of that is just psychological, but so is "I like it" versus "I don't".
On point two, Rust is not a moving target, in the sense that it has maintained back compatibility since release to an amazing degree, and the build system does a good job by automatically pinning dependencies for applications. Also, even if it is totally abandoned, you still have a pretty solid language with C-like performance that benefits from ongoing LLVM optimizations. But it is certainly true that there could be unfixed bugs in an abandoned Rust.
I'd say, before Rust becomes really mainstream, we have to wait for the current generation of sysdevs to die.
But I guess till this is the case, there will be new languages invented that may be better than Rust.
On the other hand, most new companies don't hire old devs, so maybe IoT will give rise to new companies and young sysdevs all using Rust before the old generation is gone...
Why?
It's like with everything. Most people simply do what they always did, most never reinvent themselves.
Yeah I get that. I asked why they should die. Not how or by what means.
> It's like with everything. Most people simply do what they always did, most never reinvent themselves.
Based on? And note that we're not talking about "most people", we're talking about a very specific subset of people. Considering the changes in popularity of programming languages and the recent surges in adoption of Go and Swift, I'd say there's at least evidence to support people do change in this domain when something comes along that excites them or opens up new possibilities.
(Don't ask me to cite it though. I don't have time to go digging back through the textbooks from my "scientific reasoning" course.)
I don't see it growing and replacing C++ though. I don't think there's much incentive post C++11 to really consider porting anything (even small things) over. Most of the features Rust gets praised for are either: (1) Ridiculous - if you need segfault protection, you're a bad programmer (CLARIFICATION: if you act like segfault protection is some majorly useful feature, you're an imbecile who must also think writing C/C++ is like disarming a bomb - nonsense; give me a real argument for Rust that isn't: insignificant, badly contrived, already in C++, etc. - you can't convince a generation of systems programmers to drop everything to move to Rust without this). Let's be honest, you don't segfault unless you're doing something idiotic. I've not segfaulted in the past 8 years in anything but assembly. Or, (2), things I've been using in C++ for the past 4 years.
Rust will definitely end up in these areas I believe but I just hope that it's not some horrible binding to a C/C++ library or something. I think backwards compatibility and current dependencies is a big thing.
I've caused segfaults in the runtimes of three major languages in the last year by running code that, from a user perspective, is completely fine.
I don't think the developers of those runtimes are "bad programmers".
I replied to you mostly because "you're a bad programmer if you need protection against invalid memory accesses" is rampant nonsense. Everyone needs that protection. It is at best a question of whether you need other things more. (Few people do.)
I think C++'s biggest failing is how large and convoluted it is but, in relation to the thread's question, how many beginner C++ programmers are gonna jump straight into systems programming? I sure hope the answer is 0.
I just see too many people quoting the list on Rust's homepage verbatim when I ask them about why a skilled C++ developer should pick up Rust.
Nobody said that C++ code segfaults every 5 minutes, and accusing people of being disingenuous for saying things they never said is, well, disingenuous.
The claim is that memory safety problems are serious problems in C++ code. It's been found that memory safety problems are the leading overall cause of software security vulnerabilities [1].
[1]: https://insights.sei.cmu.edu/sei_blog/2014/08/performance-of...
sigh Please look at the "trophy case" here: http://lcamtuf.coredump.cx/afl/
I want a better argument for: 1) A C++ developer who's been writing C++ for a long time and is skilled in modern C++ who is wondering why he'd pick up Rust for user application development? I await more superfluous bindings like "Rust-Qt". 2) Porting C/C++ to Rust code (with a rather large codebase).
Every argument I've seen for Rust is: out of context, disingenuous when they compare it to other languages, or just incredibly biased. I don't think it's ironic that the majority of people I've met who have started doing Rust are bad at C and C++ and have bought into the list of features on Rust's homepage without any knowledge of anything related to them.
> it's incredibly disingenuous to act like it's a major issue
I gave you a trove of real world examples of serious security issues in widely used software developed by competent teams. Quite a few of these would have not existed in a language with the kind of guarantees that Rust provides. How is this disingenuous?
Take a look at the OpenBSD bug - any user can kernel panic the whole host, a massive security issue. Are the OpenBSD maintainers, in your opinion, "idiotic"? Or that Xen bug - privilege escalation. Are the Xen developers, in your opinion "imbeciles"? What about all the OpenSSL / OpenSSH ones? Perhaps they're "bad at C"?
The truth is that as code gets more complex, writing safe code becomes harder. The above is evidence that even smart and experienced people regularly cause colossal bugs that have real life implications.
Genuine question : do we know that those bugs would have been avoided using rust? Maybe some of those part would have had to be done unsafe mode for some reasons.
> Take a look at the OpenBSD bug - any user can kernel panic the whole host, a massive security issue. Are the OpenBSD maintainers, in your opinion, "idiotic"? Or that Xen bug - privilege escalation. Are the Xen developers, in your opinion "imbeciles"? What about all the OpenSSL / OpenSSH ones? Perhaps they're "bad at C"?
When was this code written ? you are comparing old C code with (non existant/hypothetic) rust code. How do you know the rust wouldn't slower ?
> The truth is that as code gets more complex, writing safe code becomes harder. The above is evidence that even smart and experienced people regularly cause colossal bugs that have real life implications.
That we completely agree on, but we learn quite a bit on how to write better code. Some of that knowledge got embedded in compilers/compilers warnings and tooling, some retrofitted in the languages themselves , some through libraries design and coding guideline etc...
My main problem with your argument is that you saying that a code written in rust today would be safer than a code written in C/C++ decades ago...That's probably true.
I think a much more interesting question is how much safer a code written in rust today would be vs a C/C++ code written today , reflecting our current understanding and knowledge on how to build safe system.
A lot safer, judging by browser exploits.
Part of the current "understanding and knowledge of how to build safe systems" is to use a memory-safe language.
Advocating for Rust by lying is not going to help anyone.
The claim that Rust's memory safety is sound while C++'s is not is... not really the question. The question is whether that matters in practice. C++ has certainly improved in making certain mistakes easier to avoid.
Now, I come down on the Rust side for many situations, but making unsubstantiated claims about your language of choice is exactly the problem people had with the Curl blog post. Please stop making them about Rust.
No, the argument i am trying to make is that if someone wants safe and reliable code, it's possible to buy that in C/C++ at cheaper price than to migrate to whole new language and platform.
> I'd be willing to wager a far larger portion of the Rust written today will follow best practices
Yes, as you mentioned that's by design. But i don't that the metric we should be looking at : in the group of people/team/compagny who actually care about safety and performance ( and let's be honest that group is the biggest one), what proportion will be using C++ vs rust.
AFAIK no one's done a comprehensive survey, and it'd be hard to know for certain what someone would choose to use unsafe for until/unless they actually rewrite the code in question into Rust.
But if you look at code that is written in Rust today, I think you'll find less than 1% of the code is unsafe. [1] I think it's used for
* FFI / interfacing with C (common now, but less so the more you rewrite into Rust),
* low-level code (such as synchronization primitives and data structures), and
* a few bits of performance-sensitive code.
My gut feeling is that many of these bugs are in safe code, the "boring" 99%. The bugs would either be prevented by the compiler or turned into a panic at runtime instead of undefined behavior.
When people use unsafe, I'd like to think having to explicitly flag it as such would make authors and reviewers more careful. But certainly there's no 100% guarantee; I've seen broken unsafe Rust code in the wild already. As a small example, sqlite3::core::ResultRow::column_slice [2] is unsound; a following call to another column_* method would invalidate the returned pointer, [3] but as they all take a &self nothing prevents you from using the pointer after it's no longer valid. column_slice should take a &mut self instead. I haven't reported the bug because this buggy crate has been marked obsolete in favor of rusqlite.
[1] For a project of mine, it's found on 0.3% of non-comment-non-blank lines (23 unsafes / 7,390 lines). 13 of those were for FFI; the remaining 10 were due to my unfortunate obsession with optimizing for CPU. If anyone's done an accounting of more/larger projects, I'd be curious to hear it.
[2] http://www.madmode.com/rust-sqlite3/sqlite3/core/struct.Resu...
[3] https://www.sqlite.org/capi3ref.html#sqlite3_column_blob
I've been doing systems programming in C for 20 years. I disagree with your claim.
I disagree, segfaults can arise out of simple mistakes in rare cases that aren't always immediately obvious - let alone a segfault in a complex system.
A sign of a good language is to as much as possible make invalid states illegal by design. Why, if you can reliably check for bad memory use with the compiler, would you not do so? Toughness is no measure of coder talent, otherwise the best of us would only be using assembly for everything.
This is exactly the insight that will probably (if I can help it) keep me from leaving the functional language space ever again.
I am curious why specifically C++ 11? Could you elaborate?
Modern C++ has made great strides in the direction of making writing good code a lot simpler. I don't think you're gonna convince C++ (and C developers, of course) programmers who've been doing systems programming for a long time to stop everything and jump to Rust. It's just not viable.
But it can become a hot place for higher-level people to do lower-level things and rapidly learn a lot, as it has for me and some other Rubyists.
So - we can implement threads without data races if we implement threads without data races? The reason people cite memory safety as a feature of Rust over C++ is because you get it for free, without having to do any additional work to achieve it.
Nothing is free, language design is an exercise in compromise. OP might need to calm down a bit with the aggressive language, but underneath all that there is real message from people using (trying to ?) use modern C++ : The added safety you mentioned can 1) be really well approximated using modern C++ technics, 2) addressed by really well engrained coding standard and practice learned and known for a long time and doesn't apply for the in the unsafe part of rust that some of the libraries have to use. But i doesnt come at the cost of reduce expressiveness in the safe part of language, slower compiler time and high learning curve.
C++11 move semantics and Rust move semantics are not equivalent. C++ requires every movable type to have a null state, and a (perhaps derived) move constructor that can potentially throw exceptions.
Rust avoids the null state problem by statically omitting the constructor call (or, in the dynamic case, inserting a flag into the stack frame rather than forcing the programmer to reuse the object itself). It gains some ability to optimize by forbidding unwinding during a move.
> I don't think you're gonna convince C++ (and C developers, of course) programmers who've been doing systems programming for a long time to stop everything and jump to Rust.
That's not the goal. The goal is to provide a tool for new projects like Servo, or incremental partial rewrites like Firefox, or new infrastructure like ripgrep.
This doesn't sounds true to me. Can you clarify what you mean by moveable type have to have null state ?
> Rust avoids the null state problem by statically omitting the constructor call
You seems to be conflating move semantics and move optimization...
Static omission of destructors in Rust is more than just an optimisation: locals (and other values) never have their destructors run once they've been moved-from, and thus no values need null states, and moving a value doesn't have to run arbitrary code (it can be, and is, just a memcpy).
Oops, too late to edit but that was meant to say "destructor."
"if you need segfault protection, you're a bad programmer" is a ridiculous statement - your personal data is one unchecked buffer away from being very public
So let me get this straight. Is your position that Google's Chrome developers (just to name one project) are idiots? You can't hold your opinion without believing that Google, and in fact pretty much every other company that develops C++ developers, hires mostly idiots.
https://dev.chromium.org/Home/chromium-security/bugs/using-c...
And those are merely the cases where such a bug caused a security hole.
Eliminating that entire class of bug suddenly sounds like a big win, doesn't it?