3 ms·

can you give more details why dlang is not a good bet. I actually like the language and feature set :) I have the feeling that is to much noise on dlang, and th

can you give more details why dlang is not a good bet. I actually like the language and feature set :) I have the feeling that is to much noise on dlang, and they do not have a clear path, but still :)

coldtea 10y ago
Mostly because it's been going on for a decade, and while itself is not catching (much adoptions), other languages that have appeared since have already gotten much more traction, including Go and Swift -- and potentially Rust.
- gcr 10y ago
  That could be a function of the marketing rather than the language.
ori_b 10y ago
I've been using D in production at work. I can't say that it'll never happen, but it's up against some very strong competition, and given its age, I'm not optimistic about it catching up. D has been going for a long time, and still needs a decent more work before I'd call it mature. Its garbage collector still has global locks around every allocation and scan. On top of that, I've had memory leaks where it turned out that some anonymous closure just wasn't being released by the garbage collector. The fix for that memory leak was giving the anonymous closure a name to eliminate the environment capture. For that matter, the tooling around things like taking heap snapshots and profiling is rather painful -- there are no good runtime tracing solutions, and the memory profiler built into the GC breaks down allocations by type, and not by allocation site, which is generally not all that useful. Valgrind dies when I try to debug invalid memory use in C code bound to D. Symbols in the local stack frame are spotty in gdb. And, in general, debugging support could stand to be much better. The threading library (std.concurrency) can't send objects between threads without lots of lying to the type system to make things happy: You can't send shared references by default (we've hacked around this at work, still need to upstream the patch), and you can't send unshared references unless they're immutable. Sounds ok from a safety perspective until you realize that D is built around mutable objects, and there's no way to declare a value class. There are lots of things to like about D, but I would be very antsy about using D for a system that I had to rely on in any critical capacity, as things stand. At least, not without a willingness to commit to changing the libraries and runtime. I haven't used Go, Swift, or Rust in production enough to have an opinion on them and their production readiness.

coldtea 10y ago

Mostly because it's been going on for a decade, and while itself is not catching (much adoptions), other languages that have appeared since have already gotten much more traction, including Go and Swift -- and potentially Rust.

gcr 10y ago
That could be a function of the marketing rather than the language.

ori_b 10y ago

I've been using D in production at work. I can't say that it'll never happen, but it's up against some very strong competition, and given its age, I'm not optimistic about it catching up. D has been going for a long time, and still needs a decent more work before I'd call it mature. Its garbage collector still has global locks around every allocation and scan. On top of that, I've had memory leaks where it turned out that some anonymous closure just wasn't being released by the garbage collector. The fix for that memory leak was giving the anonymous closure a name to eliminate the environment capture. For that matter, the tooling around things like taking heap snapshots and profiling is rather painful -- there are no good runtime tracing solutions, and the memory profiler built into the GC breaks down allocations by type, and not by allocation site, which is generally not all that useful. Valgrind dies when I try to debug invalid memory use in C code bound to D. Symbols in the local stack frame are spotty in gdb. And, in general, debugging support could stand to be much better. The threading library (std.concurrency) can't send objects between threads without lots of lying to the type system to make things happy: You can't send shared references by default (we've hacked around this at work, still need to upstream the patch), and you can't send unshared references unless they're immutable. Sounds ok from a safety perspective until you realize that D is built around mutable objects, and there's no way to declare a value class. There are lots of things to like about D, but I would be very antsy about using D for a system that I had to rely on in any critical capacity, as things stand. At least, not without a willingness to commit to changing the libraries and runtime. I haven't used Go, Swift, or Rust in production enough to have an opinion on them and their production readiness.