Hacker News new | ask | show | jobs
by qwe----3 1 day ago
I don't know why but dlang continues to draw me - I've really enjoyed many of the talks in the past
2 comments

I always try it every few years, but I can never figure out how to get a good ide experience. I’ve tried both VSCode and IntelliJ. I most recently tried to make it work for advent of code last year. Maybe I’m just too used to how good the IDE experience for Java is?
I think that's what it is. D IDE support is bad compared to C#/Java, but it's not that bad compared to C++. I think it's just templates don't play well with proper IDE support because it's hard to reason about the code when half of the code doesn't exist until compile time.
for those (like me) completely new but interested in new programming languages - can you or similar minds summarize the current appeal?
As someone who has been using D since about late 2024, I enjoy the following things about it:

  - It has a type system that catches most category errors, without having to think too much about types
  - It is quite easy to read and write, and code in it has a high signal to noise ratio 
  - It provides a GC, but also allows you to write idiomatic code that doesn't allocate a lot (missing from a lot of gc languages, it feels like most GC languages force you to allocate more for every abstraction you write)
  - It supports GC style code for things that don't need to be efficient (>98% of the code I actually write)
  - I can easily micro-optimize the inner-loop code that does need to be efficient, without having to switch languages or setup ffi. I can also be relatively certain that the GC isn't firing too often in those loops, since the gc only collects when you gc-allocate
  - I can use all of the native libraries with C bindings on my system, with practically zero costs for bindings
  - Metaprogramming in it is top notch, I feel like every time I needed to do some type level shenanigans, I could do so in a way that actually looked like code in the end, without needing to maintain a code-generator. The way the metaprogramming works also stays fairly readable, it's not like macro_rules! or #defines or templates.
Overall, it has superseded C for pretty much everything I previously used C for, and is a joy to use for a lot of other usecases as well, I've found myself reaching for it for programs that I would otherwise write in python recently. Only major weakness in my daily experience is that you can't compile it to WASM, so I'm still using rust for that. I've considered learning Zig or Odin, but I feel like I would miss the GC for simple tasks, and D is good enough on most axes that I stopped looking for a new one true programming language to write all my code in.
it's an evolutionary (as opposed to revolutionary) language; it is in many ways a reimagining of c++ based on decades of observing the latter's flaws and weaknesses in the real world. if you're in the c or c++ ecosystem already you will likely find D a pleasant set of improvements to c++.
For example, C and C++ still cannot compile this:

    int foo() { return bar(); }

    int bar() { return 3; }
Because of stuff like ADL, the declaration order matters, thus I don't expect anyone ever submitting a paper to fix that.

And even if that isn't a problem, given how ISO works, someone still needs to get that paper in and voted.

Funny that C89/C90 would compile this specific example just fine due to implicit function declaration feature, which was deprecated in C99.
Is it because bar is defined after foo?
Yes.

It has deleterious consequences. One solution is to add a forward declaration, which is the kind of busywork a language is supposed to eliminate.

Another is to reverse the natural order of functions, with the implementation functions at the top and the interface of the module at the bottom.

After all, do you read a website from top to bottom or bottom to top?

Lua has the same problem with local functions, and Lua was the first language I learned that I still use today. So it feels very natural for me to see local functions with no dependencies at the top, and the ones with the most dependencies at the bottom. (but you can work around this in lua with globals, forward declarations, functions in tables, etc)

So I guess I kind of prefer seeing helper functions at the top and the main logic at the bottom most of the time.

BTW, that code snippet will compile properly with D's ImportC compiler. Proof that it is not impractical.