4 ms·
If you have written multithreaded C# code which encountered deadlocks, race conditions and had to build a mental model of which thread is responsible for what a
by the8472 2y ago
If you have written multithreaded C# code which encountered deadlocks, race conditions and had to build a mental model of which thread is responsible for what and currently "owns" a resource and is allowed to modify them... then you already kind of know a bunch of things implicitly that rust makes explicit and can transfer that knowledge.
At least that's how things clicked for me when I came from Java and I already had to debug lots of concurrent code before.
Similarly, if one has fought with a garbage collector and thought about efficient memory representations, where things get allocated and deallocated that transfers to some extent.
If you have been living blissfully in effectively-single-thread-land, then yeah, there'll be a bunch of new concepts to digest.
- 999900000999 2y agoAt least for the work I typically do, including my hobbyist projects in Unity, I almost never have to use threads. Praise be to Async, which has abstracted a lot of this. I couldn't really grass programming until I found JavaScript. Even now my criteria for learning a language is one of two things . One, do I want to build something and this language would be the best tool . Or, two, is this language going to make me a ton of money. I really want to find a good use case for Rust that isn't superseded by what I can do in the languages I already know. I might take some time to make a game in Rust one day...
- zozbot234 2y ago> Or, two, is this language going to make me a ton of money. I don't think any language per se is ever going to make you a ton of money. Even COBOL is not enough to make a ton of money. What might make you a ton of money at some point is being highly skilled at developing in some broad area where that particular language happens to be used. > I couldn't really grass programming until I found JavaScript. This is a bit surprising to me, because JavaScript is not at all an easy language to work with. You might want to look into TypeScript as a way to make quicker progress in that same domain, with Rust as more of a side-project to help you grok lower-level programming in general. > I might take some time to make a game in Rust one day... Game development in Rust tends to be especially challenging, since the main competition is C++ - another low-level language. Take a look at this example of a very simple Breakout game in Bevy, one of the most well-known game engines (though still very much at a highly experimental stage!) https://github.com/bevyengine/bevy/blob/latest/examples/games/breakout.rs https://github.com/bevyengine/bevy/blob/latest/examples/game... - this might help you realize the level of effort that's typically involved.
- 999900000999 2y agoI've been a salaried software engineer for a long time at this point. JavaScript just clicked. A lot of more complicated things you need to understand for c and c++ are just handled for you. To be fair I was technically using Unity Script, which has everything in a nice game engine sandbox. Want to move a cube, takes 1 line of code. I am working with Typescript on my latest project. It definitely helps when dealing with more complex projects. My current project is basically a website built in React. I still like Unity, but I don't trust the company so I'm looking for a new engine.
- zozbot234 2y ago> I still like Unity, but I don't trust the company so I'm looking for a new engine. Then the obvious choice is arguably Godot, which supports a similar "script-based" model.
- 999900000999 2y agoGodot has it's fair share of issues. Maybe I'll see if they fix C# web exports.
- pjmlp 2y agoNote that Rust only covers such scenarios for in-process data, any kind of resource that is external to the process, there is no help at all from Rust's type system in concurrency or threading. Which always gets forgotten in fearless concurrency discourse.