Announcing Rust 1.0 Alpha

Post by dbaupp » Sat, Jan 10, 2015, 7:31 AM UTC

Gankro wrote: post #202

kimundi wrote: post #169

Earlier quoted context omitted.

Well, the first two are really just the same thing :P

Eh, with the new oprhan/impl rules associated and uh... not... associated(...?) types have developed quite a schism.

    fn foo>(elem: T) { ... }

    fn foo(elem: T) where T: MyTrait { ... }

    fn foo>(elem: T) { ... }

    fn foo(elem: T) where T: MyTrait { ... }

Post by wtf_is_up » Sat, Jan 10, 2015, 8:08 AM UTC

__david__ wrote: post #122

TylerE wrote: post #69

The one thing that would put rust over the top right now is something along the lines of gofmt - something simple, with zero configuration, that can be run on commit or even save.

Ugh. I hate gofmt. It's a good idea in principle, but even with "go" there are times when you want things spaced out to align columns, or hide a distracting error handling case on one line (instead of making it take 3 lines of precious vertical screen real estate). I find gofmt to be too opinionated about certain things and I will never use it for my go programs.

Post by mhd » Sat, Jan 10, 2015, 10:12 AM UTC

TylerE wrote: post #150

mhd wrote: post #144

Earlier quoted context omitted.

Whether it's called indent, gofmt or Visual Source Formatter 2051 doesn't really change its availability. Nor does it really matter a lot how much of the source is munged -- every forced change is probably annoying to someone. The main issue for me is that your code reviwer isn't looking at the code from my company. So why should I give a damn what they think about how spaces around the parens of a function call shou…

I think you're kind of missing the point. The point isn't to have a "house" style, it's to have an "everything" style. Making it optional or configurable defeats the purpose.

Post by mandor » Sat, Jan 10, 2015, 10:28 AM UTC

jfaucett wrote: post #39

kibwen wrote: post #14

Earlier quoted context omitted.

The upside to a batteries-included stdlib is, of course, that you don't have to go fishing around for the best lib to do $WHATEVER_PARTICULAR_TASK, and you also don't have to wonder whether whatever lib you eventually choose will be abandoned by its developer next month. At such a young stage of language development, I agree that it makes more sense to let the community develop libraries in order to foster competitio…

I think the stdlib is not the way to go. Give me an example of any ecosystem where the standard library is the defacto best solution? But would agree that the only thing Rust might need are officially supported crates, while keeping the language itself fully separate. The language is then completely free of the hastles of maintaining a stdlib that probably isn't used by most people anyway. But at the same time offici…

Post by thom » Sat, Jan 10, 2015, 11:09 AM UTC

iamdanfox wrote: post #88

mike_hearn wrote: post #87

Earlier quoted context omitted.

Could you post the Scala version as well, for comparison?

Sure: https://github.com/iamdanfox/QwirkleSolver The Rust version has had some algorithm improvements to reach 0.015s, but it was conceptually identical when it was solving in 0.7s.