Decided that I wanted to try programming recreationally again...

Decided that I wanted to try programming recreationally again. I want to make dwarf fortress-esque game while also learning something useful. I am considering writing it in rust. Do you have any good specific reasons not to make it in rust and what would you reccomend instead?

Note: Give a shit about graphics I just want to make a simple text based or at the very most 2d tile game.

Bloat such as unity & alike is not an option.

Attached: 1478484386383.gif (770x433, 989K)

Other urls found in this thread:

doc.rust-lang.org/book/ch04-00-understanding-ownership.html
doc.rust-lang.org/book/ch10-03-lifetime-syntax.html
github.com/ryanisaacg/quicksilver
github.com/nodef0/gorillas-rs
twitter.com/SFWRedditGifs

First consider the libraries you are gonna use, then the language.

>Do you have any good specific reasons not to make it in rust
borrow checker is just an obstacle that you have to climb over to get anything done. No reason to use it if memory safety isn't super-important
Try C or C++

I intend to do as much as possible from scratch. Maybe some libs for managing resizing windows and exiting the game but aside from that I dont think ill want/need much else.
It isnt super important no, but I figured its an interesting way to learn new stuff. I havent really exited the C# and C++ zone yet.

Do you value learning new things over doing whats practical
because Rust isn't very practical

it's an obstacle when you're first using the language ever. stop projecting your inability to write safe memory patterns onto OP.
if you're gonna do relatively barebones 2d then use winit for windowing and just use whatever wrapper for the backend you're gonna use (gl-sys for OpenGL for example), unless you want a hardware abstraction layer, in that case I'd look at gfx-hal or its slightly higher wrapper and more sane level wrapper, rendy. for audio cpal is a great option albeit extremely low level so you'd probably want its higher level wrapper, rodio.
if you want a game framework like c++'s sfml, consider ggez. alternatively if you like sdl2 there are are fantastic community bindings for it (which is what ggez uses under the good)
can't say much more because I'm unsure of how high level we're talking but I hope that helps.

just try it out. there are quite a few terminal libraries for Rust. you don't need a very big toolkit for making terminal application.
personally i would use Rust or C. check out their libraries. ncurses is pretty good

under the hood, not the good. my bad

What a shitty gear design. Look at the contact shape

>Do you have any good specific reasons not to make it in rust
Yes. Trannies.

>it's an obstacle when you're first using the language ever. stop projecting your inability to write safe memory patterns onto OP.
It has nothing to do with ability. It objectively makes code harder to write by limiting what you can do in the name of memory safety. Maybe that's a useful feature for you, but it's not when you're writing a video game

It limits what you can do as in you can't do things that are not memory safe, like having invalid references around. Why would you want this? I know it gets in the way of "we made sure it's safe even though it's fucking weird" structures like linked lists but unsafe{} exists for isolating code that might have memory management errors in it.

No, it makes you do things that are provably memory safe. There's plenty of things that are memory safe that you can't do because you can't prove it to the compiler, which is why it's a waste of time

Yes and you can represent most of everything in provably memory safe structures. If not, just isolate them in unsafe blocks. The entire point is to have a huge beacon pointing there like "HEY THIS IS PROBABLY WHERE YOU FUCKED UP".

>Yes and you can represent most of everything in provably memory safe structures
yeah except "fucking wierd" things like... linked lists
are you serious m8

Yeah linked lists are random chunks of heap memory that float around and point at each other. That is not provably memory safe and you almost never use things like this. (For trees and such, this is not a problem.)

>Maybe some libs for managing resizing windows and exiting the game but aside from that I dont think ill want/need much else.
Certainly you will not want to write your own input methods, like getting the mouse or keyboard information, that is boring insanity.
Same for actually drawing on the window, you will spend months doing nothing but boring shit and end up with something worse then just using a library.

And again think about your libraries FIRST because that is the most important part.

>random chunks of heap memory that float around and point at each other.
>you almost never use things like this
you use them all the time in game development

>something useful
>rust
you lost before you even started

You really don't, no, not in a way that a doubly linked list does it. Feel free to prove me wrong.

well what is unique about a doubly linked list that makes it impossible for rust's system handle? is it because it's a cyclic reference? you use cyclic references all the time in a game

The ownership model, nothing actually owns the data, which is why I used the wording "floating around". They're just kinda there. This is of course easy to work around safely with reference counted pointers but that's overhead. Again - there's nothing wrong with managing the memory yourself here. The idea is that most of the time you don't have to.

well I don't know what "ownership" means, why can't each node just own its successor?

It can! In a normal linked list that's all you'd have to do, like so (Box just means heap memory, otherwise this struct would be of infinite size and couldn't compile. The optional type here would optimize down to a null pointer when it contains nothing.)
struct Node {
next: Option
}

The issue arises when you need doubly linked lists, as it'd need to have a reference to its previous node, and this reference would need to be valid for at least as long as the struct containing it, as all references are supposed to be valid no matter what. However if the previous node were to get removed... yeah. That's why you need to manually manage it.
More on this topic: doc.rust-lang.org/book/ch04-00-understanding-ownership.html
You can make references infinitely more flexible than they sound with lifetimes: doc.rust-lang.org/book/ch10-03-lifetime-syntax.html
However the nodes are completely independent of each other in that regard so that's not an option.

In a game you use lots of trees which have references both ways, to its parent and its children, which is essentially a doubly linked list, so you'd have the same problem

Correct, it can't automatically handle two way references for you if they're not owned by anything. This requires a line or two of manual management (although the STL provides types for all that so it's not like you'd need to, regardless)

I've been doing this to learn Rust, and it's been fun so far. Since I wanted it to work native and on wasm, the library I'm using is this one:
github.com/ryanisaacg/quicksilver
You can see the game here
github.com/nodef0/gorillas-rs

It also has a WIP multiplayer branch. Sadly I haven't finished that yet.

Attached: network.png (1920x1080, 325K)

not op but pretty cool! i might try to do something like this too thank you user

It's probably worth pointing out that the edge cases where you need unsafe{} show up when you're IMPLEMENTING data structures, not whenever you're using one. If you're implementing your own tree structure, either you're doing it as a learning exercise, your requirements are really strange, or you've screwed up.

>Bloat such as unity & alike is not an option.
you know nothing. don't use Rust

>If you're implementing your own tree structure, either you're doing it as a learning exercise, your requirements are really strange, or you've screwed up.
I can tell you've never programmed anything that isn't a CRUD app

>I can tell you've never programmed anything that isn't a CRUD app
Elaborate?

>I wanted to try programming recreationally again. I want to make dwarf fortress-esque game while also learning something useful. I am considering writing it in rust.
You are not going to make it.
First rust is a hard language that requires both plenty of practice and experience in programming. If you want to learn rust you should definitely learn C first and then make many small projects to improve your skills.
Secondly, rust is not a language for games. Sure, you can make a game engine in it, but it is not meant for game logic and stuff. But if you only want text based game, it might be sufficient, just not a best pick.

>Maybe some libs for managing resizing windows and exiting the game
Use SDL.

>limiting what you can do in the name of memory safety.
So does type safety.
Go be a brainlet somewhere else.

You can express linked list just fine in safe rust.

>So does type safety.
C/C++ doesn't have that either

Real programmers write data structures for specific tasks all the time

>Real programmers write data structures for specific tasks all the time
How is that not just re-inventing the wheel?

>C/C++
>doesn't have type safety
Cfags, everyone.

I can cast any type to any type I want regardless of the validity of that cast
I suppose you could call that memory safety rather than type safety, but it's not something that limits the way you program like Rust's borrow checker

Are you assuming that the general data structures you used at school are the only ones that exist? There's general ones and there's specific ones, no library implements every general one and no library is going to implement every specific data structure you need. That's like saying why write algorithms when you can just import algorithms.h

You don't know what type safety is.
Yes you can cast. In rust you can use unsafe. It doesn't mean that there isn't any safety measures to prevent you from shooting yourself in a foot. You can't assign just random pointer to random pointer of unrelated type, just like you can't create multiple mutable references. But of course you can alwaus fool compiler that you know what you are doing.

>Are you assuming that the general data structures you used at school are the only ones that exist?
No, but I am assuming that they're perfectly fine for 95% of the programs you'll write.

the difference is you rarely need to break type safety but in Rust you can't make a linked list without going into unsafe mode apparently

you assumed wrong, a typical game has dozens of custom data structures, but that depends what you want to label as a 'data structure'

>the difference is you rarely need to break type safety
You don't need to break lifetimes and ownership in Rust as well, if you know what you are doing.
You can make linked list just fine
struct Node {
data: T;
next: Option;
}


No problems, no unsafe.
For double linked list you need to use Rc instead of Box. It won't be zero cost because it's a counting reference, but it's just matter of few unsafe lines to implement it. The idea is not to autistically avoid unsafe, but to use it when needed and wrap to safe interface so rest of your code can be provably safe.
I wrote multiple Rust projects and the only place I had to use unsafe was:
>hand optimized assembly for 128 fixed point arithmetic
>low level interacting with GPU
>FFI
That's all. And it's not like I compromised some performance to not use unsafe, I just never had to use it. Double linked list is in standard library anyway.