Comment by WhereIsTheTruth | Hacker News Reader

Comment by WhereIsTheTruth | Hacker News Reader

WhereIsTheTruth

I use D for a game

What i like:

- fast to compile

- C like syntax

- modules

- slices

- metaprogramming

- compile time type introspection

- independent devs

What i don't like:

- maintainers seems to run in circle, they are scared to improve the language therefore they do nothing to improve it

- no vision

- they no longer seem to view D as a system language

- lacks features to enjoy D as a true "betterC" language

D is nice if you like C but hate headers, they unfortunately chased high level languages for too long, and it shows (EH and GC), language became depend on the two too much, making them unable to capture the system programmers

What's sad is even the high-level languages managed to catch up, as you've mentioned with Go, C# NativeAOT and Java's GraalVM

Web Assembly for example, to target it you have to create a object.d and copy paste bunch of Type Info and hooks... it's been like that for years and they didn't bother improving it, how can you be taken seriously.. system side of things got neglected

Then you have the allocator API that still is marked 'experimental', you can't ignore Exception Handling for your errors

Years after years, whenever you try to mention those issues, they always find ways to either ignore or to remind you that you should fix things yourself

Overall D is a nice language, there are much better languages if you want to target system level stuff, and there are much better languages if you want to target high level stuff

The fact that people mention using D instead of Python is just sad.. relegated as a mere alternative to an interpreted language

The language lacks leadership, it needs a reboot, 3rd time is the charm, just like Python right? ;)

Where do you get the notion that D's leadership no longer see it as a systems language? Some of D's proposed features have been blocked to protect its use as a systems language e.g. @safe by default.

Also are NativeAOT and GraalVM replacements for a language like D when they limit access to their respective languages' library ecosystems?

I think comparison to Python is a plus. Python is loved because of its flexibility and ease of use. One of D's strengths is the degree of flexibility and ease of use it maintains while offering much greater performance than Python.

I do agree that language improvements can be slow but I don't believe it is because maintainers are afraid. I believe it is because of the degree to which D involves its wider community in improvements.

Edited for grammar.

By using the language, when you step away from phobos/gc/eh to embrace esoteric targets (wasm), you start to notice how the language is just not made for that kind of things, wherewas the highlevel stuff are nailed

Or rather, it doesn't provide enough to justify the downsides

Why do so many people say that dlang compilation is fast? Does it not use llvm? If it supports features like generics, then I assumed compile times must be slow just like rust or cpp. Why is dlang different?

D has its own backend (or it used to at least) which is lightning fast. No comparison what so ever to C++ or Rust, much much faster. And that's with D having much more powerful metaprogramming than either.

Zig is similar in that regard, if you don't use the LLVM backend it is stupidly fast despite the insane amount of metaprogramming it supports.

D is one of the very few languages that maintain its own backend, they have full control, and it is very fast, that's why I still use D, despite its problems

I did an unscientific comparison more than 1 decade ago... yep D was pretty fast (at least compared to g++). Of course FPC was faster.

BTW, there are several D compilers:

- DMD (the de-facto compiler written by Walter). Previously written in C++, now is self-hosted. It has it's own code codegen.

- LDC (using LLVM)

- GDC (using GCC)

I guess Walter still hangs around here to comment on this, I hope.

He tends to not comment on postings that are directly about D. You can make what you will of that.

He does, at times.

HN Algolia search should find some.

> C# NativeAOT and Java's GraalVM

I’m not sure these are really a competition or a threat to anything. Go is eating C# and Java’s lunch precisely because these 2 solutions are no where near good enough in the real world.

Go has its niche and C# and Java have theirs. I don't know any emulator written in Go but C# has Ryujinx. Same with some impressive desktop apps like Icons8 Lunacy. C# AoT works fine for them.

Choco one of the best constraint solvers around now compiles with GraalVM and exposes a C-API callable from Python. Try that in Go.

They overlap in a small niche that is server side services/microservices. Pluse I’m not sure emulator startup time is a relevant metric. Jitted C# or Java are faster than AOT in most scenarios other than startup time and initial memory consumption.

Startup time is definitely relevant for any kind of user-facing application. I'm sure the JIT versions are actually faster since both languages (specially Java) have features that benefit greatly from it.

But if I'm loading a constraint solver into my Python app I don't want it to drag a massive JVM around and take 3 seconds to load up. Same with an emulator, most emulators load up in milliseconds.

> Jitted C# or Java are faster than AOT in most scenarios other than startup time and initial memory consumption.

Why are is so many people saying this, as it doesn't seem to be true. At lest from what I have seen so far. I know that theoretically jitted can be faster, in in practice it's almost never. From C# benchmarks I have seen, in case jitted is faster than AOT, it's only by minuscule few percent. But when AOT is faster it is often a lot faster. And I am not talking about startup time.

Startup time is very important

Some apps get poorly reviewed due to slow startup time

Also 3sec on your dev machine = 10sec on regular machines

Don't be like Microsoft, don't pretend 9 seconds is fast startup time :)

https://www.youtube.com/watch?v=CT7nnXej2K4

"10MinuteMail shared how they used GraalVM and Spring Boot 3 to reduce their startup time from ~30 s down to about 3 ms, and memory usage from 6.6 GB down to 1 GB, with the same throughput and CPU utilization."

https://medium.com/graalvm/graalvm-for-jdk-21-is-here-ee0117...

I agree with you, Go is ahead, but as I said, they are catching up quite fast

Outside Kubernetes and DevOps, hardly anyone cares Go exists.

Reply on news.ycombinator.com