Live data from Hacker News

One year of Rust

blog.rust-lang.org

101–110 of 110 posts

Re: One year of Rust

#101
post #97

Earlier quoted context omitted.

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/is…

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 ?

Re: One year of Rust

#102

Earlier quoted context omitted.

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.

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.

Re: One year of Rust

#103
post #21

Earlier quoted context omitted.

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

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.

Re: One year of Rust

#104

Earlier quoted context omitted.

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/is…

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

Re: One year of Rust

#105

Earlier quoted context omitted.

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 tha…

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.

Re: One year of Rust

#106

Earlier quoted context omitted.

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.

Re: One year of Rust

#107

Earlier quoted context omitted.

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.

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.

Re: One year of Rust

#108

Earlier quoted context omitted.

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.

Re: One year of Rust

#109
post #48

Earlier quoted context omitted.

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

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.

Re: One year of Rust

#110

Earlier quoted context omitted.

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).
Post reply on HN