[atombender]

I love Erlang's OTP, but I would never go back to a dynamically typed language.

Most of my current work is in Go, which is a fairly strict language, and I value perhaps more than anything the ability to verify my program at compile time -- for one, I can do large-scale refactoringest, safe in the knowledge that my program won't run until everything is again sound.

Go still leaves a lot to be desired, so I've been exploring options. I've started picking up Rust. I love the idea of zero-cost abstractions, though at the moment I find the mental overhead of a lot of the constructs (lifetime annotation, implicit operations that happen due to what traits you implement, the many baroque syntax choices, etc.) a little annoying. It brings to mind modern C++, which also has a lot of rules that you have to remember, from copy constructors to what the order of "const" in var/arg decls mean, to the awkward split between functional and imperative styles.

Modern C++ looks interesting, and I've used it for a few projects. What bugs me the most is the warts still not fixed by the "modern" iterations: Include files (leading to long compilation times), lack of modules, unsafe pointers, etc. While I appreciate and understand template mechanics, I'm not overly impressed with some developments -- Rust traits and Haskell typeclasses just seem so much less messy than the current situation with type traits and concepts. There's a tendency in "modern" C++ to offer multiple syntaxes for the same thing, none of which are very intuitive.

I've occasionally written small things in Haskell and OCaml, and I've considered doing a future project in OCaml now that multicore support is getting close. I looked at F# for a bit, too, but it comes across as having too much .NET/Microsoft flavour for me. Same with C#. I've looked at Nim, but it's too niche -- for the projects I'm going to work on, I'd have to write libraries for functionality that just isn't there yet (e.g. gRPC).

Back to Elixir, though; the problem is of course that none of these other languages offer anything like OTP. The closest may be Haskell, with it's Distributed Haskell project. But I'm not sure it's anywhere close to being as mature. Maybe Pony is comparable, but that also seems quite niche at this point.

[himaraya]

> I looked at F# for a bit, too, but it comes across as having too much .NET/Microsoft flavour for me.

Mind elaborating? F# seems like a decent fit from what you've said. I'm hoping the language will grow less stagnant as .NET Core matures.

[atombender]

I'm a big fan F# the language. It comes across very as a modern, cleaned-up version of OCaml — F# started out as an implementation OCaml, after all — with some very interesting innovations.

However, it comes with the baggage of .NET Core, which is a rather big thing. And it's growing, as Microsoft is apparently porting over everything from the older, non-cross-platform .NET stuff. For one, .NET Core includes the CLR/CIL, i.e. the JIT VM and cross-language integration, which I'm not interested in at all; I just want an AOT compiler. The AOT support seems like a fairly recent addition, and it's unclear to me how optimized it is or how well-supported it is compared to the older CLR-based toolchain. As a standard library, CoreFX seems rather large, and contains things like GUI and SQL Server support, for some reason.

In short, .NET Core seems like something you'd love only if you were already heavily invested in Microsoft's tech stack. I'm not interested in it myself.

[himaraya]

I see -- most complaints I've heard about .NET Core relate to F#'s status as a second-class citizen vis a vis compatibility problems, which have recently resolved.

I'm with you on AOT, but I think the language makes more sense if you understand it as a .NET port of OCaml. If you isolated F# from CLR, you'd lose libraries and tooling, arguably F#'s raison d'etre, pleasant design choices aside.