Hacker News Reader

Comment by hnra | Hacker News Reader

Did you compare it to F#? I’ll probably try to learn an ML language next year and without doing much research F# looks really nice since it gets all the .Net benefits.

View on HN

F# is nicer than the alternatives if you need to be (or want to be) on the Microsoft ecosystem but there are some things I miss when I use it from OCaml, like modules and functors. It also doesn't support named arguments, which are a fairly trivial thing that drastically cuts down the bugspace and increase usability for me.

I also don't think F# is as fast as OCaml?

Fairly relevant piece of culture on why a company switched from OCaml to F# https://blog.darklang.com/new-backend-fsharp/

https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...

might be now in there.

I would expect F# to be faster than OCaml, given that it doesn't box floats, and is backed by a JIT that proactively does monomorphization of generics.

I doubt very much that F#/.NET is faster than OCaml. The latter is very fast, and the CLR's runtime generics have runtime costs.

Can you give examples of the latter? I know from personal experience (of looking at disassembly of JIT output) that, when CLR generics are instantiated with structs, it is perfectly capable of full monomorphization with inlining of stuff similar to C++ <algorithm>.

Yes, structs are generally very good because they are mostly monomorphized. I haven't tested lately if structs of the same size but different types will fully monomorphize or if they share code and so require a small dispatch table. There was a CLR release awhile back where they discussed sharing code in this way to reduce code bloat.

There are still a few pitfalls. Off the top of my head, accessing generic static fields, ie. static class Foo<T> { public readonly static T Member }. Mainly for non-struct members, this typically requires a hashtable-like lookup to resolve the offset for the.

Also, generic interface dispatch can't be monomorphized, ie. interface IFoo<T> { void Method<T>(T value); }, so this too costs more than a regular virtual call because it too requires a hashtable-like lookup to resolve the generic overload to invoke.

It’s faster in some ways and slower in others. But in general this is “very fast” vs. “very fast”. You won’t find yourself wanting in web service performance in either language, for example.

I wouldn't expect F# to be faster in anything actually, speaking as a .Net developer. OCaml is very well optimized and the abstract machine was well designed to have an efficient execution. Do you have any specific examples where the CLR is better?

I recall OCaml wasn't particularly fast with anything involving floats, IIRC because they often require boxing?

It's complex [1], OCaml does have a unboxed representation of floats in arrays [2] and records (provided all fields are floats), but elsewhere they are indeed boxed.

[1] https://discuss.ocaml.org/t/optimizing-small-vector-operatio... [2] https://v2.ocaml.org/api/Float.Array.html

Good point. Polymorphic code that doesn't reduce to an unboxed float representation can be slower because of the boxing, but I don't think such code is very common exactly for this reason. I wonder if OCaml developers have tried NaN-boxing to see how it would impact performance.

Yes, you can find several benchmarks on the language benchmarks game, for example. And I would expect that any situation where you use Spans in F# to outperform almost everything outside of native code (just like with C#).

Have you compared the two before?

I like F# and I think its a great language. But I also think it will always be second class for Microsoft.

Maybe so. But it benefits from the larger ecosystem that it can piggyback onto. This is often important to people selecting a language bound by constraints in their product, company, etc and can't be dismissed.

.NET/JIT/GC improvements, improvements to core API's, enterprise libraries/SDK's, etc. C#'s improvements do tend to flow into F#, if not from a language/syntax perspective from an ecosystem perspective. An upgrade of .NET version for example also benefits a F# developer greatly even if no work is done on the language at all for example. A performance improvement in say ASP.NET Core benefits many of the F# web frameworks too. A language/tool is more than just its syntax - you need to learn the libraries, package management, build tools, etc as well and be confident of their long term support/improvement. All dimensions are important.

At this stage F# does have more broader technology support and interoperability as a result of this "second class" status. Whether this matters depends on the use case, company, and engineering resources at hand. Being second class may be more feasible for a language that can ride the tail wind may be better than standing on its own two feet? Right now in my context personally I could use F# for my company's apps and not hit too many blockers, I probably couldn't use OcAML given the technologies we use day to day.

Sure, but does that really matter? Second class doesn't mean they aren't investing in it... and some of the coolest use cases for F# (Fable ecosystem) falls outside of MSFT's scope entirely.

It's a small community with great libraries/support, and you can generally bet that the folks who are excited by it and want to use it are pretty strong technically.

I'd say significant portion of F# users are using Fable to generate Javascript. F# can compile to Rust and Python as well. https://github.com/ncave/fable-raytracer

Fable -> JS is our main use case for F#; having had to hire for this, I wouldn't say it's accurate. Most are still focused on the .NET implementation side of things. Compilation to Python is nice, I've yet to figure out why we wouldn't just use Rust rather than F# -> Rust... Rust is a great language and it feels a little silly to abstract over it.

I haven't tried F# because I am already having to work with powershell and C# and that whole .net/visualstudio ecosystem. The last thing I will look at on my personal time is a language in that ecosystem but since you recommended it I will have a look.

Since we have a Unity product, I’m moving us to an F# backend! I actually quite like it since we’re building a typical web api for a game.

You don’t have to deal with the typical need to determine what packages to use as you would in ocaml. I have aspnet and co. I’m okay with OOP leaking here and there when I get most of what I need already: an ML tool with an huge ecosystem.

Reply on news.ycombinator.com