F# would probably sit in there somewhere too a little more on the app than system side, although you don't see many uses of the more low-level stuff that's been made available in the later releases of .NET, it's there for use in F#

Is Haskell a good fit for your hybrid category, similar to go and ocaml, considering it also compiles to native?

I haven't heard of Haskell being used for the kind of "high level" systems programming that go is used for.

In my opinion, as a professional haskell developer, it is too hard to reason about the runtime space usage of Haskell programs to ever recommend Haskell as a "systems programming language". Haskell would be great for writing a DSL for generating such code though.

Why do you think D isn't an option?

Well, D have a GC, and by design cannot have a GC with good performance, because of its complex mutable object system

OCaml, can achieve good GC performance because its immutable by default

D by design, will never outperform OCaml, at least this is my understanding

That, and I think D's community is too small to fix the language, while it does have several brilliant members and developer, its just too small and underfunded

So, you have two reason why D should not be an option the first technical ( D will never have a good GC ) the second is more of a logistics issue, the community is just not there to support a language as complex and as ambitious as D and deliver on all its claims

> Well, D have a GC, and by design cannot have a GC with good performance, because of its complex mutable object system. OCaml, can achieve good GC performance because its immutable by default

I'm not so sure considering Java probably has better GC performance than D/OCaml/Go and is completely mutable.

Java GC is only efficient if you allow it to be wasteful. I'm regularly running hundreds of different ocaml programs on a single machine and I trust ocaml GC to actually collect the garbage. I would not trust tens of java processes in default GC mode, which seems to be tuned for cases where a single process own the whole machine.

Hopefully, the multicore GC will be as good, or one will be able to disable multicore abilities when not in use (which is going to be most of the time, I believe)

what i know is that it is inherently harder to have good GC performance with mutable language

and as i said D has a very small community Java is on the opposite side of this spectrum its immensely popular, and as I understand it took Java several iteration, and tons of resources before gaining good performance, and still today, Java optimization is a specialized experts job

> Java optimization is a specialized experts job

No its not. Modern Java GC's require 0 tuning. ZGC with default settings can achieve submillisecond pauses.

> and as i said D has a very small community Java is on the opposite side of this spectrum its immensely popular, and as I understand it took Java several iteration, and tons of resources before gaining good performance

This wasn't your argument. You stated that mutability was the reason that D couldn't have a good GC, not the size of its community or resources. According to tiobe D is more popular than OCaml as well.

D also suffers from the community always racing after the next big thing without fixing the current set of issues.

That language is C# not OCaml, specially with the improvements done after version 7.