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

201–210 of 255 posts

Re: Announcing Rust 1.0 Alpha

#201

Post by vhbit »

cottonseed wrote: post #130

What the status of Rust for Android/iOS?

For a long time only 32 bit archs were supported for iOS, but just yesterday a PR landed with preliminary support of 64 bit archs. As Rust uses LLVM for codegen, it means there might be a couple of minor glitches, but overall it should be stable.

Considering that in February Apple will deny apps which do not support arm64 it is just in time :-)

So I'd say that iOS is almost first-class citizen - the only drawback here is that it is not in build bots and therefore `master` can be broken sometimes, in this case you can check https://github.com/vhbit/rust which may lag a bit but is always buildable for iOS.

Re: Announcing Rust 1.0 Alpha

#202

Post by Gankro »

kimundi wrote: post #169
Gankro wrote: post #111

Earlier quoted context omitted.

Like three different kinds, too! // Old-style generics; monomorphized // with S as an "input" type of MyTrait fn foo >(elem: T) { ... } // Where-clause-style generics; monomorphized, // with S as an "output" (associated) type of MyTrait fn foo (elem: T) where T: MyTrait { ... } // Trait objects; dynamic dispatch fn foo(elem: Box ) { ... }

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.

Re: Announcing Rust 1.0 Alpha

#204

Post by bjz_ »

12423gsd wrote: post #117
nercury wrote: post #61

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?

They fill the same role as concepts - ie. bringing type checking to the call site when using parametrized types, rather than using a duck typed approach, which leads to the big template stack traces that you get in C++.

Re: Announcing Rust 1.0 Alpha

#207

Post by snake_case »

yoklov wrote: post #175
snake_case wrote: post #112

Earlier quoted context omitted.

I guess I should do some more research regarding that. Although, I just liked the idea of inheriting from a base "empty" game object. It makes it easy to have lists of GameObjects. Also, all of my components inherit from a Component class which makes it possible to AddComponent() and GetComponent(). That way, a user of the game engine could create a new type of component and easily add that to any game object. Howeve…

Honestly, it sounds like you are over-engineering this... Forgive me if I'm wrong, but the impression I'm getting here is that you're writing the engine before the game. Never do this. Just don't. What you should do instead, is write a game, and while writing that game, write its engine. At the same time (Or even, write a game, and then refactor the engine out as you go). Then, after you're done, that engine can then…

> Forgive me if I'm wrong, but the impression I'm getting here is that you're writing the engine before the game.

Your impression is a little wrong, see below.

> Never do this. Just don't. What you should do instead, is write a game, and while writing that game, write its engine.

I'm not making a game. We have an OpenGL Game Engine class in my Game Programming program at college. I'm creating my game engine with the idea that someone could simply include it as a library and then use its features to develop a game. This Game Engine class is now over, however, I'm still developing my engine purely for personal learning purposes. Yes, I am creating demos to test features of my engine, but I'm not writing anything that would be considered a game.

Regarding the rest of your comment, I totally agree and understand what you are saying. This actually makes sense, however, it's just not the way that we've been taught so far in my program. Being a student, we are familiar with the practices that our teachers use. This makes us somewhat close minded, but it's really nice when people (like you) give a completely different way of doing something.

Thanks for the help! I'll look into these different methods of structuring my engine.

Re: Announcing Rust 1.0 Alpha

#208

Post by snake_case »

jamii wrote: post #177
snake_case wrote: post #112

Earlier quoted context omitted.

I guess I should do some more research regarding that. Although, I just liked the idea of inheriting from a base "empty" game object. It makes it easy to have lists of GameObjects. Also, all of my components inherit from a Component class which makes it possible to AddComponent() and GetComponent(). That way, a user of the game engine could create a new type of component and easily add that to any game object. Howeve…

This series of articles might help you picture how a game could be architected without inheritance: http://bitsquid.blogspot.com/2014/08/building-data-oriented-... A couple of commercial games have been built on that engine and it was recently sold to Autodesk, so it's not just handwaving.

Thanks, I'll definitely take a read through this!

Re: Announcing Rust 1.0 Alpha

#209

Post by snake_case »

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.

This also is a good solution to my problem. Thanks!

Re: Announcing Rust 1.0 Alpha

#210

Post by snake_case »

tomlu wrote: post #170
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…

Solution: Don't inherit from GameObject. Make GameObject "final" and simply be a container of components. Move all object-specific behaviour into the components.

But, I still need inheritance. DuckComponent would need to inherit from Component in order for my GameObject to add that to the list of components attached.

Am I wrong?

Post reply on HN