Live data from Hacker News

I built a Game Boy emulator in F#

nickkossolapov.github.io

81–84 of 84 posts

Re: I built a Game Boy emulator in F#

#81
post #59

Ah 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.

F# is so elegant and terse for writing functional-style wrappers around OO code packages! Unfortunately, you find yourself needing to write functional-style wrappers around OO code packages.

Re: I built a Game Boy emulator in F#

#82
post #21

Earlier quoted context omitted.

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.

I am a computer scientist, not a programmer. So the short answer is that the language I choose mostly does not matter.

Re: I built a Game Boy emulator in F#

#84
post #79

Earlier quoted context omitted.

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…

Searched online for it - there is this one https://github.com/fsprojects/fsharp-hashcollections. YMMV.
Post reply on HN