Stupid question...
Why not 'let' and 'var' instead of 'let' and 'let mut'?
It's just so ... weird.
Announcing Rust 1.0 Alpha
91–100 of 255 posts
Re: Announcing Rust 1.0 Alpha
#92The 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.
We absolutely want one, but we've been actually developing the conventions first. You have to know what you want to format to!
Please tell me those discussions are on the mailing list.
Re: Announcing Rust 1.0 Alpha
#93The 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.
We absolutely want one, but we've been actually developing the conventions first. You have to know what you want to format to!
[deleted]
Re: Announcing Rust 1.0 Alpha
#94Stupid 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) = ...
There are some discissions about this on the ML archives, RFC repo, or discuss, if you're interested.
Re: Announcing Rust 1.0 Alpha
#95Earlier 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.
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.
Re: Announcing Rust 1.0 Alpha
#96Being 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…
If you want closer performance characteristics and simpler use patterns, in the meantime, storing the parent GameObject by value rather than through a pointer might be easier.
For some reason I had pointers on the mind. You're right, no real use for pointers in that scenario. Storing by value makes more sense.
Re: Announcing Rust 1.0 Alpha
#97Re: Announcing Rust 1.0 Alpha
#98Earlier 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…
Python's standard library was only invaluable when its packaging situation was near-unusable. If Rust's isn't, the same thing will be true.
The opposite is also true; a good package manager can avoid the stdlib to bitrot ala Python, because you can easily swap out an old module by simply repackaging as a third party dependency.
On the contrary, the benefits of having a standard set of batteries, especially those upon which other might be developed, is fundamental to a sane ecosystem development. For instance, a standard framework for async I/O programming is important, because then people can write thousands of protocols that can be fully interoperable; if 2-3 different framework arises, each one can then develop its own ecosystem of protocols and libraries (not interoperable), and it's hard to think that each one would be as rich as the one in the former scenario. The same can be said for a HTTP library, a threading library, a XML/JSON marshaling library, a threading/concurrency library, and so on.
Re: Announcing Rust 1.0 Alpha
#99Earlier quoted context omitted.
We absolutely want one, but we've been actually developing the conventions first. You have to know what you want to format to!
Please tell me those discussions are on the mailing list.
They're actually RFCs. And the results are in a repository. I'm on mobile or I'd link you. But they generally codify already-existing style, rather than mandating it, although sometimes we just need a decision to tear down a bikeshed...
Re: Announcing Rust 1.0 Alpha
#100Being 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).