121–130 of 255 posts
Wow. Anyone remembers Rust pre-0.1? When it had typestate, ML syntax, garbage collection, etc.? So nice to see how the language slowly evolved and was molded to fit as best as possible the problem they were trying to solve.
Wasn't garbage collection actually always just planned but never realized (other than reference counting)?
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.
I find gofmt to be too opinionated about certain things and I will never use it for my go programs.
Earlier quoted context omitted.
Performance is an area where Rust still has a lot of low-hanging fruit to pick, so I'm happy to hear that you managed to make your version fast. Did you have to make any design compromises to that end? We're very interested in optimizing the typical use cases.
I have currently got some bit-swizzling [1] going on to fit the concept of a Piece into u8. (one of 6 colours and one of 6 shapes). I'd like to turn this back into a nice enum if I can! Introducing laziness by writing an iterator was actually one of the biggest single improvements (I couldn't figure out the syntax for a while, but lifetimes worked much better than I was expecting)! [1]: https://github.com/iamdanfox/q…
>Hm, an enum like `enum Color { R, O, Y, G, B, I, V }` is represented by a u8 at runtime (see for yourself here[1]), which means that you're only saving a single byte in your `Piece` struct by doing that manual optimization. What was the magnitude of the speedup that you saw?
[1]: http://play.rust-lang.org/?code=%23%5Ballow(dead_code)%5D%0A...
Earlier quoted context omitted.
You can read up here: http://doc.rust-lang.org/book/generics.html , as well about "output" generics here: https://github.com/rust-lang/rfcs/blob/master/text/0195-asso... , and explore usage in collections here: http://doc.rust-lang.org/nightly/std/collections/ .
Are "Traits" basically C++ Concepts?
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.
Gofmt respects vertical alignment of basically everything I've ever vertically aligned, and it's remarkably intelligent about it in places.
>I will never use it for my go programs.
And no one will colloborate with you. Look at ANY Go project on Github and the first issue is "run gofmt". It gets rid of entire bike-shedding discussions like this.
As an example, comprehensively document in what cases you do and do-not put two lines of code on the same physical line. Now try to enforce that across the entire internet, let alone in a lexing tool.
Earlier quoted context omitted.
I have currently got some bit-swizzling [1] going on to fit the concept of a Piece into u8. (one of 6 colours and one of 6 shapes). I'd like to turn this back into a nice enum if I can! Introducing laziness by writing an iterator was actually one of the biggest single improvements (I couldn't figure out the syntax for a while, but lifetimes worked much better than I was expecting)! [1]: https://github.com/iamdanfox/q…
FYI both kaoD and Kibwen's post seem to be dead because they included a link to a URL shortener (seems a little melodramatic on HNs part...) so I'll reproduce it here w/o the URL shortlink and see if that helps >Hm, an enum like `enum Color { R, O, Y, G, B, I, V }` is represented by a u8 at runtime (see for yourself here[1]), which means that you're only saving a single byte in your `Piece` struct by doing that manua…
Earlier quoted context omitted.
I strongly disagree with that assertion; while I readily agree that some parts of the standard library are less maintained than others, as a consumer of many third-party components, I can say without a doubt that items in the core library are generally better maintained (from a security perspective) and easier to deal with. The ease of installation has nothing to do with the desire for core components. Core component…
That's just not true. Standard library components are not better maintained, not more secure, and not easier to deal with. There are too many examples to even count of each of those -- you can take a look at PEP 476 for just one recent example.
Wow. Anyone remembers Rust pre-0.1? When it had typestate, ML syntax, garbage collection, etc.? So nice to see how the language slowly evolved and was molded to fit as best as possible the problem they were trying to solve.
is it really "so nice"? I wish they had been able to go forward with typestate :(
It'd be great for someone to write a more up-to-date version of this post!
Earlier quoted context omitted.
You can read up here: http://doc.rust-lang.org/book/generics.html , as well about "output" generics here: https://github.com/rust-lang/rfcs/blob/master/text/0195-asso... , and explore usage in collections here: http://doc.rust-lang.org/nightly/std/collections/ .
Are "Traits" basically C++ Concepts?