Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My Vision of D’s Future

dlang.org

Post reply on HN
Print view View original

151–160 of 211 posts

Re: My Vision of D’s Future

#151

Post by 1980phipsi »

EvenThisAcronym wrote: post #127
Profan wrote: post #33

I wish standardizing documentation tooling (everyone uses a different tool today and ddoc by default has _no_ styling, no navigation, no nothing, so usually nobody writes docs for their code unless it's a big project like vibe.d) and IDE support was on this list (vscode centric tools exist and mostly work, but it's still fairly hit and miss) .. D's tooling has languished for a long time even if it is a great language…

Visual D with Visual Studio is the gold standard, with full debugging, autocomplete, and static analysis support. Code-D with VS Code is also great, and it has fairly recently gotten funding from the D Language Foundation for further development. There's also DCD, D-Scanner and dfmt which can be used with a lot of different editors.

Also, what's the difference between code-d [1] and dlang-vscode [2]

[1] https://marketplace.visualstudio.com/items?itemName=webfreak...

[2] https://marketplace.visualstudio.com/items?itemName=dlang-vs...

Edit: It seems that dlang-vscode recommends to instead use vscode-dls [3] or code-dlang.

[3] https://marketplace.visualstudio.com/items?itemName=LaurentT...

Re: My Vision of D’s Future

#152

Post by fao_ »

mav3rick wrote: post #56
fao_ wrote: post #12

Earlier quoted context omitted.

I mean, Go is funded by google. So, that's kind of what you get when you use a search engine that is run by a major advertising corporation, I think. I hold a rather controversial (at least for HN, apparently) opinion that, I don't think we can expect a corporation to be impartial if there's no legal impetus on it and there's no monetary reason for them to act impartially. Google is a business, that makes money from…

Did you try typing it in ? It does nothing of the sort and goes to dlang's page.

https://spreadprivacy.com/google-filter-bubble-study/

Re: My Vision of D’s Future

#153

Post by p0nce »

ibobev wrote: post #119
earenndil wrote: post #111

Earlier quoted context omitted.

Nim does it by compiling to c++, which means it's dependent on c++. D isn't.

And what exactly is the bad thing about that?

cfront, the original C++ compiler, used to compile to C. Why aren't we using such a compiler nowadays?

Re: My Vision of D’s Future

#154

Post by p0nce »

skocznymroczny wrote: post #52
xhgdvjky wrote: post #17

Earlier quoted context omitted.

I work in c++ and D was designed in part to address a lot of c++ complaints. so I find myself with very few issues while writing D. it's just a very enjoyable experience (subjective ik) the meta programming is very cool also

I am worried the push towards integration with C++ will just turn D into a cheap C++ clone. We already got copy constructors, just to interact with C++ code. More C++ features to come.

It's the other way around, C++ is turning into a complicated D clone.

Re: My Vision of D’s Future

#155

Post by anaphor »

EvenThisAcronym wrote: post #124
skocznymroczny wrote: post #50

Earlier quoted context omitted.

While I enjoy using D, I find it hard to use at times. Especially if someone isn't a C++ veteran, as soon as heavy template usage comes into play I get confused, and error messages are useless because it's several screens of errors with multiple isX() && !isY() && isZ() conditions for types. Most of the standard library function calls return some opaque Result type which isn't obvious how to progress from. Only after…

Let me give you a little guidance on this (if you happen to still be using D). Most functions in std.algorithm (and many more throughout the rest of the standard library) return "ranges", which is like a begin iterator and an end iterator zipped up into one data structure. There is a "range hierarchy" that mirrors the C++ iterator hierarchy: Input/Output Range > Forward Range > Bidirectional Range > Random Access Ran…

Uniform Function Call Syntax is one of my favourite things about D

Re: My Vision of D’s Future

#156

Post by anaphor »

7thaccount wrote: post #87
ktm5j wrote: post #35

As someone who has only somewhat recently started using D, I would love to see this language succeed. It's been such a pleasure to use.. scope guards, string mixin, inline json & std.json. It's been so useful for the code I write at work. Much love for D The one thing I would add to this list is documentation ! There is a lot of good documentation available, but not for everything you would expect. For example, I had…

Yes on documentation. They have a beginner's book and everything else is pretty advanced or reference material. Some additional intermediate content would be good like how the Julia project does it.

the #d channel on freenode is extremely helpful and knowledgeable though, which helped fill the gaps for me personally.

Re: My Vision of D’s Future

#157

Post by exikyut »

atilaneves wrote: post #46

I didn't submit the link but I did write the blog post. AMA!

I have to admit I totally latched onto the point you made about fast development time.

The interpreter+compiler approach is something I've been pining for for a little while now. I've only just begun to punch holes in my obsessive tendency to only use interpreted languages (because I hate compile waits that much), and to me having the fast-iteration times of interpreters, and _also_ -O3 when it's needed, would be the best of all the worlds; IMHO JITs are a necessary hack for dynamic/untyped(/interpreted) languages, and there are serious real-world gains to be had from having the plumbing get done that lets people jump from interpretation, over JITs, straight to optimized AOT-compiled code.

Would be quite the project though, to port a fundamentally-compiled ecosystem like D to use an interpreter. I wonder how long a realistic timeframe to "minimally practically usable" would be.

Thinking about it, Cling (https://root.cern.ch/cling, https://github.com/root-project/cling, LGPL 2.1) wires Clang's C AST into LLVM's built-in JIT (IIUC) to get a C/C++ interpreter. D has LDC, so there is already integration of the UI/NCSAOSL and understanding of how to leverage LLVM. Perhaps a workable direction (with probably a lot of domain-specific knowledge already worked out and potentially available from ROOT) could be a Cling-like s/Clang/LDC/->LLVM ?

Another thought: using an approach like the above, it might be possible to add pragmas that specify whether functions should be AOTed or JITed, and how much JIT optimization should be done. I also wonder if the LLVM JIT can be told/forced to "precompile this specific function" (effectively AOTing just that function), within the JIT hot-code-replacement framework; if this were possible you could even hot-reload running code (with per-function/per-file/etc customizable optimization levels). IMHO it may be interesting to make this functionality available, and let the community/ecosystem work through the messiness of solving things like the struct-versioning problem. Clear communication would be important to rationalize and clarify the deliberateness of such a decision, of course, and that the language [design] hadn't gone completely nuts :) due to the number of segfaults/developer burnout/etc it would probably introduce.

Re: My Vision of D’s Future

#158

Post by ZootAllures91 »

mhh__ wrote: post #149
ZootAllures91 wrote: post #133

Earlier quoted context omitted.

Well, for example: import std.stdio; struct Math(string Op) { static auto eval(T, U)(T l, U r) { static if (Op == "+") return l + r; else static if (Op == "-") return l - r; else static if (Op == "*") return l * r; else static if (Op == "/") return l / r; } } static immutable auto result = Math!("+").eval(1, 2) + Math!("*").eval(3.0, 3.0); void main() { writeln(result); } You'll never be able to do anything like that…

Assuming I formatted it right, I made your example shorter import std; template Math(char Op) { auto eval(T, U)(T l, U r) { static foreach(x; "+-*/") { if (Op == x) mixin("return l ", x, " r;"); } } } static immutable result = Math!('+').eval(1, 2) + Math!('*').eval(3.0, 3.0); void main() { writeln(result); }

Yeah, that works too. I was trying not to get too crazy I guess. And also just show all the various levels of "static".

Re: My Vision of D’s Future

#159

Post by aldacron »

1980phipsi wrote: post #150
EvenThisAcronym wrote: post #127

Earlier quoted context omitted.

Visual D with Visual Studio is the gold standard, with full debugging, autocomplete, and static analysis support. Code-D with VS Code is also great, and it has fairly recently gotten funding from the D Language Foundation for further development. There's also DCD, D-Scanner and dfmt which can be used with a lot of different editors.

Do either Visual D or Code-D work with Linux or WSL? It would be really nice to have the GUI for debugging linux code. Some libraries are just much easier to get set up in linux.

Visual D is a plugin for Visual Studio, so no. Code-D is a plugin for VS Code, so it works anywhere VS Code does.

Re: My Vision of D’s Future

#160

Post by pjmlp »

einpoklum wrote: post #94
tempsolution wrote: post #86

Earlier quoted context omitted.

The main reason that D hasn't been picked up by anyone is mostly because it is an evolution of C++, not a revolution. Discarding an entire ecosystem for an evolution is not going to happen. Rust took a very different approach and just threw everything away. D looks and feels too much like C++, I would rather have hoped that effort would have been spent on making C++ better.

... and over the past decade-and-a-bit, C++ has been evolving itself quite nicely (IMHO), so the motivation for moving away from it has decreased. Also, now D probably has to "chase" some C++ developments.

The problem is that while modern C++17/20 are quite productive, we cannot get rid of C copy-paste compatibility and the errors of the past (see Python 3).

So either you work alone, in a small team that appreciates modern safe C++ (including Core guidelines), and enjoy C++, or you are faced to deal with all idiocrasies and unsafety issues from the past.

Post reply on HN