I’ve found emulators to be a pretty poor first project for rust specifically for the reasons you alluded to: That you need to know to write it without heap allocation (or other hoop jumping so long as you avoid juggling lifetimes) when so much literature and example emulator code doesn’t do this is a recipe for a bad experience. Ask me how I know.
If you’re going to write an emulator in this style, why even use an imperative language when something like Haskell is designed for this sort of thing?
These emulators already exist in basically every language, so why do anything? The point is the journey, which doesn’t need to be the shortest, most optimal path possible.
I’m saying it’s not optimal for learning the language, not that it’s not worth doing. I’ve worked on 3 different emulators for fun over the last few years, my first in rust. It was a bad experience for learning rust because I was following prior art which relied heavily on shared data structures and lots of poking randomly at blocks of RAM, a very natural way to think when you’re engrossed in the mechanics of an 8-bit CPU.
I had a better time writing a raycaster and later a path tracer, although by then I had learned to avoid dealing with the borrow checker…
I know this feels like a positive vibe post and I don’t want to yuck anyone’s yum, but speaking for myself when someone tells me “everyone should” do anything, alarm bells sound off in my mind, especially when it comes to programming languages.
Yeah I agree, I enjoy the process. I don’t think that’s what’s behind “everyone should learn rust” in this case, and many cases. It feels like a “cause”.
Sure, C++ has a more complex spec, nobody can argue against that.
Complex is the wrong word. Baffling is a better word. Or counterintuitive, or cumbersome. If “easy enough for someone with experience in C++, OCaml, Haskell, and F#” were the same thing as “not hard” then I don’t think this debate would come up so frequently.
What you call "baffling", I call "different". Being different doesn't mean it's "complex" or even "hard" (in isolation), but it can be baffling, in the same way that driving on the other side of the road for the first time can feel baffling (but doesn't mean it's "wrong").
Of course, this is very subjective. For someone who only knows python or javascript at a superficial level, Rust may seem out of reach. But if you're ok with the most common programming paradigms, I don't find Rust baffling.
I mean, you can't expect to learn a new language in a few days, it'll always take a bit of work. My feeling is that people complaining of the language being hard aren't putting the effort.
My experience is that Rust is a relatively small language which doesn't introduce a lot of new concepts. The syntax is quite intuitive, and the compiler super helpful. The borrower checker was the only new thing for me. I'm not an expert at all, but my experience is that after spending 2 weeks full-time reading books and experimenting, I was able to work professionally with the language without feeling too much friction.
On the other hand, after spending much more time on C++, I don't feel really comfortable with the language.
My feeling is that Java / C++ / Python / Javascript are all really the same language when you get down to it. Rust borrows from OCaml more than an other popular imperative languages (the first implementatoin by Graydon Hoare was in OCaml, so the inspirations abound), and therefore it really is quite different to a lot of devs who have never seen the functional paradigm. Good rust is written as a mix of imperative with a strong functional flavoring. Bad Rust is when you try to do everything by mutating arrays over iteration as you would do in imperative languages.
For me, I almost never write "for loops" and "if statements" in Rust; instead I use "functional iterators" and "match expressions", which interface with the borrow checker more nicely.
For example, iterating over an array while modifying it is a common pattern in imperative languages that compiles fine but often causes hard to reason about logic errors during runtime. In Rust, such a thing would cause compile time errors. So instead you rewrite to be more functional, it compiles, and then the magic is it just works, which is a common property of functional languages like Haskell.
IMO a lot of the consternation about the cost of the learning curve is because developers haven't realized once you get past it, the benefit is your code more often is just correct and therefore you run into fewer runtime bugs. In other languages you get the code compiling faster, but then you spend a great deal of time debugging things at runtime which you didn't anticipate at compile time.
C++ is a huge and complex language. I worked in it, on and off, from 2002 through 2014 or so and never really felt comfortable, either. Everyone seems to use their own dialect.
There _are_ more than two programming languages, though. I feel like most of the debates about Rust devolve into the same false choice between safety and ease.
Before Rust I was hearing the same argument from Haskell or Scala developers trying to justify their language of choice.
I know Rust is here to stay, but I think it’s mostly because it has a viable ecosystem and quality developer tools. Its popularity is _in spite of_ many of its language features that trade that extra 1% of safety for 90% extra learning curve.
> features that trade that extra 1% of safety for 90% extra learning curve.
I remember both MS and goog having talks about real-world safety issues in the range of 50% of cases were caused by things that safe rust doesn't allow (use after free, dangling pointers, double free, etc). The fact that even goog uses it, while also developing go (another great language with great practical applications) is telling imo.
It’s mind-mapping software that has a “zoom” component, and uses Mandelbrot fractal visuals as a background to provide some kind of landmarks I guess? Neat, but I’m a bit turned off by the grandiose readme. Reading it felt like I was trying to decode the product offering of an NFT platform from a few years ago or something.
Still in the earliest R&D phase, but working on a multiplayer voxel game. I don’t intend to share it widely, just something for me and family/friends to play.
I mostly wanted an excuse to play with shaders and WebRTC, but I also like the idea of being a sort of “dungeon master” but instead of writing a campaign, I populate the world through procedural rules, and adjust the rules based on how we all end up playing as we go, adding things to stumble upon and keep it fresh in an organic way.
Perhaps another reason to unionize is to claim more of the political power being wielded by our industry. Unions can play a role in shifting where lobbying money goes, how industry advises politicians, etc. At least I think that’s how things used to work. Not sure how anything works anymore…
If you’re going to write an emulator in this style, why even use an imperative language when something like Haskell is designed for this sort of thing?