Live data from Hacker News

My Vision of D’s Future

dlang.org

81–90 of 211 posts

Re: My Vision of D’s Future

#83

Earlier quoted context omitted.

You could share D .di files, which are akin to C/C++ headers, but automatically generated by the compiler.

Does this work over arbitrary concurrency barriers (ie a network), or is it for libraries only?

In principle, the compile time code generation involved can generate arbitrary wrappers including networked RPC. It wouldn't be terribly hard. It just hasn't been done yet as far as I know.

Re: My Vision of D’s Future

#84
post #47

Earlier quoted context omitted.

I find that D is about as easy as Python to get into. Being able to use rdmd as a shebang makes D almost feel like as scripting language. A lot of Python was also pretty easy for me to directly translate into D. Here is an example: http://inversethought.com/hg/medcouple/file/tip/medcouple.py... http://inversethought.com/hg/medcouple/file/tip/medcouple.d#...

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…

Having to use .array() on the Result of some functions is the exact same problem I've ran into as well! D is by far my favorite language but there is definitely some room for improvement in terms of documentation on how to use the standard library.

Re: My Vision of D’s Future

#86

I have to say, I like what I read there. I'm glad they're working more on c++ interoperability. I've ported some c++ code to D before, it wasn't not too bad, it wasn't a lot of code, but it would be great to be able to work directly with c++ libraries in D similarly to C libraries. It always makes me sad D hasn't picked up more. Usually comments I see about D seem pretty ambivalent to dismissive. It's a great languag…

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.

Re: My Vision of D’s Future

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

Re: My Vision of D’s Future

#88

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

In a recent blog post Walter talked about adding borrowing to D. Is this planned to be implemented and if so do you see any hurdles and/or benefits in relation to your Vision?

Looking forward what new perspective you bring to the community!

Re: My Vision of D’s Future

#89
post #6

D needs to up its game with the Techempower benchmarks IMHO. Vibe.d has been completely left behind by the usual Rust/Go/Java suspects. I'm very confident that it is capable, but that isn't particularly obvious atm.

Wow, Rust is a beast.

Re: My Vision of D’s Future

#90

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…

Having to use .array() on the Result of some functions is the exact same problem I've ran into as well! D is by far my favorite language but there is definitely some room for improvement in terms of documentation on how to use the standard library.

It's not the best idea to always unconditionally use .array because you might want to preserve the laziness of a Result type. By using .array you're saying you want all of the results into memory right now! Depending on what you're doing, you might not want that.
Post reply on HN