Awesome. I'm actually right in the middle of trying to choose which one I should learn. I'd love to have a conversation with people here who already use one or (ideally) both ... any informed...
Awesome. I'm actually right in the middle of trying to choose which one I should learn.
I'd love to have a conversation with people here who already use one or (ideally) both ... any informed opinions?
I've used both in the past, currently using Go. Rust has a very steep learning curve, and I don't think I ever got over the main hump. Sometimes it seemed like you just couldn't represent certain...
I've used both in the past, currently using Go.
Rust has a very steep learning curve, and I don't think I ever got over the main hump. Sometimes it seemed like you just couldn't represent certain things cleanly. While learning, I tried to build a little test roguelike game with "Actors" that all had pluggable AI objects. But that always seemed to lead to infinitely recursing types and I never did get it to work, even with a lot of outside help. Shame because it has a lot of benefits, I just can't get over the initial costs myself.
While it took me weeks to start writing any code in Rust, pretty much the next day after touching Go I had ported over my lil JavaScript/HTML5 Canvas CHIP8 emulator to Golang and the Linux terminal. Everything feels very simple and easy to get a good grasp of while introducing a lot of little "just very nice" things.
I think each has their uses, but for someone like me that was looking for a language to play with and replace Python with, I definitely prefer Go.
I haven't done much Rust programming myself, but for a game, one approach I've heard is popular is an entity component system. This is sort of like a little column-oriented database where each...
I haven't done much Rust programming myself, but for a game, one approach I've heard is popular is an entity component system. This is sort of like a little column-oriented database where each game object is a row and IDs rather than pointers are used for links between game objects. It avoids a lot of issues with pointers and it's appropriate for games where each object has its own lifespan and is deleted explicitly like in a database. (As with a database, dangling IDs are possible.)
Rust is great. I love it. It’s brilliant language. But if I knew both of them, Rust would probably stand aside most of the time. You probably already know at least something about Rust memory...
Rust is great. I love it. It’s brilliant language. But if I knew both of them, Rust would probably stand aside most of the time.
You probably already know at least something about Rust memory model. It’s genious idea and it works great, but you need to think a bit different to actually be able to use it. It took me about 4 months to get used to it. Until than, I just wasn’t able to write any complex application. The learning curve is really, really steep. But one day, everything just clicked and I realised how powerful Rust really is.
Once you get used to it, you start thinking in a different way. This is the main reason why I love rust. Not because it’s fast, efficient or powerful, not because of the environment or for the language features themselves. I love it because it made me think outside of the C#-y OOP box.
So while I would strongly recommend Rust as a learning experience and means of learning new ways to program software, I don’t think it is the best language for day-to-day programming. You just aren’t as efficient with Rust as you could be with any other high-level language. It’s fine for projects that require high efficiency, or projects that I’m doing because it’s fun - I really enjoy writing in Rust. But for general day-to-day work when I have to get something working as soon as possible, and Rust would just slow me down? No.
About Rust compiler, mostly irrelevant to this
Oh and btw, the compiler is amazing. Using variable that is empty at the time? It’ll tell you what happened in plain english, tell you where are you accessing the variable, where (and when) you emptied the variable, and an example of good and bad code and reference to documentation. It’ll often even suggest what exactly should you edit in your code to make it work (and it’s correct most of the time!). And the same with all the errors you can encounter (even the greek question mark thing), especially rust-only ones, that you tend to encounter very often as beginner.
And if you decide to start learning rust, get in touch once you get to lifetimes. I found a very good explanation of them, which I think makes it much more clean how they work than the explanation in the Rust Book. If I knew the explanation ahead of time, I could save like three weeks when I was trying to wrap my head around it.
Could you link or provide that explanation of Lifetimes? I'm working through the Rust Book now and just finished that chapter. I feel like I wrapped my head around it, but more detail is usually...
Could you link or provide that explanation of Lifetimes? I'm working through the Rust Book now and just finished that chapter. I feel like I wrapped my head around it, but more detail is usually better.
Sure! Maybe it's clear from the book, but I completely missed that lifetime isn't how long an object lives. It's how long an unchanged object lives in current location in memory. It's such a small...
Sure! Maybe it's clear from the book, but I completely missed that lifetime isn't how long an object lives. It's how long an unchanged object lives in current location in memory.
It's such a small detail, but it really helped me when building new programs. I can write about it in detail later, but I don't have time right now, so I hope the very core of the explanation is enough for now. I'll include some examples later.
The operations team I work on is looking at using Go because it is what Kubernetes is built with and we are heavily invested in migrating our code from dedicated hardware to Kubernetes pods and...
The operations team I work on is looking at using Go because it is what Kubernetes is built with and we are heavily invested in migrating our code from dedicated hardware to Kubernetes pods and they've hit limitations on what they can do in Python. I'm not too sure on the specifics because I'm a software engineer on an operations team (I build the APIs and GUIs to help automate as many operations tasks as possible), but that's what I see the people around me doing.
That said, if you can learn Rust and find a company that needs a Rust developer you can get PAID. Not saying that's a great reason to learn a programming language, but it is a detail.
Awesome. I'm actually right in the middle of trying to choose which one I should learn.
I'd love to have a conversation with people here who already use one or (ideally) both ... any informed opinions?
I've used both in the past, currently using Go.
Rust has a very steep learning curve, and I don't think I ever got over the main hump. Sometimes it seemed like you just couldn't represent certain things cleanly. While learning, I tried to build a little test roguelike game with "Actors" that all had pluggable AI objects. But that always seemed to lead to infinitely recursing types and I never did get it to work, even with a lot of outside help. Shame because it has a lot of benefits, I just can't get over the initial costs myself.
While it took me weeks to start writing any code in Rust, pretty much the next day after touching Go I had ported over my lil JavaScript/HTML5 Canvas CHIP8 emulator to Golang and the Linux terminal. Everything feels very simple and easy to get a good grasp of while introducing a lot of little "just very nice" things.
I think each has their uses, but for someone like me that was looking for a language to play with and replace Python with, I definitely prefer Go.
I haven't done much Rust programming myself, but for a game, one approach I've heard is popular is an entity component system. This is sort of like a little column-oriented database where each game object is a row and IDs rather than pointers are used for links between game objects. It avoids a lot of issues with pointers and it's appropriate for games where each object has its own lifespan and is deleted explicitly like in a database. (As with a database, dangling IDs are possible.)
See: https://slide-rs.github.io/specs/ and https://raphlinus.github.io/personal/2018/05/08/ecs-ui.html
Rust is great. I love it. It’s brilliant language. But if I knew both of them, Rust would probably stand aside most of the time.
You probably already know at least something about Rust memory model. It’s genious idea and it works great, but you need to think a bit different to actually be able to use it. It took me about 4 months to get used to it. Until than, I just wasn’t able to write any complex application. The learning curve is really, really steep. But one day, everything just clicked and I realised how powerful Rust really is.
Once you get used to it, you start thinking in a different way. This is the main reason why I love rust. Not because it’s fast, efficient or powerful, not because of the environment or for the language features themselves. I love it because it made me think outside of the C#-y OOP box.
So while I would strongly recommend Rust as a learning experience and means of learning new ways to program software, I don’t think it is the best language for day-to-day programming. You just aren’t as efficient with Rust as you could be with any other high-level language. It’s fine for projects that require high efficiency, or projects that I’m doing because it’s fun - I really enjoy writing in Rust. But for general day-to-day work when I have to get something working as soon as possible, and Rust would just slow me down? No.
About Rust compiler, mostly irrelevant to this
Oh and btw, the compiler is amazing. Using variable that is empty at the time? It’ll tell you what happened in plain english, tell you where are you accessing the variable, where (and when) you emptied the variable, and an example of good and bad code and reference to documentation. It’ll often even suggest what exactly should you edit in your code to make it work (and it’s correct most of the time!). And the same with all the errors you can encounter (even the greek question mark thing), especially rust-only ones, that you tend to encounter very often as beginner.
And if you decide to start learning rust, get in touch once you get to lifetimes. I found a very good explanation of them, which I think makes it much more clean how they work than the explanation in the Rust Book. If I knew the explanation ahead of time, I could save like three weeks when I was trying to wrap my head around it.
Could you link or provide that explanation of Lifetimes? I'm working through the Rust Book now and just finished that chapter. I feel like I wrapped my head around it, but more detail is usually better.
Sure! Maybe it's clear from the book, but I completely missed that lifetime isn't how long an object lives. It's how long an unchanged object lives in current location in memory.
It's such a small detail, but it really helped me when building new programs. I can write about it in detail later, but I don't have time right now, so I hope the very core of the explanation is enough for now. I'll include some examples later.
Edit: this is nice memory management cheatsheet.
The operations team I work on is looking at using Go because it is what Kubernetes is built with and we are heavily invested in migrating our code from dedicated hardware to Kubernetes pods and they've hit limitations on what they can do in Python. I'm not too sure on the specifics because I'm a software engineer on an operations team (I build the APIs and GUIs to help automate as many operations tasks as possible), but that's what I see the people around me doing.
That said, if you can learn Rust and find a company that needs a Rust developer you can get PAID. Not saying that's a great reason to learn a programming language, but it is a detail.