Python, OCaml, and Machine Learning (2020)
signalsandthreads.com
signalsandthreads.com
F#, basically OCaml on dotnet, has good support for notebooks: https://www.compositional-it.com/news-blog/a-brief-introduct...
I use it all the time when prototyping/scripting. Much more fun to use than the standard REPL.
A video of it in action: https://channel9.msdn.com/Shows/VS-Code-Livestreams/net-Inte...
I do lots of ML in Groovy using beakerx [0] which is pretty much the last thing anybody would expect but it works great.
I wanted to write a new low latency HFT system in OCaml at my firm, but we eventually decided to go with Rust. No real regrets there though, Rust feels a lot like a ML language, albeit a little more finicky and lower level. The fact that Rust seems blazing fast by default is a big advantage over OCaml imo, which in contrast can be slow (relatively) if you aren't thinking carefully about your memory allocations.
1. costs to average performance from doing gc
2. Jitter/increased tail latency from collections and (particularly) compaction which one can’t easily control.
I don’t believe that much in #1. Tracking memory with something like malloc can be slow and allocation with a typical gc is usually a few instructions bumping a pointer. If most of the minor heap is dead then deallocation is likely cheaper too. I think most of the differences are in programming style as when allocations are easy and cheap, programs tend to allocate a lot. #2 is still true though modern gcs can have very low pause times. And manual memory management can still lead to pauses waiting on the kernel (or in its page fault handler) for more memory.
Other issues for gc languages is that one generally doesn’t get data access patterns that are performant. C/C++/Rust objects generally get included in one another rather than referenced with pointers and most short-lived allocations happen on the stack which will very likely be in the cache.
If you write in a RAII style or with value allocations (note that in ocaml the only ‘value allocations’ are things that fit in a single 63 bit integer) with gc then, in a typical language, you still pay the cost of gc when you don’t use it.
1. Then don't do GC, use the language features for stack allocation, native heap allocation, RAII
2. Just like most malloc()/free() implementations, where you don't control how they talk with the actual OS heap management APIs, as you mention
Naturally not all GC enabled languages provide such features, so one looks at Python or Java, and thinks all GC languages were born alike.
Examples of GC languages where you can do exactly the same stuff as in C/C++/Rust, Common Lisp, Oberon, Oberon-2, Component Pascal, Active Oberon, Modula-3, D, Nim, Eiffel, C#, F#, Swift.
Also note that on my earlier comment I wasn't referring to OCaml in particular, rather languages of the list above, yet Cisco might be relatively happy with their MirageOS research.
https://dl.acm.org/doi/abs/10.1145/3264560.3264561
Here is a little gem of what happens when the low level coding features of GC enabled languages are taken into the hands of people that actually know how to use them.
https://devblogs.microsoft.com/aspnet/grpc-performance-impro...
.NET 6 is bringing even more C++ like features into the managed world for .NET devs.
The code I ported was not complex, and ran on the first try. Except it only worked in release mode. So I had to rewrite it using loop which made my inner ocamler sad (and the code a lot uglier).