Hacker News new | comments | show | ask | jobs | submit login
Ask HN: Will Rust ever become a mainstream systems programming language?
82 points by justinucd 19 days ago | hide | past | web | 279 comments | favorite



I work for Faraday (.io, not the car folks), and we use Rust in production. I personally suspect that Rust will continue to grow in popularity.

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.


Trying to articulate why I like it: it marries the low-level control and type safety from C++ to modern language features as found in Python/Ruby etc, and in doing so manages to hit a pretty sweet spot in terms of having the compiler finding actual bugs early. With enums and pattern matching and the borrow checker, there are a bunch of features that help make the type system expressive enough that you can generally express what you need and still allow the compiler to perform very thorough, important checking on it, with the effect that "it compiles -> it works" is true much more than for, for example, C++.


I agree and would add one more property that makes Rust likable - it's about two years old, so still a greenfield language and standard library. It's easy to overlook that.


Whatever the answer is, you probably will not find it here. From an historical perspective, the success a language seems to have very little correlation with the vague notions of quality that we language geeks think are important. And it seems that the HN echo chamber forgets that.


Rust has to stand the true test of time -- the test where 5-10 years-old codebases written in Rust are still being maintained. Someone who's literate in programming language theory can evaluate the design decisions in Rust and say "it looks good" (or not), but in order to determine whether Rust is actually good for building and maintaining large, complex software systems for long periods of time, there's no metric like really doing it.

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.


> I think at some point, Rust will have enough tooling that people will try to start using it for graphics and videogames

The game developer community is actually one of the communities that jumped onto Rust really early, well before it hit 1.0.


Are there any AAA game studios using or evaluating Rust yet? I saw some GDC talks about the multithreaded game engine for Bungie's Destiny game. Given the debugging and QA challenges of their multithreaded architecture, something like Rust's ownership model seems like a good fit. Does the Rust toolchain support Xbox and PlayStation?

* 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


DICE is using it internally. The only reason why they aren't using it in games is because Rust won't compile on console platforms.


Oh? I hadn't heard of this before! I wonder if we can fix that...


Rust can totally compile on console platforms- it's been done, e.g. on PS4 (https://twitter.com/wickerwaka/status/479842553831776257), as I'm sure you've seen, Steve :)

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.


Yeah, I knew it was possible for some definition of possible; I just didn't know that any game studios were using it in any capacity, let alone a studio like DICE.

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.


I honestly don't know how fundamental an issue it is. I suspect the console vendors and engine/library developers would all have to be on board at some level. For some idea of the timeline- most consoles transitioned from assembly to C around the N64/PS1 era, and then to C++ around the time it was standardized.

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.


Thanks, this all makes a lot of sense.


>* 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.

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...


> memory management > It's just a lack of library support AFAICT.

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 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.

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.


I recall some DICE slides about two years ago and a mentioning from a DICE employee that they are building some of their game dev tools in Rust. Naturally, EA would never approve of allowing DICE to develop a game in Rust if it meant it would make the game PC-exclusive.


You mean hobbyist ? All the AAA games are still written in C++, none of the big studios is even considering to switch. Rust type system/restrictions would get into the way more than it would help in AAA game dev. Memory safety is not a problem in game development, they will just patch the bugs. Studios have whole ecosystems written in C++ that works for them. Benefits are really low compared to costs, that's why it's unlikely any major studio will switch any time soon.


Type restrictions aren't really a problem, but in fact really helps out game development in the long run.

> 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.


This is nonsense. I would love to use Rust in games (I currently work in games) but it's not clear that it would work out. That opinion is shared by game developers far more experienced and prominent than myself.

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.


There's already a few games written in Rust on Steam's Greenlight program. SHAR was even greenlit. Stating that it isn't clear that it would work out is basically stating that you are choosing to ignore that it has and is being done successfully.

> 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.


There are vast gulfs between Steam Greenlight candidates and AAA.

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.


You clearly don't read what you write.

> 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.


> Type restrictions aren't really a problem

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.


This is just outright denial. Bethesda titles are rife with segmentation fault galore. Even their most recent titles suffer the same terrible CTDs as all of their previous titles.


I am talking from my experience, I do not recall any segfaults in fallout 4 and elder scrolls oblivion.


What? Cannot talk about Fallout 4 but Oblivion (and Skyrim and Morrowind) was full of CTDs bugs. Some of them are fixed in EngineBugFixes(http://www.nexusmods.com/oblivion/mods/47085/?) or the Oblivion Script Extender (as the SetLevel bug). Don't you know that the background SpeedTree laoder thread has a potential for a data race that can cause random CTDs in the Wilderness? Or the Corrupted SpwanPoints bug? Or calling GetAlarmed on a NPC without AI package. Or the internal heap manager with it's race conditions?


I had great hopes for Rust as the future of systems programming, but they've decreased over time. Parts of the language are just too cute.

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.


This critique makes no sense to me. The composition-based object system mirrors Go's. enums aren't original (ML, anyone? 1970s tech?) or weird (every new language from this decade has them, including Swift, and C++ will have them by C++20). Error handling is literally Go's `if err` pattern but first-class (Swift's error handling is quite similar as well). And your disdain for closures has long been noted and I reiterate that your concerns are overblown.

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.


It makes a lot of sense if you take that "weird" is about familiarity, not functionality.


> But the object system (yeah, they're called structures and traits) is too weird.

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.


Your comment doesn't seem like a helpful way to advocate for Rust. It's a critique of the comment but doesn't address the commenter's concerns.


Because "addressing" the concerns would make Rust a worse language.

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.


Nitpick : > 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. Classes and interface can be implemented without indirect dispatch...


Only if you monomorphize interfaces—which gives you Rust's traits.


No. THe fundamental difference is that rust traits cannot convey structural information , classes (java and c++ can)


There's an open (and desired) RFC for this. It's not likely to happen soon since it's not a super high priority, but I'd be willing to bet it gets merged in the future.


Fair enough, as long as we agree that classes/struct in C++/java a quite a different beast than just monomorphic traits.


Absolutely, you're totally right with regards to today.


I didn't suggest changing the Rust language. There are other ways to address concerns than by saying "you're wrong," which is effectively what your comment did.


Nothing wrong with pointing out that someone's logic is wrong. It is true that the only way to address these 'concerns' is to change Rust into something that it is not. Rust without closures, structures, traits, pattern matching, and algebraic data types would not be Rust, it would be C. We don't want C.


Unless the person actually happens to be... you know wrong... Which does happens sometime.


If Rust doesn't differ from Go, from Swift, from Ruby, from JavaScript in these regards then perhaps, as was pointed earlier, Rust didn't know when to stop. It seems to violate the Law of Parsimony. I like Rust's borrow checker and that's pretty much it.

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.


> If Rust doesn't differ from Go, from Swift, from Ruby, from JavaScript in these regards then perhaps, as was pointed earlier, Rust didn't know when to stop. It seems to violate the Law of Parsimony.

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.
In a systems programming language I can do without closures, without generics, without .... I would and will say the exact same thing about Swift which also provides closures, generics, ....

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.


I don't think the current state of systems programming is something to be proud of.


>> The error handling is too weird.

>What would you rather see? Exceptions


We would lose lots of users from C and C++ if we mandated exceptions for error handling. The code size and complexity of unwinding is too much of a price for many to pay.


Rust is already paying the cost of unwinding. RFC 1236 added unwinding machinery for catching panics.[1] ("A drawback of this RFC is that it can water down Rust's error handling story.") This is the expensive part of exception handling. Rust has exceptions, but they're not very good.

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...


You have talked about Python's exception scheme before, and been rebuffed before (it is too dynamic to use pervasively in a systems language), please be more specific, and also have the minimum grace to not repeat incorrect things.

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.


What dynamism? An exception hierarchy just requires a type hierarchy, and Rust has enough inheritance for that. Rust has some dynamic dispatch, although it's not clear if the mechanism for trait objects [1] can implement an exception hierarchy cleanly.

A WITH clause mechanism implies no dynamism.

Please be more specific with your complaints. Thanks.

[1] https://doc.rust-lang.org/book/trait-objects.html


Firstly, "just" determining membership of a value within a type hierarchy requires far more dynamism than zero. Given a fairly arbitrary type-erased value x, how do you tell if its type implements some fairly arbitrary trait T? This hierarchy presumably has to be open, which makes the problem harder.

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.)


Having to allocate memory while processing an exception probably isn't a big deal, since Rust does not claim to be able to operate in an out-of-memory condition. Besides, unwinding already causes allocation:

"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]

[1] https://doc.rust-lang.org/nomicon/vec-alloc.html


> Having to allocate memory while processing an exception probably isn't a big deal, since Rust does not claim to be able to operate in an out-of-memory condition

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.


> Allocating is definitely a big deal for a pervasive error handling!

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


As the sibling points out, this is in the context of the suggestion of using Python's approach, where exceptions are not just pervasive, they are so pervasive they're used for non-errors/control flow (e.g. StopIteration).


To be fair to the "no exception" camp, they do see that there are multiple kinds of errors: they partition them into recoverable errors and unrecoverable errors.


And yet the bulk of this thread was in reference to python where exceptions are the pervasive scheme.


There's also Swift's approach, which looks like exceptions but is really similar to Rust's approach under the hood. Swift also requires failable calls to be prefixed by "try" which makes them even easier to spot than the postfix "?" that Rust uses.

Not mandate them , use have them as an options where the monadic Errors types are not enough or are too cumbersome to use.


And thereby prevent people from writing code that needs to catch errors but can't use exceptions. Won't work.


I don't understand what that sentence means...


Some people don't want to use exceptions because of runtime overhead costs.

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.


> then you'll get a split ecosystem

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.


Just curious, have you ever used any other modern languages that do not use exceptions for error handling? Most people who complain are just used to the exception way, but once you embrace returning errors out of functions, it really does feel like a massive improvement in terms of the paradigm.


I work on several languages professionally being the only one without exceptions Go and I don't see how its idiotic pattern of checking the value returned after every single call is a massive improvement on anything except masochism.


Go's "error" system is nothing like Rusts. I personally find Go's terrible and boilerplate-y.

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.


I dislike Go's error handling too. Rust solved this neatly with question mark operator (previously implemented as try!() macro).


Haskell is the last language i used without exceptions


Haskell has exceptions. So does Rust. People just prefer to use Either / Result (with good reason).


Exception in Haskell ?


Yeah. Try grabbing the head of an empty list, for instance. People for the most part don't like exceptions in Haskell, but that's not the same as the language not having them.


The `error` function is approximately `throw`.

Catchable with: https://hackage.haskell.org/package/base-4.9.1.0/docs/Contro...


How do you return failure for a bus error in Rust?


You can use signal handlers if you need to, but it's not like there's a good way to handle most bus errors in userspace to begin with. Anyway neither standard C nor standard C++ even spec out interrupt handling, and SIGBUS isn't a standard signal :P


A signal handler (signal!(sig::ffi::Sig::BUS, test_bus);) will catch the bus error in userspace. You now need to communicate that caught exception to the offending fn. For that, you'll need setjmp() and longjmp(), something else that Rust lacks.

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) -> ();
  }
It took me awhile to figure this out (and it barely works). There's a cleaner way (adding a wrapper) that is even more work.


> A signal handler will catch the bus error in userspace.

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).


Whenever I see "systems programming language" in the context of Rust advocacy I've basically begun mentally substituting "programming at the applications/systems grey-area border". There's a lot of ambiguity about what "systems programming" really means, so I wouldn't say they're not using it correctly, but I've been getting the impression that your brand of systems programming isn't what they're targeting.

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 is targeting all meanings of the word "systems programming". If you need some feature that Rust doesn't have, file an issue or write an RFC.


I think you have some point (especially for the definition of "systems programming"), but in my perspective Rust has a possibility [1] to encompass the largest possible meaning for systems programming. Here's why:

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.


> Rust programmers do like the safety guarantee of safe Rust and rarely talk about unsafe Rust

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.


I would be downright appalled if Rust were to start promoting exceptions. It's an anti-feature.


Being this emotionally invested in a feature, really is unprofessional...


Using exceptions would be unprofessional. If someone were to use exceptions, then all of my carefully crafted error-handling routines would go up in flames because someone's library decided not to use an algebraic data type for conveying error messages across boundaries. It's bad enough that C libraries can suffer catastrophic failures bringing the entire stack down. I want a consistent error-handling strategy, and pattern matching is the best method of clearly displaying intents and possible downfalls.


> Using exceptions would be unprofessional. Unless it happens to be the best tools for the particular scenario...

> 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.


> No just sandbox the code inside a try catch...

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.


I'd recommend taking a look at Common Lisps condition system, which does exceptions right.

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.


Fun trivia: Rust had conditions! Nobody used them, so they were removed.


That sounds short-sighted to me. Even in Lisp restarts (i.e. the feature that allows a handler to communicate back to the point where the exception was thrown) aren't used that often, but when they are, they are incredibly valuable.

In TXR Lisp, a continuable exception occurs every time you see a warning about something in the code, like an unbound variable. It is intercepted higher up and automatically continued.

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.


Perl 6 does[1], referenced directly from CLOS (from which a lot of other stuff was cribbed from as well).

1: https://docs.perl6.org/language/exceptions


You are basically stating that we should be doing both try/catch AND result/option at the same time, everywhere. That would get annoying fast.


Many people sooner or later have to spend an evening/night debugging serious issue affecting critical production system, discovering that system is left in inconsistent state after some corner case is throwing an exception that the code between it and the catch block didn't anticipate/handle correctly. And then they become emotionally invested.


> code between it and the catch block didn't anticipate/handle correctly

This sounds like a general errors handling issue that nor exceptions nor monadic errors types can prevent.


No language can fix mistakes, but in Rust if you have a() calling b() which calls c(), there is no way* that c can jump to a without any indication of it in b. You at least need to have `?` somewhere in b. I consider it a really good thing, among other advantages.

* panic + catch_unwind, but that's special and not meant or used in practice for error handling


Rust requires at compile-time that you handle each case.


I'd even prefer the golang way of error handling by `if err!= nil` over exceptions, treating errors as values is so much better


Hyperbole is lost on you, it seems.


I prefer to think of the difference being "In classical inheritance, verbs are members of nouns, but, in Rust, you define your nouns and verbs as distinct top-level identities, then define the valid relationships between them."

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.)


> I can't think of any way that Rust differs in this regard from, say, Ruby. Or JavaScript.

"Everything is an expression" is pretty different. You can say ML/Lisp, but those are non-top-10 languages/styles.


> > I can't think of any way that Rust differs in this regard from, say, Ruby. Or JavaScript.

> "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").


Eh you got me. I still think it's pretty surprising (especially for systems languages), but OK :)

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.


> But the object system (yeah, they're called structures and traits) is too weird.

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 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.


> But the object system (yeah, they're called structures and traits) is too weird.

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
Except that traits are also usable for static dispatch as in templates/concepts.

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 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.


The borrow checker is Cyclone's region-based memory management combined with linear/affine types.

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


That's the point. IIRC it's called Rust to allude to the fact that there's nothing really new in the language


Compile-time checking of owned and borrowed references was in Vala, a C#-inspired language for the GNOME ecosystem, four years earlier.


Doesn't Vala use reference counting? [1] I'm not actually sure; do you have some pointers I could read here?

1: http://www.vala-project.org/doc/vala/Overview.html#Memory_ma...


From what I remember, it just uses GLib's system for implementing reference-counted pointers in C and is equivalent to using Rc<T> or Arc<T> everywhere in Rust.


Yeah, that's what I thought. Which is very different than most Rust code!


Yes, but so does Rust. Reference counting is orthogonal to, although related to, to borrow checking.

Vala's wiki has a page all about its ownership mechanism: https://wiki.gnome.org/Projects/Vala/Ownership


Rust does not use reference counting for ownership, or borrow checking. It is true that you can introduce it for your own types though, with Rc/Arc. That's not really "rust using" it though; it's just a library.

Thanks for the link, I'll dig in!


Odd that you find closures weird. I use them everywhere that I can because it allows you to make your library more modular and, at the same time, allows you to write unit tests for otherwise impossible functions to test without dependency injections and other convoluted external setups that won't pinpoint the cause of an error very well.

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.


I don't know why you're calling all of that stuff "weird". I have to assume it's simply because you were never exposed to another language that had stuff like it. But you're definitely wrong about that keeping Rust from going mainstream - just look at Swift, which has a very similar trait system (called protocols), enum variants with associated values, an arguably weirder error system, widespread closures, and half-functional style. And I'd say Swift is already fairly mainstream.


Swift is mainstream because Apple replaced Objective-C with it for iOS and said that it's new standard for writing apps. How much of Swift is written out of Apple ecosystem? Not much.


Apple didn't replace Obj-C. They added Swift alongside it. Literally nobody is being forced to switch, and all of Apple's frameworks are still written in Obj-C (they can't be written in Swift until Swift has ABI stability).

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.


> Trying to port something from another language to Rust is difficult because Rust's ways of doing things are so different from other languages.

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.


This is like reading criticism of Erlang which we use. A bunch of people (the vast majority of which never shipped anything in it) have plenty of arguments against it, those of us that actually use it love it to bits.

Rust is productive, efficient and a joy to use. For things we required C/C++ before, we will be using Rust now.


Japan's NicoVideo seems to agree. 550K lines of Erlang, and 20K lines of Rust.


Rust aims to be mainstream hence the effort to improve ergonomics and marketing,documentation. Or atleast safe systems programming to be mainstream.


The fact that you think all these features are 'weird' just solidifies you haven't used a typed language with any modern features


You don't have to do any of that in your code. All the main compiled languages (or at least C++, Java, and C#) are all getting features roughly equivalent to what think is difficult in Rust: closures, functional pipelines, option types, pattern matching, and the like.

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.


> 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.

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.


> 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 think that language will end up looking a lot more like Rust than you think.

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".


> 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.


I agree with you that people have a preference. For me it's about enjoying what I am doing, I would rather change my job than write Rust every day, not because it's a bad language or I don't know how to use it but because this style of writing the code is not clean and elegant for me. I would rather write D, just my personal taste.


The Rust ecosystem has lost sight of the forest for the trees in my opinion. I highly agree with Graydon's opinion in "Rust is mostly safety" [1] that it's raison d'être is memory safety and concurrency in the systems space. But strangely a significant amount of time is being put in to making it usable for other tasks. I think this has to do with the different cultures between C/C++ developers versus other developers, namely that developers coming from web development are younger and more used to jumping around to new languages and frameworks.

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.

[1] http://graydon2.dreamwidth.org/247406.html


Web developers have zero issues with using Rust for web development though. The Rocket web framework is rather intuitive. I even built my website entirely in Rust with it.

http://mmstick.tk


"zero issues" is a bridge too far. Rocket, for example, only works on nightly Rust, and that might be a non-starter for a lot of people.


This has been my biggest issue trying to learn rust, there are too many projects that only support the bleeding edge.


Rocket is one big one. Just recently though, serde and diesel started working well on stable Rust. Other than that, unless you're doing embedded stuff or SIMD, you should be fine on stable.

Unfortunately, Rocket does not appear to be on track to work on stable Rust for the foreseeable future.


I was hoping with serde being on stable things would settle down. What's keeping rocket on nightlies?



This issue has been greatly reduce since Rust 1.0 came out as more language features are stabilized. Just in 2017, Diesel (ORM) and Serde (serialization) have started being fully functional on stable Rust. Rocket is one of a rapidly shrinking set of libraries that relies on unstable features. As long as Rocket doesn't add a dependency on more unstable features, it too will join the ranks of stable-compatible crates soon.


Maybe it's nostalgia for pre-Web 2.0 designs but I love your website; it has character and feels personal compared to most pages I peruse.


Thanks. I've never built a website before, but now I've built a website, and a web server + cms client at the same time. I've been thinking of open sourcing the code at some point in the 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.


Couldn't you just gzip the HTML and serve it directly to the browser?


The HTML pages are generated dynamically from content in my database, in the same manner that Wordpress works. Once a page for a URL has been generated, it is indeed gzipped with zopfli and stored in a concurrent hash map so that future requests for the same content will serve the already-compressed content.

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.


I want to believe. I love Rust. I feel like Rust is the language I've waited for all my life.

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]));
        }
    }
There are three distinct reasons why everything has to be "unsafe." Unless you have a lot of experience with Rust you are NOT going to figure that out until you've banged your head against the compiler for some time doing your level best to minimize the lines of code you've wrapped in unsafe, and then finally surrender.

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.


I think you noted one of the problems Rust is going to have with adoption: its raison d'être is solving technical debt (specifically, security debt).

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?"


It does keep rising in popularity, but is that coming from folks actually using system languages like C, C++, Ada, and Forth? I'm guessing only a portion. There's a difference between a web developer using Rust enthusiastically for hobby projects and a seasoned C coder switching to Rust for a professional job. In fact, a lot of the projects I've seen in Rust (ex: Dropbox) are commonly being done in Go as long as the GC isn't an issue.


Rust is the first language since C++ that can improve/not hinder runtime speed while making development safer, so I definately see its future.

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 only problem is that the compiler is very slow now, so it doesn't scale to large code bases

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.


While your suggestions work at some companies, it's not a good solution for every company:

https://www.wired.com/2015/09/google-2-billion-lines-codeand...


A single repo can have lots of crates


I believe incremental compilation is already being worked on, which should speed up your compiles (well, the first compile would be slow, but subsequent compiles would be faster).


A limited form of incremental compilation is already available on nightly. And yes, more is coming.


Dlang ?


In Dlang you either opt for slower garbage collection or get back to manual memory management where you don't get any advantage compared to C++


Compiler speedup is in the roadmap.


You have a point. I've done medium-sized C projects in my degree, but my professional background is mostly web.

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...


Why use Rust for web development? There are very few web back ends in the world that need the speed of C++ or Rust.

Java, C#, Go, Haskell, OCaml are much easier to ramp people up with and hire for.


If rust ever gets to the point where it's not much harder to write than java/c# then why not got for the fastest one and avoid performance death by a thousand cuts? A millisecond here and there can add up.

And then there's the environmental cost of slower code. How many tonnes of CO2 emissions are higher level languages responsible for daily?


> If rust ever gets to the point where it's not much harder to write than java/c# then why not got for the fastest one and avoid performance death by a thousand cuts?

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 not saying this makes Rust as easy as Java or C#, but I don't think `Rc`/`RefCell` types are the cause, nor for that matter the solution to the cause.

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.


> 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.


A friend pointed out some reasons, in particularly the safety stuff, that would make Rust unsuitable.


:-) I've been trying to keep the nuance in my comments here. When I said, "I think that if you want to use it for web stuff you very much can," I'd emphasise the, "if you want to."

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.


Rust is also pretty attractive for use in AWS Lambda and Google Cloud Functions. It's ability to strictly control memory usage and make the most of CPU resources is really powerful in an environment where you're billed based on memory and CPU time.

If you've got a particularly hot lambda function, rewriting it in Rust is a pretty simple way to save a bunch of money.


Exactly. Sneak some Rust code into your business-critical systems for that extra job security! :)


Most C++ developers won't easily develop systems in Rust because of lack of well-known libraries and a stable ecosystem(profilers, static analyzers, concurrency tools, many skilled and mediocre developers, etc). C++11 and subsequent versions have a good amount of memory safety(though not as safe as Rust).

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.


I'm not sure what "concurrency tools" are. Profiling tools that work on C++ should work on Rust just as well; "perf" and "sysprof" do, at least. "static analyzers" are far less important in Rust since the compiler prevents most of the bugs that C++ static and dynamic checkers look for. Having said that, ASAN and TSAN do work with Rust!

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.


Like... Cobol... 'cause all those reasons are vanishing and will vanish.


Those who need Cobol use them(Core banking applications).

Rust is better than C++, but it's not extremely better than C++.


Extremely safer seems to me to be extremely better, these days.

System76 is using Rust now for automated testing and firmware flashing. I wrote these projects in rust, and I enjoy using it, can't say much about the other engineers.


Also, Redox OS is awesome :-)


Thanks ;-)


My feeling is that Rust (and/or Go) will probably supplant Java (and/or C#) in the coming age, just on the basis of the user experience alone. This past week I wasted several hours trying, and failing, to get a simple Java app up and running. Rust (and Go) have such a better end user experience that I can't see them not winning. Firing up a single executable is miles better than installing a run time, then tweaking the config to make it work, then trying to find out where it stores log files, then tweaking it again when it fills up memory, etc.

Give me a single, self contained, executable any day!


I think it's important to consider the implications if Rust doesn't become a mainstream programming language.

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++.


> It doesn't use segmented stacks so it doesn't achieve the M:N performance of Go

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.


They seem to be aware: ", but it has memory and data race safety, OS threads, and futures, so no problem."

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.


Yeah Tokio is the answer and what I'm referring to. All I meant was if you implement M:N in Rust it'll be slower than Go. I think this is probably the right answer, as segmented stacks cost you C interoperability, but it's not right for everything.


If "functions as a service" (AWS Lambda) takes hold, I think Rust will be a popular server language since you'll need services with almost no startup/warmup time.


I would say so far, yes. I would say it's pretty "mainstream" already with many companies using it in production, including Mozilla.

As big as C++/C? Too early to tell for that.


Also anyone big besides mozilla, who created it?



I don't think that counts. I'm not using c when I run grep.


They are shipping ripgrep with VS code.


But shipping a program using rust != using rust. If that was the case I've used Erlang despite never having written a single line of it because I've shipped rabbitmq.


This is a strange argument I find myself in. What do you expect me to say? They're shipping a Rust application I wrote. That's a fact. Do with it what you will.


No, it's not strange. What you wrote can be interpreted as manipulation. It's the same as replying to question "Who uses Go besides Google?" And you would reply that almost everyone use it, because everyone is shipping their apps with Docker. You see manipulation here? I don't know if intentionally or not but you did exactly the same.


FWIW, a common argument in favour of C and C++ is how it is used by pretty much everything that one runs on a computer, in exactly the same sense of "use". I think you're tilting at windmills: some people mean "use" to mean "ship" and others "write", and neither are that unreasonable.


I wasn't the first one that made that claim. And I don't know the author of the comment that made it and I am not involved with anything that author do - something you can't say yourself in context of person you are defending. I've asked couple of people about that question without suggesting the answer and all of them agree with interpretation that it's about writing software in language A, not using third party tools written in language A.

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.


"Manipulation"? Really? Please.

> 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.


> "Manipulation"? Really? Please. > 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.


> Those are not an arguments for anything.

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.


> 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.

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.


Emphasis mine:

> 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.


> I'm in this discussion with you because you're assaulting my character

"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.



That's 60 companies. Granted there's bound to be a few more but calling it "pretty mainstream" based on that seems like a stretch to me.

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.

[1]: https://www.tiobe.com/tiobe-index/


Rust fares better in other indices.


Google and Microsoft are using it.


You have any sources to support that claim? Where do they use it? In their infrastructure?


Unless you count ripgrep being shipped with VS Code as a data point of Microsoft using Rust, I can almost certainly say that the above poster is wrong.

Source: We had an email thread about using Rust on the MS Rust mailing list about a month ago.


Just check out Google's GitHub repository.


Not too sure what is meant by "mainstream" but I can see Rust getting a foothold in certain industry, such as medical, automotive or aerospace. To get there, it will need to be mature and be stable significant enough. It will also need a big player to take that first step and prove it in production.

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.


I'm big into Rust, but I doubt that anyone in security-critical industries is going to put themselves on the line by using a language that's neither standardized nor government-approved. Nobody ever got fired for buying IBM, and nobody ever got fired for picking MISRA C.


Totally agree with you. Rust is just a baby growing up. C is a middle aged guy with tons of experience. Rust just needs to catch up.


The industry I see Rust making headway into first is actual security. E.g., encrypted communications, etc.

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.


I'm an aviation enthusiast and a CS undergrad. I've always wondered what's different about code written for airplanes. Anybody have any insight ? And is there a modern replacement for ADA?


Code for Airplanes (and cars and other safety critical applications) follows a special set of rules in order to eliminate wonkiness that tends to crop up in complied programs (usually the result of undefined behavior, not always the programmers direct fault).

See: http://blog.regehr.org/archives/213 (particularly part 3)

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...


> I've always wondered what's different about code written for airplanes. Anybody have any insight?

You might be interested in some publicly available coding standards for the Joint Strike Fighter (C++) and the NASA JPL (C):

http://www.stroustrup.com/JSF-AV-rules.pdf

http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf


Ada is still under active development and widely used in applications requiring extremely reliable software.

http://www.ada2012.org/


I've used Ada on satellite programs, it's still very popular for that sort of thing. Ada has managed to carve out a small niche for itself in aerospace and I don't think it'll be replaced by rust anytime soon.

Which is fine, nothing wrong with Ada.


I would say unlikely, for the simple reason that Rust is just really hard.


C++ is hard, too. So is C, to write correctly. Hasn't stopped either of them from literally powering almost every computer in use.

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.


I think C++ is much harder actually. Making sure that the system doesn't crash means writing a lot more unit tests than what would be needed, and sometimes these problems come out in production only. I would love to switch to Rust, but it takes many years in a big company.


I agree. Learning all of C++ is much harder than learning all of Rust. C++'s saving grace is you can easily get away with learning only a much smaller portion of the language.


C++ and C are easy to get into a working state, and then you bit by bit discover your mistakes. Rust forces that information up front, and that can be problematic for people who aren't used to it ( and just want to get a back up and running, which is unfortunately too many real world systems).


Rust is a paradigm shift; "...to write correctly" most people don't start off the bat with correct IMO. The learning curve is steep with rust.


Yes, and I would say that is problematic for fast uptake. However I don't think that over the long term it is an insurmountable barrier.


It's not really hard. It's incredibly easy, from my perspective. It only took me about a week to get a hang of it -- about the same amount of time that it took me to get the hang of Go. Yet the difficulty curve progressively becomes easier and easier until it's much easier to write and maintain software in Rust than Go or even Python. Now I can regularly slap out solutions to challenging problems that would be much harder in 'easier' languages.


Rust has benefits for writing and maintaining correct code, sure. But your claim here is absolutely absurd. Rust is quite difficult to learn- anecdotally, empirically, and by nature.

Being dishonest about Rust is not going to help anyone no matter how good it is.


Rust frontloads some required learning related to shared data because of the borrow checker and lifetimes (which is different example of the same kind of frontloaded learning that comes with static type checking.)

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's entirely dishonest and ignorant to simply discredit and dismiss someone's point of view because you have it set in your mind to not believe a point of view that isn't your own. My history with Rust is proof alone that there is more to the story than you claim. I'm not the only one that has no difficulty with Rust either.

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.

http://mmstick.tk/posts/id/292


Your posts in this thread are good examples of how the "Rust Evangelism Task Force" meme started: it's great that you're enthusiastic about Rust, but you're not tempering your enthusiasm with pragmatism nor with empathy for your audience, like, for instance, the core team does.

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.


It is all a matter of mindset, but you are blindly ignoring the fact that it takes effort to learn a new mindset. Maybe it went smoothly for you and that's fine (though I suspect you're just not remembering it, perhaps willfully). In fact it went relatively smoothly for me as well.

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.


I had zero issues learning and then creating software with Rust shortly thereafter. In fact, we even have recent threads in the Rust user's forum from people that have picked up Rust and already have some software solutions implemented it on day one. To claim otherwise is just denial.


Good thing nobody's claiming otherwise, then. Quit trolling (or, on the off chance you're sincere, learn some basic logic).


Seems you need to learn what trolling and logic are before using those terms.


Probably. But why do you care? If you like it then use it and build something. If you don't like it, use something you do like and build something.


Why you might care is that if you build something today, that something could reap some benefit in the future from the language becoming "mainstream".

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".


For point one, it helps that Rust is one of the easiest languages I have ever worked with to install the compiler run-time, pull dependencies, build, run, and distribute. So at the very least, it won't get in your way if you just want to distribute a static binary, or give your users a few commands to compile it themselves, even if it is "some weird language".

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.


Unfortunately Rust uses an LLVM fork IIRC, so using it is non-trivial.


We can use (and have tests to ensure that it works) a stock LLVM as well.


It is


Certainly more then Nim.

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...


> I'd say, before Rust becomes really mainstream, we have to wait for the current generation of sysdevs to die.

Why?


Of old age I mean.

It's like with everything. Most people simply do what they always did, most never reinvent themselves.


> Of old age I mean.

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.


It's a pattern that's been well documented in the scientific community. You generally get a burst of innovation when enough of an older generation of scientists dies off for their ossified cognitive habits to stop holding back the more correct of the theories that have arisen in the mean time.

(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 think it has a fair chance (Go is a "systems" language and grew very quickly). I also believe you'll see it pop up in unikernels as well. Why, you ask? Because there's always 1 person that starts a project that gets traction.

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.


> if you need segfault protection, you're a bad programmer. 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

sigh Please look at the "trophy case" here: http://lcamtuf.coredump.cx/afl/


My views are the responses you'll probably get from the people who've been doing systems programming in C for the past 20 years. I don't doubt lots of common applications have memory issues. Maybe not a definite segfault but it's incredibly disingenuous to act like it's a major issue (as if writing C and C++ are similar to disarming a bomb or something). It's nonsense and the same reason I have been learning C++17's stuff rather than bothering with Rust.

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.


You're being so rude and inflammatory, for no reason. What's so frustrating is how you're convinced that everyone else is an idiot.

> 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.


> 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?

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.


> 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.


> reflecting our current understanding and knowledge on how to build safe system...


Browser engines are more indicative of the current "understanding and knowledge of how to build safe systems" than nearly any C++ codebase in existence.

Part of the current "understanding and knowledge of how to build safe systems" is to use a memory-safe language.


Despite all the flashy tools that proponents of C and C++ claim that makes C++ as safe as Rust, it's not doing any good at stopping the exponentially-increasing amount of vulnerabilities and crashes that are being reported over the last few years.


You have no data at all to back this up. The vulnerabilities you speak of are, far more often than not, written in old-style C and C++. That doesn't make Rust a bad idea, but it does mean your claim is completely unsubstantiated.

Advocating for Rust by lying is not going to help anyone.


This is the same line of logic and statements repeated by C and C++ programmers that shortly thereafter get showed up with a list of CVEs in their 'modern C/C++' projects. Remember the recent Curl developer PR disaster?


Yes, it's the same line of logic because it's correct.

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.


You've living in some serious denial. You were given a point that proves that your line of thought is incorrect, and you continue on to completely ignore that point by stating that it is correct. So tell us, o'wise one, why is that top C and C++ projects are continually riddled with CVEs, crashes, and other severe issues that are 90+% the fault of C and C++? Why is it that veteran, experienced C/C++ programmers are still making these same mistakes 20, 30, and even 40 years into their careers?


I think it's too early to tell if rust will prove any better in the real world, which includes things like devs using unsafe sections to cope with time pressures.


Use of unsafe in Rust is not required or recommended in most, if not all situations. That said, auditing a handful of small unsafe blocks is easier than auditing an entire project.


The question then is whether large chunks in unsafe is still better than the entire program in the equivalent of unsafe (C).


> 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.

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


You seem to be presupposing that all, or much of the C/C++ written today will follow best practices and be written by "expert" programers. A portion will, perhaps even a substantial portion, but I'd be willing to wager a far larger portion of the Rust written today will follow best practices and doesn't have to be written by expert programers. This is because the safety in Rust isn't optional, like it is with C/C++ best practices/new features.


> You seem to be presupposing that all, or much of the C/C++ written today will follow best practices and be written by "expert" programmers

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.


> My views are the responses you'll probably get from the people who've been doing systems programming in C for the past 20 years.

I've been doing systems programming in C for 20 years. I disagree with your claim.


> Ridiculous - if you need segfault protection, you're a bad programmer. Let's be honest, you don't segfault unless you're doing something idiotic.

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 think the bad programmers are ones who state "segfault protection" as a feature of Rust because they read it on Rust's site. I genuinely don't think these features of Rust are really all that useful (they're being disingenuous; acting like C++ is some primitive language where you segfault every 5 minutes). Even Bjarne would probably agree. He talks about the same issue at his "The Essence of C++" talk. Someone asks if he shares the blame, alongside Ritchie, for all of today's major security issues (Heartbleed is the given example). He says something similar to what I've said. Segfaults are not a major issue at all unless you're consciously doing something idiotic.


I don't disagree with you in that well-written code should make invalid memory accesses rare. And I don't disagree that, if you write good C++ (and I've stumped around here for C++ because I really didn't learn it until C++11 and have never had an environment where I didn't have the tools to write good C++), they are. But I feel, and pretty strongly, that Rust makes it a lot harder to write bad code in general. Memory protection is just one of the ways this is true.

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 agree, that was rather brash. They're not bad programmers. I tried to clarify that in my previous comment.

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.


But they're good features, mftb. I have to say that as an experienced (some might even say skilled) C++ developer I would go for pretty much all of them.


> I genuinely don't think these features of Rust are really all that useful (they're being disingenuous; acting like C++ is some primitive language where you segfault every 5 minutes).

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...


>Let's be honest, you don't segfault unless you're doing something idiotic.

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.


> A sign of a good language is to as much as possible make invalid states illegal by design

This is exactly the insight that will probably (if I can help it) keep me from leaving the functional language space ever again.


Even if only "bad programmers" segfault (debatable - especially depending on the type of code you are writing), most of the software written in the world is not made by amazing programmers who never segfault. It doesn't matter your opinion of the developer in question when a buffer overrun happens and your data gets stolen. Encourage people to write code with less safety at your own peril.


> (1) Ridiculous - if you need segfault protection, you're a bad programmer. 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.

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.


For the uninitiated: Google dedicates a whole cluster of machines to finding memory safety bugs in Chrome. Finding segfaults is part of their work flow.

https://dev.chromium.org/Home/chromium-security/bugs/using-c...


when I think of all the segfaults I've seen in last few years - it's usually been in some horrible bindings to unsafe C/C++

"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


Look up the longest list of security advisories you can find, and then tally what percentage of them are based on "buffer overflow" bugs.

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?


>"I don't think there's much incentive post C++11 to really consider porting anything (even small things) over"

I am curious why specifically C++ 11? Could you elaborate?


Let's look at Rust's homepage: - Zero-cost abstractions - C++, in my opinion, is the founding father of zero-cost abstractions. - Move semantics - we've had this since C++11. - Threads without data races - C++11 introduced a threading library as part of the language. We can avoid a lot of data races, deadlocks, etc. if you actually look deeper into how to implement the modern threading library well. - Efficient C bindings - this had to be listed because we all know the world relies too much on C at the moment for this not to be a feature. C++ is almost a perfect superset of C, fantastic.

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.


> - Move semantics - we've had this since C++11.

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.


> 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.

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...


The parent correct: C++ runs destructors on all local variables, even if they have been "moved from", so it must be valid to do so. This translates into a null/"valid invalid"/sentinel state that the destructor can check to avoid truly destroying the underlying resource (which could result in double-freeing memory, or double-closing a file, or some other undefined behaviour). For instance, moving out of a unique_ptr will swap in NULL, and the destructor checks for that.

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).


> > omitting the constructor call

Oops, too late to edit but that was meant to say "destructor."


> - Threads without data races - C++11 introduced a threading library as part of the language. We can avoid a lot of data races, deadlocks, etc. if you actually look deeper into how to implement the modern threading library well.

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.


> The reason people cite memory safety as a feature of Rust over C++ is because you get it for free

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.


For an experienced C++ dev it might not seem sensible. I can appreciate your viewpoint here.

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.


Thanks for the detailed explanation. I appreciate it.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: