Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing Rust 1.0 Alpha

blog.rust-lang.org

Post reply on HN
Print view View original

101–110 of 255 posts

Re: Announcing Rust 1.0 Alpha

#101

Post by natrius »

apendleton wrote: post #48
Ao7bei3s wrote: post #29

Earlier quoted context omitted.

Python is a prime example of a rotten standard library. Take urllib/urllib2 (use requests instead), unittest (use py.test or nose), os (too low-level, hence arcane usage) or time as examples (use pytz for anything serious), and of course Tkinter. Take all of the modules that solve minor/niche tasks that could easily have been put in a seperate library (e.g. wave), that are usually a bad idea to use (e.g. pickle), tha…

It all depends what you're using it for. If I'm writing code that's going to be around awhile and can tolerate some dependencies, I'll totally use, say, requests. But I use urllib2 from the repl all the time, especially if I'm on a machine that isn't mine. The fact that any Mac already has the tools on it to grab some JSON from an API, parse it, and do something useful with it from the command line, without having to…

It's possible to achieve the best of both worlds. We could introduce the concept of a standard distribution instead of a standard library. A release of Python should ship with specific versions of requests, nose, and other packages that have a broad community consensus. Those packages could be individually upgraded later, but every install of Python 2.7.9, for instance, would have requests 2.5.1 or greater installed. That would avoid the stagnation packages see when they enter the standard library, and would maintain the benefits of universal availability.

Every language ecosystem should work this way.

Re: Announcing Rust 1.0 Alpha

#102

Post by kibwen »

iamdanfox wrote: post #86
kibwen wrote: post #80

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: http://is.gd/YkUY0l), 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?

Re: Announcing Rust 1.0 Alpha

#103

Post by odroid-user »

kibwen wrote: post #84
odroid-user wrote: post #72

Earlier quoted context omitted.

I attempted to install Rust on my ODROID-XU3 (which is running Lubuntu 14.04.1 LTS) just now by running: curl -s https://static.rust-lang.org/rustup.sh | sudo sh The resulting output was: rustup: CFG_CURL := /usr/bin/curl (7.35.0) rustup: CFG_TAR := /bin/tar (1.27.1) rustup: CFG_FILE := /usr/bin/file (5.14) rustup: CFG_SHA256SUM := /usr/bin/sha256sum (256sum) rustup: CFG_SHASUM := /usr/bin/shasum (5.84) rustup: rustu…

Rather than trying to run the compiler itself on a given platform, I'd recommend cross-compiling binaries from a known platform. I'm not an expert in this aspect of Rust, but here's some example Rust code that targets the PSP: https://github.com/luqmana/rust-psp-hello (AIUI the magic is in the psp.json.in file, which communicates a target specification to the compiler). Feel free to come ask in #rust on irc.mozilla.o…

I have a VPS running x86_64 Debian unstable so I installed Rust on it now.

I compiled an hello world on the VPS, the content of which is:

  fn main () {
    println!("hello world");
  }
using

  rustc main.rs
and the resulting binary ran on the VPS and said

  hello world
I went to the example Rust code you linked that targets PSP and had a quick look at it but it was kind of a lot at once so I went looking for alternatives and found https://github.com/japaric/ruststrap which seemed promising but the README was not very clear and the archive hosted by that person is from 2014-12-17. I cloned it to my VPS and attempted to run the ruststrap.sh which it didn't want to unless it was root so I let it be root but it ended with

  + apt-get install -qq g++-arm-linux-gnueabihf
  E: Unable to correct problems, you have held broken packages.
So I'm not sure if I was supposed to run that on x86_64 or not or if maybe I was supposed to run something else first. My VPS is a bit of a mess so that could be the reason also.

I am going to go back now to the example Rust code for PSP you linked and look more at it, it seems to be the most promising at this point (though it will be a bit inconvenient for me in the long run to do any development on the VPS instead of locally.)

Thank you for your comment and the link.

Re: Announcing Rust 1.0 Alpha

#104

Post by dman »

yoklov wrote: post #100
snake_case wrote: post #81

Being a game developer, inheritance is a really important language feature. I'm not one to abuse the power. Currently, for school I've been working on an OpenGL game engine in C++. It's a component based system. The only real inheritance situation that's important to me, is to allow the user of the engine to create any object and make it inherit from GameObject (example: Duck would inherit the members and methods fro…

I'm a game developer and I don't use inheritance a lot, and when I do use it it's almost never for virtual dispatch. (I wouldn't mind it being added to Rust, but I don't expect I would use it). Anyway, if you're already doing a component based system, why do you need inheritance? Just do a normal ECS. You don't subclass GameObjects in most implementations of ECS (and this is a good thing).

ECS - http://en.wikipedia.org/wiki/Entity_component_system (Just trying to save a lookup for others)

Re: Announcing Rust 1.0 Alpha

#105

Post by panic »

steveklabnik wrote: post #15
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…

It's been my experience that the standard library is _never_ the place for the best lib to do $WHATEVER_PARTICULAR_TASK, but different folks have different preferences. We'll see how it all shakes out!

There are languages with strong standard libraries: Erlang (both its normal libraries and OTP), Objective-C (Cocoa) and Mathematica are three that come to mind.

Re: Announcing Rust 1.0 Alpha

#106

Post by JulianWasTaken »

chc wrote: post #95
JulianWasTaken wrote: post #49

Earlier quoted context omitted.

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.

You're arguing with a general observation. The fact that it's not universally true is unsurprising. If you take the average quality of third-party libraries and the average quality of libraries in the standard library, I think you will find that the standard library is generally pretty good.

Whether it's better than the average is irrelevant, that isn't the benchmark. It needs to be better than or equal to all of the third party libraries for it to be worthwhile, otherwise, why does it exist? When you pick a library you don't pick all of them, you pick just the best one that meets the criteria you need, and the standard library can't beat the flexibility that other people will have to better meet those criteria without needing to partake in the process upstream.

(It's also not true that the standard library is generally pretty good IMHO, but that will start to veer us into subjectives [which I think the comment above my original post has already done anyhow]).

Re: Announcing Rust 1.0 Alpha

#107

Post by Gankro »

iamdanfox wrote: post #86
kibwen wrote: post #80

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…

There have been a few proposals for advanced bit-packing stuff, but most of it has been postponed as back-compat for later.

That said, by default enum/struct layout is undefined, so it's possible the compiler could be taught to optimize your usecase correctly. For instance Option is the same size as &T because &T is strictly non-zero, and we can therefore use 0 for None.

Re: Announcing Rust 1.0 Alpha

#108

Post by Animats »

steveklabnik wrote: post #73
Animats wrote: post #65

Earlier quoted context omitted.

Oh, and what's the matching version of Cargo? Is Cargo still changing so rapidly that it needs to be downloaded nightly?

You get a Cargo when you install Rust.

Only if you install it as root. I install nightlies in ~/local. It's not stable enough to be installed as root.

Re: Announcing Rust 1.0 Alpha

#109

Post by kaoD »

iamdanfox wrote: post #86
kibwen wrote: post #80

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…

Check kibwen's post (my sibling). It's [dead] for some reason but it answers your question. I'll reproduce it here:

> Hm, an enum like `enum Color { R, O, Y, G, B, I, V }` is represented by a u8 at runtime (see for yourself here: http://is.gd/YkUY0l), 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?

Re: Announcing Rust 1.0 Alpha

#110

Post by riffraff »

gnuvince wrote: post #59

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 :(
Post reply on HN