3 ms·

I use D for a game What i like: - fast to compile - C like syntax - modules - slices - metaprogramming - compile time type introspection - independent

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? ;)

eddythompson80 3y ago
> 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.
- sirwhinesalot 3y ago
  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.
  - eddythompson80 3y ago
    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.
    - sirwhinesalot 3y ago
      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.
    - zigzag312 3y ago
      > 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.
    - WhereIsTheTruth 3y ago
      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 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-ee01177dd12d https://medium.com/graalvm/graalvm-for-jdk-21-is-here-ee0117...
- WhereIsTheTruth 3y ago
  I agree with you, Go is ahead, but as I said, they are catching up quite fast
- pjmlp 3y ago
  Outside Kubernetes and DevOps, hardly anyone cares Go exists.
coderedart 3y ago
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?
- sirwhinesalot 3y ago
  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.
- WhereIsTheTruth 3y ago
  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
- anta40 3y ago
  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)
anonzzzies 3y ago
I guess Walter still hangs around here to comment on this, I hope.
- genter 3y ago
  He tends to not comment on postings that are directly about D. You can make what you will of that.
  - fuzztester 3y ago
    He does, at times. HN Algolia search should find some.
gomoboo 3y ago
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.
- WhereIsTheTruth 3y ago
  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

eddythompson80 3y ago

> 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.

sirwhinesalot 3y ago
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.
- eddythompson80 3y ago
  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.
  - sirwhinesalot 3y ago
    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.
  - zigzag312 3y ago
    > 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.
  - WhereIsTheTruth 3y ago
    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 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-ee01177dd12d https://medium.com/graalvm/graalvm-for-jdk-21-is-here-ee0117...
WhereIsTheTruth 3y ago
I agree with you, Go is ahead, but as I said, they are catching up quite fast
pjmlp 3y ago
Outside Kubernetes and DevOps, hardly anyone cares Go exists.

coderedart 3y ago

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?

sirwhinesalot 3y ago
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.
WhereIsTheTruth 3y ago
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
anta40 3y ago
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)

anonzzzies 3y ago

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

genter 3y ago
He tends to not comment on postings that are directly about D. You can make what you will of that.
- fuzztester 3y ago
  He does, at times. HN Algolia search should find some.

gomoboo 3y ago

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.

WhereIsTheTruth 3y ago
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