4 ms·

Most of the remarks are deserved. The exception hierarchy is not consistent currently, but the language is still evolving a lot, including on a syntax level (ju

Most of the remarks are deserved. The exception hierarchy is not consistent currently, but the language is still evolving a lot, including on a syntax level (julia 0.4 deprecates the short dict/array syntax, just to name one). To be honest, I hope they continue to break stuff. There are still many areas where it feels that the syntax/language itself could be improved a lot (too many to list!). Some of the changes have a significant impact on the entire system (like multiple inheritance for abstract types). Most of the proposed discussion/changes I've seen improve the language in several ways, they make it more uniform, so I'm really looking forward to them! The base lib is very minimal, and the quality of the contributed packages varies wildly. It's a new language... you might lament most of the same issues with Rust. Being a long time lisper, for me Julia it's a lisp in disguise with an edge on performance. The compromises/choices done so far have a great sense of direction and balance. It's a good time to jump into the development before the language is set in stone and the warts cannot be changed anymore!

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.

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.