That's so cool! I love F#, but I wrote a little Smalltalk interpreter in it and I can confirm it isn't exactly a speed demon for that kind of thing if you use it as intended lol

▲

tombert 7 hours ago | parent | next [-]

I've found that with F#, I get better performance if I do dumb imperative stuff, but keep the side effects within a function. At that point, the functions can basically be "pure" but you can get decent speed.

For example, I usually like using the `Map` data structure, and that's a pretty neat immutable structure and is usually fine for most stuff, but when performance becomes critical, it's easy enough to break into a boring imperative loop with a regular hash map. If I keep everything contained into one function, I usually can avoid feeling super dirty about it.

▲

ragnese 6 hours ago | parent [-]

Yes! That's exactly how you should do it while working with a language that doesn't have a compiler that will aggressively analyze, and rewrite and optimize your code for you. (So, most languages with "heavy runtimes" that support a bunch of dynamic stuff and JITs)

There are basically two points to programming with immutable-first data. One, eliminate certain classes of data race concurrency bugs. Two, less mutable state in a given context makes it easier to reason about.

So, if you're inside a function scope and you aren't launching any concurrent operations from inside that function, you don't have to worry about benefit #1. If you're inside a function (and you're not reaching out for global mutable state), then the context you need to keep in your working memory is likely fairly small, so a few local mutable variables doesn't significantly harm "understandability" of the implementation (in most cases). So, you really don't have to worry about #2, either. Make your functions black boxes with solid "APIs" (type signatures), and let the inside do whatever it needs to make it work the best.

Just because premature optimization is the root of all evil, it doesn't mean we need to jump right to premature pessimization...

	▲	tombert 5 hours ago \| parent [-]
		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 fast enough. Occasionally, though, you hit a bottleneck of some kind (usually in some form of loop), and you have to avoid all the beautiful functional stuff and go back to sad imperative stuff. When I do that, I usually try and keep it scoped to one function. Even within one function, I do find the persistent structures easier to reason about, but as you stated it's a small enough surface area to not be too irritating. There are exceptions to this, of course. Sometimes for caching/memoizing I will make a global ConcurrentDictionary, and I'll use the interlocked thing to do global counters sometimes.

▲

runevault 5 hours ago | parent | prev | next [-]

Out of curiosity when did you write that interpreter? The entire dotnet ecosystem has seen massive speed improvements over the years, particularly for anyone who last tried them during the Framework era. Hell they even put work in to improving tail calls which the c# compiler doesn't even take advantage of (also either in the dotnet 9 or 10 timeframe f# added an attribute to make it so a recursive call that isn't a tail call throws a compiler error so you can't accidentally screw that up).

▲

z500 4 hours ago | parent [-]

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# projects, I got like a 75% speedup out of it. I understand the JIT is supposed to outperform native AOT in the long term but I haven't seen it reach that speed.

	▲	runevault 4 hours ago \| parent [-]
		AOT vs JIT is always interesting since JIT depends on the runtime actually deciding to bother running the later passes to get more optimized code. And sorry for the paranoia, I find a lot of people tried f# or even c# back in 4.x Framework era and think it hasn't changed.

▲

jackmott42 7 hours ago | parent | prev [-]

With some care about what features to use and when, F# can be very fast. Which is nice, use functional paradigm when you want, or low level imperative code in hot loops if you need. But yeah if you use linked lists and sequences and immutable data types everywhere it sure isn't Rust.