6 ms·

I would like to defend Rust here. For example, the article complains "The build is often broken or has failing tests". Rust build is basically never broken nor

by sanxiyn 12y ago

I would like to defend Rust here. For example, the article complains "The build is often broken or has failing tests". Rust build is basically never broken nor has any failing tests. Being a new language really is no execuse. This is not rocket science. You can do it too. Go read http://graydon2.dreamwidth.org/1597.html http://graydon2.dreamwidth.org/1597.html written by Rust's original author.

tenfingers 12y ago
I personally never had a failing build, and I'm following the master branch. I cannot relate to the author for that specific point. Julia seems to be reasonably unit-tested to me for being such a young project. The testing framework is very simple, but does the job. I would say that also the complaint that @test is just an assert is mostly moot: it's actually the only thing you need the vast majority of the time. Other frameworks are maturing. But if you consider the entire ecosystem (see http://pkg.julialang.org http://pkg.julialang.org), many packages that you might rely on, especially for simple operations, might break. Most of the breaking changes are developed in branches and merged when completed. Again, overall the source management is also following the best practices in this sense. I didn't really want to get into too much detail because for me most of the arguments made are ok, but it's an ongoing development effort. When new ideas are proposed, I want them to be considered, not dismissed as "breaking changes".
mijoharas 12y ago
On another point, the rust documentation is absolutely amazing for a young language (and improving! [0]). [0] http://words.steveklabnik.com/rusts-documentation-is-about-to-drastically-improve http://words.steveklabnik.com/rusts-documentation-is-about-t...
- steveklabnik 12y ago
  Thanks for the kind words. Still so much to do!
- masklinn 12y ago
  One thing I definitely miss, especially with things being split into separate extension traits (e.g. iterators a few weeks ago) is a Hoogle-like type-based search. Because finding out how to perform operations, especially very generic ones, has become fairly frustrating. Also the ability to easily search both the standard library and third-party libraries is probably going to be needed soon if nothing experimental is going to be available in the "standard track".
  - steveklabnik 12y ago
    https://github.com/rust-lang/rust/issues/12866 https://github.com/rust-lang/rust/issues/12866
bazookajoes 12y ago
Maybe I'm off base, but in this day and age I can not imagine writing a new compiler and runtime without at least 100% branch coverage and automated fuzz testing and actually asking people to use it. It is a gut wrenching feeling when code crashes in production and it is my compiler to blame. It seems so much more shameful to me then if a library or service of mine crashed, not that that isn't shameful as well. Do I need to loosen up?
- lmm 12y ago
  You need to be loose enough that you'll actually write and release a compiler, imperfect as it is. Shame can be a powerful motivator but it can also be paralyzing. As I've used more modern languages with better type systems I've moved away from high test coverage and towards writing code that simply can't go wrong (or at least, that is exceedingly limited in the ways it can go wrong); http://spin.atomicobject.com/2014/12/09/typed-language-tdd-part1/ http://spin.atomicobject.com/2014/12/09/typed-language-tdd-p... is a well-written explanation of something very close to my current approach. So I wouldn't put the emphasis on branch coverage or fuzz testing that you do. But I absolutely agree that you should have a very high level of confidence in a compiler before you ask people to use it, substantially higher than the level of confidence required of a library or service.

by sanxiyn 12y ago

tenfingers 12y ago

I personally never had a failing build, and I'm following the master branch. I cannot relate to the author for that specific point. Julia seems to be reasonably unit-tested to me for being such a young project. The testing framework is very simple, but does the job. I would say that also the complaint that @test is just an assert is mostly moot: it's actually the only thing you need the vast majority of the time. Other frameworks are maturing. But if you consider the entire ecosystem (see http://pkg.julialang.org http://pkg.julialang.org), many packages that you might rely on, especially for simple operations, might break. Most of the breaking changes are developed in branches and merged when completed. Again, overall the source management is also following the best practices in this sense. I didn't really want to get into too much detail because for me most of the arguments made are ok, but it's an ongoing development effort. When new ideas are proposed, I want them to be considered, not dismissed as "breaking changes".

mijoharas 12y ago

On another point, the rust documentation is absolutely amazing for a young language (and improving! [0]). [0] http://words.steveklabnik.com/rusts-documentation-is-about-to-drastically-improve http://words.steveklabnik.com/rusts-documentation-is-about-t...

steveklabnik 12y ago
Thanks for the kind words. Still so much to do!
masklinn 12y ago
One thing I definitely miss, especially with things being split into separate extension traits (e.g. iterators a few weeks ago) is a Hoogle-like type-based search. Because finding out how to perform operations, especially very generic ones, has become fairly frustrating. Also the ability to easily search both the standard library and third-party libraries is probably going to be needed soon if nothing experimental is going to be available in the "standard track".
- steveklabnik 12y ago
  https://github.com/rust-lang/rust/issues/12866 https://github.com/rust-lang/rust/issues/12866

bazookajoes 12y ago

Maybe I'm off base, but in this day and age I can not imagine writing a new compiler and runtime without at least 100% branch coverage and automated fuzz testing and actually asking people to use it. It is a gut wrenching feeling when code crashes in production and it is my compiler to blame. It seems so much more shameful to me then if a library or service of mine crashed, not that that isn't shameful as well. Do I need to loosen up?

lmm 12y ago
You need to be loose enough that you'll actually write and release a compiler, imperfect as it is. Shame can be a powerful motivator but it can also be paralyzing. As I've used more modern languages with better type systems I've moved away from high test coverage and towards writing code that simply can't go wrong (or at least, that is exceedingly limited in the ways it can go wrong); http://spin.atomicobject.com/2014/12/09/typed-language-tdd-part1/ http://spin.atomicobject.com/2014/12/09/typed-language-tdd-p... is a well-written explanation of something very close to my current approach. So I wouldn't put the emphasis on branch coverage or fuzz testing that you do. But I absolutely agree that you should have a very high level of confidence in a compiler before you ask people to use it, substantially higher than the level of confidence required of a library or service.