One year of Rust | Hacker News Reader

One year of Rust

blog.rust-lang.org

321 pointssteveklabnik106 comments

> While much of Dropbox’s back-end infrastructure is historically written in Go

I'm sorry, but much of Dropbox’s back-end infrastructure is historically written in Python, not Go. Go is a new addition to the stack. Only a small and very specific part of Dropbox is written in Rust, where things like an effectiveness of CPU caches becomes important. Other back-end code is still being written in Go.

I think it depends on what you mean by "historically". My understanding is that the server-side was largely in go for a long time now, but you're also right that before that, it was Python.

While you're right that it's a small and specific part, it's also the core of the whole thing, so it's a very significant part. Dropbox isn't moving away from Go generally any time soon, as far as I know: it's still very much the default.

> server-side was largely in go for a long time now

I guess I call "a new" what you call "a long time now". Dropbox is using Go for about 3 years.

Yeah, maybe that's entirely it. Words are tough. :)

So Dropbox is no longer using Python for it's backend code ?

Yeah, this extract does feel a little out of place and almost like a dig at Go. I'm sure it is not but a little clarification wouldn't go amiss.

To my knowledge Dropbox's backend is migrating (slowly) from Python to Go (new default), with Rust for some specialist features where the memory management model is preferable.

One year since stable? It feels like five years for the level of maturity they have achieved.

I was confused by that, apparently it's one year since the first stable release.

Except the tooling, could be better. A language like Rust will benefit from a rich IDE a lot.

But still the language is great.

With this speed of development, I'm pretty sure it is coming.

actually idea-rust made great progress, yes.

I'd say the tooling is pretty great only with the exception of an IDE. Debugging, building, testing, packaging all seems pretty well handled.

packaging will work great if you don't rely on any unicorn library that will put their dylib/so files in some ugly path's that aren't standard. (FFI only) actually not the worst thing for most people, but linking against a paid library will mostly end up with setting LD_LIBRARY_PATH at some point.

A big pain is still JIT compilation. Last time I used rust, even small changes to code required a full re-compilation.

To be clear: Rust doesn't have a JIT. But we've been doing a lot of work on incremental recompilation, which will fix this problem. (Or rather, we've been working on the precursor requirement, MIR.)

To be extra clear, a crate is the unit of compilation in Rust, so changing your code means that the whole crate it's in needs recompiled; your dependencies won't be. Or, if your project is split up into multiple crates, the other ones won't. Incremental recompilation will reduce this level of granularity such that the whole crate won't need to be recompiled.

Are you sure you mean JIT rather than incremental compilation? The former is a pretty different concept that AFAIK Rust has no implementation of.

I think we are likely to see better incremental support with the recent development of MIR, but I'm not sure what the current plans are. Should help tooling around the language generally!

You are correct. I doubted JIT was the right word at the time but couldn't think of the right term. Incremental support is what I mean.

> Debugging, building, testing, packaging all seems pretty well handled.

Eh, debugging is a mess, at least on OS X. Rust advertises LLDB support, but it seems semi-broken. Listing source is non-functional and just setting a break-point requires a lot of hand-holding.

Bug reports of specific problems would be very appreciated! We emit fairly complete DWARF, but debuggers tend to be finicky about the exact subset of DWARF they accept.

I'll try to submit a report later. It's exactly what it sounds like, though.

    $ cat hello.rs
    fn main() {
	println!("Hello world!");
    }
    $ lldb -v
    lldb-350.0.21.9
    $ uname -a
    Darwin mycomp 15.5.0 Darwin Kernel Version 15.5.0: Tue Apr 19 18:36:36 PDT 2016; root:xnu-3248.50.21~8/RELEASE_X86_64 x86_64
    $ rustc --version
    rustc 1.8.0
    $ rustc -g hello.rs
    $ ./hello
    Hello world!
    $ lldb hello
    (lldb) target create "hello"
    Current executable set to 'hello' (x86_64).
    (lldb) source list
    (lldb)
    (lldb) b 2
    error: No selected frame to use to find the default file.
    error: No file supplied and no default file available.

I don't see how the core team could be unaware of this unless literally no one has done even a cursory glance at OS X & LLDB in months.

Well, I do use it regularly for testing Servo. There's a debugger harness run as part of the test suite too. (Not to say we shouldn't fix whatever is causing your problem, though!)

I can make it work if I feed full file paths to the debugger using syntax I can't remember off the top of my head. Maybe that's one way some scripts might be functioning?

I'll copy and past this into a Github issue when I have a sec.

edit: https://github.com/rust-lang/rust/issues/33674

Thanks! Forwarding to the appropriate people.

I think this is a known issue relating to some lldb versions no longer treating unknown languages as C; which got fixed in lldb upstream but may not have been released yet.

Ok, maybe I've been too spoiled by Visual Studio, but debugging without an IDE? That sounds extremely painful to me.

I really wish that Jetbrains had a Rust IDE. I love their Go, and Erlang plugins for IntelliJ, Java with IntelliJ, and Clion with C. Without them, I don't think I could be anywhere as effective as I am.

I tried to pickup Rust, but I was super frustrated by the code/compile/run cycle with the current plugin. But, hopefully more users will make that better.

Jetbrains Rust IDE would genuinely make Rust my go-to language for pretty much every task I can think of.

Couldn't agree more! There's some work ongoing on a third party Rust plugin for InteliJ but it still has a long way to come.

There is unofficial plugin: https://github.com/intellij-rust/intellij-rust and works very well: https://www.youtube.com/watch?v=mHa7QlFz7io (small video recorded by me)

Is that Racer happening? It look like there is still a lag in the completion suggestion... and that is a huge problem (mainly when using it as to find things).

No, this plugin works without Racer. I use it every day and I don't see any problems with code completion. Except of cases where code completion isn't supported yet :) But it's all personal and better to try - it's free.

To clarify: I'm not author of this plugin.

And I tried Racer with Microsoft Visual Code plugin - it works without any lags, very fast. Just fails sometimes :)

Not as great as a full IDE, but Atom.io + tokamak(https://vertexclique.github.io/tokamak) + atom-ctags(https://atom.io/packages/atom-ctags) get you a decent editor/light IDE setup.

I agree however that it would be nice to have ie lifetimes visualized and stuff like that, hopefully sometime soon...

> Except the tooling, could be better. A language like Rust will benefit from a rich IDE a lot.

I just found this link[1] for a pretty complete Emacs IDE-like setup the other day. I'm not a Rust programmer, but it seemed promising enough that it made me want to give it a spin.

[1] http://julienblanchard.com/2016/fancy-rust-development-with-...

I'm not into IDEs, so that doesn't bother me. But by tooling I'd understand cargo. It is improving.

Replied in the wrong child.... May want to give VS Code + RustyCode[1] extensions a look.

[1] https://github.com/saviorisdead/RustyCode

I actually find the tooling to be quite decent. VSCode + Racer has worked pretty well for me so far.

I'd say rustdoc is pretty rough. It's very hard to navigate the rust stdlib vs, say, Go, and when you do find what you want, it's often specified in some very cryptic manner that seems to require a PL PhD.

It is a really big barrier to adoption because it's very hard to find out what functionality is or is not offered. Here's an example: I want to iterate over a set. Easy, right?

No.

http://static.rust-lang.org/doc/master/std/collections/hash_...

Look at the signature for Cycle. It's really hard to know what this does even though it's trivial:

fn cycle(self) -> Cycle<Self> where Self: Clone

When you click through to the real documentation, it describes a useful use case for this. But that's not how programmers think. They think "I need to do X right now so I'll find something that looks right" not "I'm going to click through the documentation... oh X looks interesting I'll remember that later". There's no way to infer what Cycle really does without having actually clicked through or used it.

If you (or anyone really) has specific thoughts here, that'd be super great. Rustdoc's output could use a lot of love, but we haven't figured out exactly what we want to do with it. And having worked with it daily for a few years now, I'm personally a bit blind to its shortcomings.

Specific thought: Trait implementation pages like http://static.rust-lang.org/doc/master/std/collections/hash_... should output the first paragraph of the documentation text. That way you can easily scan/Ctrl+F through the documentation that's right next to the struct you're interested in. Reduce the number of clicks and context switches.

It's just a pretty terrifying way to output right now.

Ah, just saw your edit. So, to be clear about what you mean, you want the Iterator implementation to show the summary line on this page? Seems reasonable to me! I filed a bug: https://github.com/rust-lang/rust/issues/33672

(Also, that page is a bit sparse because I haven't gotten around to writing any docs for it yet, so it's just the autogenerated stuff.)

Yeah, once you actually get to the text, it's really good and clearly improved from 12 months ago when I last got the free time to play around significantly.

Thanks for the bug ticket :)

Made a PR: https://github.com/rust-lang/rust/pull/33679

I actually get the opposite feeling. Maybe that's because I'm so used to rustdoc now, but it's super easy to find everything. Go's doc tool seems like just a giant dump of API signatures.

Rustdoc isn't perfect, but it's pretty easy to find things imo.

> fn cycle(self) -> Cycle<Self> where Self: Clone

I agree that a summary would be good, but this doesn't require a PL Ph.D. It means "cycle is a method that moves its receiver and returns a Cycle object of the same type of the receiver, and only works if the receiver is cloneable". The trickiest thing here, IMHO, is move semantics, which is something fundamental to Rust in general.

Yup, I've got the same feeling here.

If you've spent more than a cursory time with Rust this is pretty straightforward.

You'd represent this in Java(minus move semantics, because Java has nothing like that) via:

  class IntoIter {
    public Cycle<T extends Clone> { ... }
    ...
  }

Where Clone is just an interface that knows how to clone its value.

Fair enough; some more noodling over the signature made it a bit more obvious than it seemed banged out at the back of an OSCON presentation.

I think the point still holds. Maybe just not for that one.

The thing is what you linked is the docs of an implementation not the interface.

I guess I've just had a different experience. I come from almost no PL/ML background and I've found the Iterator interface in Rust(along with Option/Result) to be some of the most impressive, clear things about the language.

Perhaps there's room for a rust equivalent of cdecl, a tool to map rust to plain English descriptions, offering a gradual onramp to the syntax.

This kind of thing seems silly to experts but could raise the rate at which folks make it through language learning funnel.

I agree that the rust docs need work, but I disagree with your example. cycle is just a method defined as part of the Iterator implementation - it's just like a method you might define to implement an interface in Java. JavaDocs actually have the same layout as the Rust documentation in this case: you have to actually click on the method to find out how it works. This is also how docs for other languages are often laid out as well.

I'm surprised, I find Go's doc generator to be very rudimentary. For example, you can't find the implementations of an interface, and given that interfaces are used often I have to resort to grepping the code to see what it means.

> I want to iterate over a set. Easy, right?

yes, it is easy, `for value in &set {}`. Not sure why you went all the way down to `Cycle`

In this case I agree that perhaps rustdoc should note that a full description should be alluded to (the full description of Cycle is on the Iterator trait's docs), but it's still IMO much better than go

Well, it has been around for about that long. The "one year" is since the stable release 1.0.

I meant since the stable release in fact.

Rust has been in development for almost a decade at this point; but the language changed significantly many times before 1.0. It's been one year since the 1.0 release, which is the language we know today as "Rust". All those older languages are dead and gone now.

I'm actually doing a talk about the ACM's Applicative conference in NYC this year talking about the history of Rust.

This is one thing that's a little annoying to me. I know if I develop a Rust app today I can't leave it alone or it will decay horribly.

That should not be true. 1.0 meant that we stopped breaking things on a daily basis, if your code runs on stable today, it should run on stable tomorrow, modulo any soundness fixes (of which we have had two or three this year, which were all trivial to update).

If it is true, please file bugs. We do our best not to break people's stuff, going to pretty extreme lengths compared to many other ecosystems.

and occasional other breaking compiler bug fixes that are not really soundness fixes.

> This is one thing that's a little annoying to me. I know if I develop a Rust app today I can't leave it alone or it will decay horribly.

No, it won't. Rust has been stable since 1.0, as the article itself mentions.

Good news for you: this is a complete misconception. Rust has been stable for a year. With a minor caveat for actual bugs in the language, your code will compile on all Rust 1.X compilers from now until the end of time. Upgrading Rust versions has been a breeze.

You're overstating the stability guarantees. The Rust project has formulated it as “hassle-free upgrades” which seems to imply that small, simple edits may be necessary when upgrading to a new Rust version.

That's only for changes that are important, though: we don't make unnecessary changes.

Agree. It's important to underscore what was promised and what was not. Otherwise you might get the impression that a promise was broken (when it was not).

That's gotten much better since 1.0. Prior to 1.0, you needed to revise your Rust program about once a week so it would compile. Now the language has settled, but the libraries are still churning.

One of the big advantages of Go is that it comes with a coherent set of libraries from a single source (Google) that do most of the things you'd want to do on a server. Rust is more like Python; many people write libraries, many of which overlap and some of which work.

The advantages of having a distributed ecosystem vs. having a monolithic standard library is an extremely polarized topic, and I don't want to start that debate.

But I do want to emphasize that Rust libraries follow semver, and the lock features of Cargo mean that your builds are always reproducible and you upgrade only when you want to. Your code will never stop compiling one day just because some library "churned".

"Rust is more like Python; many people write libraries, many of which overlap and some of which work."

Odd comparison, Python actually has quite a comprehensive, well used standard library, which usually gives you enough to get going.

Using NodeJS as an example would've made more sense, where most libraries/modules are user written.

That was true prior to last year's 1.0 being released, but since then code no longer breaks, (in any major ways anyway, there's been some soundness fixes for the good of the language's future). Also, the Rust teams runs any potentially breaking changes against the crates at crates.io and they even sent fixes to existing crates in the past.

Will that talk be available online at some point?

I hope so. I gave it at FOSDEM in 2015, only intending to give it one time, and then they lost all of the video from the keynote track :( So I'm giving it again there to hopefully get it on the record.

That was a really good talk, one of the highlights of that FOSDEM for me.

Thanks so much! I was so sad when they lost the recording :(

For the record, I take issue with the "almost a decade" label, development on Rust didn't start in earnest until 2010 at the earliest. :P It's about as misleading as saying that Go is 40 years old just because its commit graph goes back that far (https://github.com/golang/go/graphs/contributors).

It depends on how you define "in earnest". Graydon started in 2006, which is a decade, though obviously it was very slow at first. My "almost" is an almost because of those personal project years. YMMV of course :P

The 4 commits before 2008 are pretty clearly not development on Go in any sense, they appear to be Brian Kernighan playing with the syntax and styling for a C "hello world" program: https://github.com/golang/go/commits/master?page=810

No one would say those commits show he was working on Go as a "personal project" during that time.

And I guarantee that none of the Rust commits from before 2011 survive to this day, because the compiler was rewritten from scratch in 2011. :P A different argument could say that Go dates back to 1995, because Go is essentially an evolution of Rob Pike's language Limbo.

So maybe you know why it's called 'rust'? I can't find any reference to it. Such a horrible name for a new programming language.

There's no one reason. One is the "rust" group of fungi. Another is that Rust isn't cutting edge; it uses ideas that have been around a while. And so on.

One thing I'm really hoping to see happen in Rust is more development to make it more "functional," as in suitable for a functional programming style. It's already so close and, while I don't want to bring up the higher-kinded types discussion, things like stronger support for closures being returned from functions are just not quite there yet for me.

I filled out the survey that was sent around and mentioned some of my concerns about missing crypto-in-Rust code and some of the shortcomings of the documentation. I'm pretty happy I'm not the only one mentioning one or both of those things, because it makes me hopeful that we'll see improvements soon. In particular, regarding docs, I've found it rather difficult to go from reading a type signature and brief explanation of a function/method and being able to actually use it, as a beginner. For example, when I tried to figure out Hyper, it took me a long time to realize I could use pattern matching in my function signatures to capture a mutable reference to something that Hyper was giving me ownership over. I feel silly having missed that, but being a beginner just referencing the Hyper docs, I really struggled.

Does anyone have more information about the crypto situation? In particular, I use ECDSA 384-bit for a lot of the code I write at work and have only been able to find the Ring library, which doesn't seem to feature signing yet. If I could get some high-quality, audited crypto code (or heck, even just some nice Rusty wrappers), I'd be so close to ready to use Rust at my day job and for more personal stuff as well.

I think this ship sailed when Rust removed function purity. Rust is a Scala, not a Haskell.

So I'm actually not super familiar with Scala. I do know Haskell a little bit. Could you elaborate on what you think the implications are for Rust's development down the functional route are? I've heard about the potential for support for higher-kinded types, which makes me think there could actually be a strong incentive to be able to do more functional programming in Rust if people started working on monad implementations and such.

There was a very nice comparison between the type systems of Rust and Haskell a few days back on reddit: https://www.reddit.com/r/rust/comments/4jh8hv/question_about...

Nah, Scala does support higher-kinded types. :P Rust just isn't an especially functional language, though it may seem that way relative to C.

The grandparent was probably referring to the fact that Rust allows mutation and side effects, which Scala also does. "Functional" is not a very meaningful term, but Rust has about equivalent support for higher kinded polymorphism as SML or OCaml (in that there is no first class support but another language feature can be used to implement it), which are certainly functional languages. And of course, many lisps are considered functional languages despite not having types at all.

Having started functional programming with Lisp and Caml Light, with Prolog on the side for logic programming, it feels strange this modern notion that Haskell is the be all and end all of FP.

The "return a closure" part is still awkward, due to lack of boxing by default. You can do what you can do in many functional languages today, there's just some syntactical overhead. There's an RFC that will fix the ergonomics, while also increasing performance by removing the boxing.

We're in the process of starting up a docs subteam, and one of the things we're interested in is helping the broader ecosystem get better docs. It's also possible that part of my job writing docs will eventually move towards contributing ecosystem docs, but gotta finish up the official distribution first.

Crypto is tough: it's very, very important to get correct. Right now, most projects use wrappers over OpenSSL, but having it all in pure Rust (and maybe some asm where appropriate) is, of course, the dream...

Returning unboxed closures by way of some form of type abstraction seems like its on the table in the next year. Higher-kinded polymorphism will be a more gradual process.

There are some libsodium bindings that you can use[1]. Otherwise, there's not a ton of "Made In Rust" crypto libraries, though I know some are being written. I myself am working on a prime number generator library[2], which is fairly usable in its current state.

1. https://crates.io/crates/sodiumoxide 2. https://crates.io/crates/pumpkin

Hey HN, do you knoe Any notable projects or startups using Rust? Web, desktop apps, scientific or algorithmic computing etc?

They've actually been collecting a list of companies using Rust in production: https://www.rust-lang.org/friends.html (It's also mentioned in the post.)

The most notable Rust project I know of is servo, the browser written in Rust.

https://github.com/servo/servo

It is a massive undertaking and it's already sort of working in many regards.

TFA mentions a couple of projects.

See https://www.rust-lang.org/friends.html for a list of companies using Rust (perhaps most notably Dropbox and Mozilla), but here are some non-corporate projects off the top of my head:

Panopticon, a cross-platform disassembler: https://panopticon.re/

Redox, an everything-is-a-URL microkernel OS: http://www.redox-os.org/

Piston, a modular collection of libraries for game development: http://www.piston.rs/

Pijul, a next-gen implementation of Darcs: http://pijul.org/

Xi, a high-performance text editor: https://github.com/google/xi-editor

timely-dataflow, "a low-latency cyclic dataflow computational model" (i.e. big data shenanigans): https://github.com/frankmcsherry/timely-dataflow

Dropbox is using Rust for file storage:

https://news.ycombinator.com/item?id=11283538

http://www.wired.com/2016/03/epic-story-dropboxs-exodus-amaz...

I've tried to learn Rust twice because i think it's great idea (memory safety with C++ performance) BUT... Rust seems even more complicated than C++ for me, really i find C++11/14 a lot easier to reason about than Rust. I am not sold on functional programming also. Dangling pointers/memory leaks are problems of C and old C++ but not modern C++. I don't remember when i last seen any memory problems in modern c++ code base where ownership is encapsulated inside smart pointers. I think Rust is great and would have a lot more attention and adoption if version 1.0 would ship in 2009. I think Rust is too late into the game. That's why probably only mozilla is really using it and dropbox for really small part of their infrastructure from known players. From what i researched big part of "friends" that use Rust in production are using it because of hype? I am not sure exactly why but some of their use cases for sure not need systems programming language. Maybe it will not end up like D which tried to solve similar problem.

EDIT: It's funny how people down vote my personal feelings about the language without any anti-argument or comment. It seems having other opinion than "Rust is GREAT" is not desirable here.

Probably getting downvoted because the assertion that modern C++ solves memory leaks is getting kind of tired as far as Rust discussions go, and is also missing the point.

Rust doesn't solve memory leaks, it solves memory unsafety- things like use-after-free and iterator invalidation that modern C++ does virtually nothing to help with, and that vulnerability statistics show are still huge problems with programs written in C++.

I wrote something on the memory leak vs. memory unsafety confusion a while ago, for those interested in exploring it more: http://huonw.github.io/blog/2016/04/memory-leaks-are-memory-...

I don't see usage of new/free without encapsulation, this is not modern c++ which invalidates your point. Using naked new/free is depreciated in modern c++ and is problem of C not modern C++. What kind of statistics? Can you give any links that support what you wrote? All memory leaks/buffer overflows that i saw lately are associated with C (openssl, libc etc) not with C++. For iterator invalidation there are couple of simple rules to remember or for example you can use std::insert_iterator that will not be invalidated even if relocation occurs. You could use static analyzer and would avoid most of the problems.

EDIT: My point is that i have nothing to gain from rust when knowing c++ and memory management rules + i got good static analyzer. But probably for someone that do not know C++ at all Rust could be a better choice.

Sticking the free in a destructor doesn't help you at all with memory safety, it just makes it easier to avoid leaks.

Simple rules are, again according to the evidence, not good enough. There are simple rules you can follow in C as well. The benefit of Rust (as far as memory safety goes) is that the compiler enforces those rules.

In fact, the mechanism by which it does this (lifetimes) is typically what makes Rust seem more complicated to beginners. But the fact is, that complication is still there in C and C++, the compiler just lets you deal with it all on your own.

Yes i understand what your point is. I do not need to know/remember certain rules because compiler is doing this for me in Rust, my point is that if someone knows those rules in C++ and have good static analyzer he can get similar safety.

I will try third time with Rust, i just feel sometimes like in shackles in Rust, i would like to say to compiler hey i know what i am doing, like i can do in C++.

> my point is that if someone knows those rules in C++ and have good static analyzer he can get similar safety.

No. The entire history of large-scale security-critical applications in C++ disagrees with you.

> I will try third time with Rust, i just feel sometimes like in shackles in Rust, i would like to say to compiler hey i know what i am doing, like i can do in C++.

That's precisely what unsafe is for.

Once again show me something that proves what you wrote, where is your history of modern C++ that proves that? No one provided any link.

Here's Mozilla Firefox, search for "use-after-free", "memory safety hazard".

https://www.mozilla.org/en-US/security/known-vulnerabilities...

Here's Google Chrome, search for "buffer overflow", "Use after free", "out-of-bounds":

http://googlechromereleases.blogspot.com/search/label/Stable...

Edit: Chromium bug tracker talks to me now, query for "use-after-free" has 2157 results:

https://bugs.chromium.org/p/chromium/issues/list?can=1&q=typ...

Once again, show me ONLY modern c++ code base. Those are mixed with old C++ code base.

Still waiting.

And read how chromium use C++11... (https://chromium-cpp.appspot.com/) + google style guide that is prehistory and NOT considered good in community.

Maybe try with proxygen, rocksdb, folly from facebook ?

> Once again, show me ONLY modern c++ code base. Those are mixed with old C++ code base.

These security flaws are in code that has used smart pointers for years and years.

> And read how chromium use C++11... (https://chromium-cpp.appspot.com/) + google style guide that is prehistory and NOT considered good in community.

It doesn't matter from a security perspective. In fact, I think C++11 is actually less safe than C++03 with custom smart pointers, because use-after-move is a hazard and lambdas make it very easy to have dangling references.

Chromium security engineers are some of the most competent engineers in their field. If using more C++11 features made their code more secure, they would do so. They don't, because C++11 doesn't make their code more secure.

Ultimately, these debates are really premised on something absurd: "assume modern C++ is completely memory safe unless proved otherwise". This is completely backwards and leads to endless "no true Scotsman" games. You need to show why C++ is supposedly memory safe. You won't be able to, because C++ is not.

> Maybe try with proxygen, rocksdb, folly from facebook ?

Those codebases aren't being attacked the same way browsers are.

But I can easily find use-after-free in them too with Google: http://code.metager.de/source/history/facebook/folly/folly/i...

Indeed you have found ONE, Good job.. I didn't say modern c++ is memory safe, did I? I've said couple of times that someone can use modern c++ with good static analyzer in safe way if his application is properly designed.

Tell me then if it's such a huge problem that rust solves ( that people have with memory safety) why whole world didn't switched to Rust for NEW projects? It's stable already.

> What kind of statistics? Can you give any links that support what you wrote?

Why yes, I can!

https://bugzilla.mozilla.org/buglist.cgi?o5=substring&o13=su...

Before you object, this is largely modern C++.

> You could use static analyzer and would avoid most of the problems.

> EDIT: My point is that i have nothing to gain from rust when knowing c++ and memory management rules + i got good static analyzer. But probably for someone that do not know C++ at all Rust could be a better choice.

Yes, you do. Empirically, programmers consistently make the same game-over mistakes in C++ over and over again.

Every large code base in history of the world has bugs, doesn't matter which language. What you provided proves nothing. I don't know what kind of "programmers" you are talking about maybe some from mozilla (they are known for making same shitty mistakes over and over again, i will not mention exploits over the years in firefox, breach into unfixed bug/exploit internal system etc.) but i know programmers that can write good C++ without making any memory problems and Rust has nothing to offer for them. You are just biased.

Of course every large code base has bugs, that's why we should be very concerned about what the consequences of such bugs are for users.

Please see my reply in the other sub-thread about very similar story of exploitable memory safety bugs in Google Chrome fixed in every release; do you want to continue your line of argument with a claim that Chromium developers are all incompetent too?

Reply on news.ycombinator.com