Hacker News Reader

Comment by Solar19 | Hacker News Reader

I've wanted to learn F#. I'm particularly curious about parsing and text processing, and wonder whether the pattern matching feature would work well for that.

It would be great to see an HTML minifier in F#. I've thought about building one as a way of learning the language. An F# based static site generator, similar to Jekyll or Hugo, would also be neat.

Compilation of F# is a confusing story to me. If it's still compiling to an IR, and getting JITted at runtime, that seems kind of inefficient in a world where Go exists. There's the CoreRT project, I think, that allows for precompiled .NET applications, but I'm not sure how F# fits in. I also read that all Windows Store/UWP applications are precompiled on Microsoft's cloud. I'm curious about compile-time flags and optimizations for F#, but they're rarely mentioned.

View on HN

For text processing in F# there is a library called FParsec, which is really powerful: http://www.quanttec.com/fparsec/

Regarding JIT and Go, I've built identical programs in both and while Go is faster, its not by as much as you would think (in my example, 60ms vs 40ms). Go is much more verbose to write, but its output exe is all by itself without the hundreds of dlls .NET likes to lug around.

F# works with CoreRT just fine, with some small caveats (its sprintf/printfn functions don't work I think). I've modded one of my games to use it: https://github.com/ChrisPritchard/Tetris

> If it's still compiling to an IR, and getting JITted at runtime, that seems kind of inefficient in a world where Go exists.

It really depends on your use case. If you're writing programs with very short run times, for example, then the time spent on spinning up the run-time and JITing the bytecode can amount to a significant portion of the program's execution time.

If you're writing a program that's going to run for several seconds or minutes (let alone hours, days or weeks), then the milliseconds spent JITing the bytecode just don't matter.

It's also true that, since JIT compilation happens just in time, it doesn't really have the luxury of being able to spend a whole lot of time on optimization. Depending on the kind of problem you're working on, that can make a meaningful difference. Fortran or C would still be my languages of choice for serious number crunching. .NET tends to be used more for I/O-bound or non-performance-critical applications, though, where that doesn't really matter, either.

you might want to look into parser combinators https://fsharpforfunandprofit.com/posts/understanding-parser... depending on what kind of "text proccessing" you want to do.

Reply on news.ycombinator.com