Hacker News new | ask | show | jobs
by ibgeek 120 days ago
I used to think of D as the same category as C# and Java, but I realized that it has two important differences. (I am much more experienced with Java/JVM than C#/.Net, so this may not all apply.)

1. Very load overhead calling of native libraries. Wrapping native libraries from Java using JNI requires quite a bit of complex code, configuring the build system, and the overhead of the calls. So, most projects only use libraries written in a JVM-language -- the integration is not nearly as widespread as seen in the Python world. The Foreign Function and Memory (FFM) API is supposed to make this a lot easier and faster. We'll see if projects start to integrate native libraries more frequently. My understanding is that foreign function calls in Go are also expensive.

2. Doesn't require a VM. Java and C# require a VM. D (like Go) generate native binaries.

As such, D is a really great choice when you need to write glue code around native libraries. D makes it easy, the calls are low overhead, and there isn't much need for data marshaling and un-marshaling because the data type representations are consistent. D has lower cognitive overhead, more guardrails (which are useful when quickly prototyping code), and a faster / more convenient compile-debug loop, especially wrt to C++ templates versus D generics.

2 comments

Native calls from C# are MUCH better than then the Java experience. It's a massive part of why I chose it when it came out. Today, C# is pretty great... not ever MS dev shop, which is often, like Java, excessively complex for its' own sake.

On #2, I generally reach for either TS/JS with Deno if I need a bit more than a shell script, or Rust for more demanding things. I like C# okay for the work stuff that I do currently though.

1. Java nowadays has Panama

2. Java and C# can also generate native binaries, just like Go, no need for VM.

3. C++ nowadays has concepts, modules and compile time execution

This wasn't true in 2010, but D has let them catch up with missing features.

what are you referring to regarding Java? I'm aware C# has AOT (and il2cpp for Unity projects) but I don't recall hearing about any sort of Java native binary that isn't just shipping a VM and java bytecode (ignoring the short-lived GNU java compiler).
Java has had AOT compilers since around 2000, they only happened to be commercial, Excelsior JET was the most famous one.

There were several vendors selling AOT compilers for embedded systems, nowadays they are concentrated into two vendors, PTC and Aicas.

Then you have the free beer compilers GraalVM and OpenJ9, which are basically the reason why companies like Excelsior JET ended up closing shop.

Also .NET has had many flavours, starting with NGEN, Mono AOT, Bartok, MDIL, .NET Native, and nowadays Native AOT.

Both ecosystems are similar to Lisp/Scheme nowadays, having a mix of JIT and AOT toolchains, each with its plus and minus, allowing the developers to pick and choose the best approach for their deployment scenario.