Really Cool!
I built a Game Boy emulator in F#
71–80 of 84 posts
Re: I built a Game Boy emulator in F#
#72F# is a good language, but I feel like it's forever stuck in C#'s shadow. A lot of the library code is C# and .NET handmedowns. Not interfaces or libraries crafted with F# in mind, often having no explicit documentation for use with F# either.
Translating library usage from C# to F# is pretty mechanical so not sure if specific docs are needed. The larger issue is the C# community loves OOP so you often have to wrap these libraries into something more “FP” if that’s how you want to work. Overall it’s far better than having nothing (looking at Haskell, OCaml as much as I enjoy them!)
[dead]
Re: I built a Game Boy emulator in F#
#73F# is my coding love language that I never get to use (outside of personal projects) :(
Re: I built a Game Boy emulator in F#
#74Ah F#, my greatest love. How I wish the C# guys and girls would see this instead of further bastardizing (don't hate me) C# into being everything but poorly. Don't you see that if you would use F# instead, creating projects with C# and F#, that you would get what is being added to C# but actually working and ergonomically? Interop is great!
It's a shame though that if you come from the world of OCaml, F# feels like its stuck in C#'s shadow a bit. You can get pretty far with F# by using it as a functional language, but eventually you'll want to interop with the rest of the .NET ecosystem and suddenly you're writing in a weird OOP/Functional hybrid style.
OCaml is wonderful too but having written F# for different companies for years, my code is pretty much never that hybrid stuff. Sure, .NET:s weird asynch apis, sometimes the code comes out a little bit weird but that is the exception to the rule imho.
Re: I built a Game Boy emulator in F#
#75Great project! Really cool to see something like this.
On the other hand, and this says nothing about you or your work, I realize I can put to bed my desire to learn and use F# after seeing what it looks like in a real project. The purely functional stuff is beautiful but once you drop in to more imperative/mutable code I find it really ugly to look at. I suppose unfortunately I suspect that in most real projects you will have to. Not sure if it just means I should choose a different functional language to jump in to, or if I should just work on applying functional concepts to the language(s) I already work with (fairly easy since C# is my primary language and has ever-increasing support for the functional paradigm).
Re: I built a Game Boy emulator in F#
#76Earlier quoted context omitted.
It's .NET 10 lol. It's not so slow you can't write stuff for it, I have implementations of Conway's game of life, Huffman compression, and a minimal TUI. The main problem is doing almost anything in it involves a method lookup. And there are almost certainly places I could have done things more smartly. One thing I do want to try out is publishing it with native AOT. I had a lot of luck with that on one of my other F…
Author here! I actually tried using AOT and it actually decreased the performance by about 35%. I think it's because Game Boy games tend use a small number of instructions a lot more than the others, so the JIT can optimize for them, while AOT has to be more conservative.
That makes sense. The part where my program really benefits is in a bottleneck area that you always have to go through and where you visit every code path in it.
Re: I built a Game Boy emulator in F#
#77Earlier quoted context omitted.
Found it MetalNES, transistor level NES emulation https://github.com/iaddis/metalnes While searching I also found a new one, VisualNES https://kaiokendev.github.io/nes/about There is also one for GB https://github.com/aappleby/MetroBoy
See also Higan, formerly BSNES, which among other things is a cycle-accurate emulation of the SNES hardware and its enhancement chips (like the SuperFX used in StarFox/StarWing): https://en.wikipedia.org/wiki/Higan_(emulator)
RIP Near
Re: I built a Game Boy emulator in F#
#78Finally someone putting in actual human effort to learn something, and not a LLM helped me build X in Y minutes. There is some hope for humanity after all I suppose.
It's always going to exist. People still build things with hand tools in the year 2026. Let's call it Artisanal Coding.
This app was coded by hands of 32 virgins on a moon lit full moon night.
Re: I built a Game Boy emulator in F#
#79Earlier quoted context omitted.
Yeah, and even if you need concurrency/parallelism within the function, it can be forgivable to use ConcurrentDictionary or ConcurrentBag or one of the many, many other thread safe mutable data structures built directly into .NET. I will personally almost always prefer the pretty functional versions of things, and that's almost always what I start with. I like immutable data structures, and they are usually more than…
I find algo performance is a consideration, but so is overall system performance especially in the face of concurrency, staleness, update rate, data processing size, consistency of data, etc. I think persistent collections are just another tool which is sometimes appropriate; and it has saved me over the standard Concurrent collections in some interesting cases. There are significantly faster immutable collection lib…
I haven't been able to fully justify it (and sadly I don't get paid for F# anymore :( ), but there was a competent port of the Scala CTrie structure available [1].
My local benchmarks got pretty decent performance, and often a bit better than the regular built-in concurrent structures, and any excuse to get rid of locks is generally a good excuse in my mind, but it was hard for me to push it when ConcurrentDictionary was fast enough and built in and maintained by a trillion dollar company.
Re: I built a Game Boy emulator in F#
#80Earlier quoted context omitted.
It's always going to exist. People still build things with hand tools in the year 2026. Let's call it Artisanal Coding.
Even if you use AI, there's a certain point where it's not clear that an AI would make you faster. F# is my favorite language, and I've been programming in it so long (since 2012) that I feel like I think in F#. Asking an AI for something can be faster if I can state my requirements informally; but if I need to specify many things precisely to an AI... why not just write the code in F#? Part of the beauty of good fun…
Curious, do you work in F#? I looked for jobs using functional langs in my last job change and I found positions extremely rare.