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

151–160 of 255 posts

Re: Announcing Rust 1.0 Alpha

#151

Post by steveklabnik »

listic wrote: post #136
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.

> the language slowly evolved and was molded to fit as best as possible the problem they were trying to solve. Which is...? Wikipedia says [1] > "to be a good language for the creation of large client and server programs that run over the Internet" and that looks too vague to me. [1] http://en.wikipedia.org/wiki/Rust_%28programming_language%29...

Memory safety without garbage collection.

Re: Announcing Rust 1.0 Alpha

#152

Post by M2Ys4U »

tete wrote: post #120

Pretty nice! I mostly used Rust Nightly till now. The language, the ecosystem, etc. seems really mature now. I've been following language development for a while now. I've never seen something that is really a new language and is that far before 1.0 or in such a short time. The language developed rapidly, without sacrificing reinventing things, changing opinions a lot. I am not sure how they did that, but it's really…

I'm sure that developing a large application (Servo) in parallel with the language helped quite a bit.

Re: Announcing Rust 1.0 Alpha

#153

Post by ptx »

rodgerd wrote: post #62
binarycrusader wrote: post #18

Earlier quoted context omitted.

I think Python and Go are two examples where the standard library has very much proven invaluable. Without it, it's difficult to be confident in the portability of components, and it quite frankly makes the language less attractive for use. Like the other poster mentioned, I'm happy for the RUST folks to take a "wait-and-see" approach, but at some point, I believe "blessed" components are going to be expected and str…

> I think Python and Go are two examples where the standard library has very much proven invaluable. C#. The amount of time I've wasted in Java programming teams while arguing over things like which of three quirky XML parsing implmentations[1] was the One To Use while the .net team powered off and built useful functionality... [1] This was a few years ago, obviously.

C# seems to be in a similar position when it comes to JSON. There's both System.Runtime.Serialization.Json and System.Web.Script.Serialization built-in plus a whole bunch of third-party libraries (e.g. Json.NET seems to be popular). I'm still not sure which one to use.

Re: Announcing Rust 1.0 Alpha

#154

Post by rcxdude »

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…

>Give me an example of any ecosystem where the standard library is the defacto best solution?

Almost all of them? Unless the stdlib is utterly utterly terrible the cost of the extra dependency is not worth the difference in quality between the stdlib and library which does the same thing.

Re: Announcing Rust 1.0 Alpha

#155

Post by nkozyra »

ptx wrote: post #143
__david__ wrote: post #122

Earlier quoted context omitted.

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.

Why is it a good idea in principle then? Automatic reformatting of the source code always seemed like a bad idea to me for precisely the sort of reason you describe.

Well it builds canonical standards without community strife, which removes one point of contention.

That seems good in theory.

Re: Announcing Rust 1.0 Alpha

#156

Post by JoshTriplett »

Jare wrote: post #131
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…

> Duck would have a GameObject, rather than be a GameObject Duck should not be a class, it should be a factory function that creates a generic GameObject and configures it with the set of components that allows it to look, walk and quack like a duck.

Can you elaborate on the reasons for that?

Re: Announcing Rust 1.0 Alpha

#157

Post by XorNot »

dragonwriter wrote: post #53
steveklabnik wrote: post #12

Earlier quoted context omitted.

Core team member here. The standard library is _not_ "batteries included," on purpose. Given that we have Cargo, and it works well, tying package updates to the language version has quite a bit of downside, and very little upside. That said, the Rust team itself maintains and provides a number of packages on Crates.io ourselves. Many of these were pulled _out_ of the standard library over the past few months.

> The standard library is _not_ "batteries included," on purpose. Given that we have Cargo, and it works well, tying package updates to the language version has quite a bit of downside, and very little upside. With a good package management system, a batteries-included standard library could just be a set of packages where you are guaranteed that a version of each backward-compatible to the one provided at language r…

A language where the standard is "we download the packages we need" (somewhat like npm on node) feels like it has a lot less mental overhead to it because the default is "users expect to get dependencies easily", and you don't have to spend so much time trying to target older but "default" installations of things.

Which with a language like Rust capable of producing static binaries, feels like a better place to be in anyway since it's a lot easier to replace 1 executable then a whole net of shared dependencies.

Re: Announcing Rust 1.0 Alpha

#158

Post by Eleutheria »

steveklabnik wrote: post #94
Eleutheria wrote: post #91

Stupid question... Why not 'let' and 'var' instead of 'let' and 'let mut'? It's just so ... weird.

One reason is that let takes a pattern, so you can do things like: let (x, mut y) = ... Another reason is that we feel 'mut' more cleanly communicates mutability than 'var.' Another reason is that we prefer immutability by default, and let/var doesn't communicate that as nicely as let and let mut. There are some discissions about this on the ML archives, RFC repo, or discuss, if you're interested.

let (x, var y) = ... can easily express the intention.

Also, communication is in the ear of the beholder. Var: variable, that varies. 'Let' would be immutable by default.

Thanks for the response anyway.

Re: Announcing Rust 1.0 Alpha

#160

Post by bjz_ »

listic wrote: post #136
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.

> the language slowly evolved and was molded to fit as best as possible the problem they were trying to solve. Which is...? Wikipedia says [1] > "to be a good language for the creation of large client and server programs that run over the Internet" and that looks too vague to me. [1] http://en.wikipedia.org/wiki/Rust_%28programming_language%29...

Agreed. I think that description should be updated.
Post reply on HN