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

171–180 of 211 posts

Re: My Vision of D’s Future

#171

Post by atilaneves »

exikyut wrote: post #157
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…

> Would be quite the project though, to port a fundamentally-compiled ecosystem like D to use an interpreter.

Sort of. We already have an interpreter (CTFE!), it's just not up to the task for what I want to do with it.

Re: My Vision of D’s Future

#172

Post by atilaneves »

gravypod wrote: post #72
anderspitman wrote: post #66

Earlier quoted context omitted.

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

This. You definitely aren't attempting to build a service in one heap/address space if you're using an RPC IDL.

You'd be surprised...

Re: My Vision of D’s Future

#173

Post by atilaneves »

mhd wrote: post #42
thiago_fm wrote: post #11

Can somebody enlighten me, why use D when there is Rust/Go? I think on almost all cases, and also having a bigger community, it is a win for Rust/Go.

Not as exotic as Rust, due to more being in the Algol line of succession than ML's. But boy, on the Algol-tree, it's about as far away from Go as you can, erm, go. The blog poster's predecessor was about as heavy as you can get into generics without being called Stepanov. D tends to have quite a lot of features and lets you pick your subset, which brings it closer to languages like C++ or Scala. Go, being basically O…

I'm not exactly averse to templates...

https://atilaoncode.blog/2015/02/11/the-craziest-code-i-ever...

Re: My Vision of D’s Future

#174

Post by skocznymroczny »

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…

auto natsBelow1000 = iota(1000);

How do I pass this output to some other function without doing .array()? It's rare that you do all your processing in one method. Should I do this:

void processFurther(T)(T t) if isInputRange!T { } ?

I mean, it would probably work, but I don't like how the conditions are detached from type definitions :S

Re: My Vision of D’s Future

#175

Post by aldanor »

mochomocha wrote: post #45
thiago_fm wrote: post #11

Can somebody enlighten me, why use D when there is Rust/Go? I think on almost all cases, and also having a bigger community, it is a win for Rust/Go.

Compared to Rust: smoother learning curve, and you don't have to fight the compiler so much Compared to Go: much better designed and richer language. Obviously in terms of community, it's much smaller. But if you're ready to "build vs buy" more, or if you have some small scope project, I'd encourage you to try it.

"Fighting the compiler" is a common annoying stereotype, quite often quoted by people who don't even know Rust. After a while of using Rust, you no longer fight the compiler, you know how things work, you design and structure your programs with borrowck in mind from the start.

Re: My Vision of D’s Future

#176

Post by pjmlp »

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.

There are a couple of good D books on Packt.

https://www.packtpub.com/application-development/d-cookbook

https://www.packtpub.com/web-development/d-web-development

https://www.packtpub.com/application-development/learning-d

Plus buying them is a way to support some community members.

Re: My Vision of D’s Future

#177

Post by pjmlp »

aldanor wrote: post #175
mochomocha wrote: post #45

Earlier quoted context omitted.

Compared to Rust: smoother learning curve, and you don't have to fight the compiler so much Compared to Go: much better designed and richer language. Obviously in terms of community, it's much smaller. But if you're ready to "build vs buy" more, or if you have some small scope project, I'd encourage you to try it.

"Fighting the compiler" is a common annoying stereotype, quite often quoted by people who don't even know Rust. After a while of using Rust, you no longer fight the compiler, you know how things work, you design and structure your programs with borrowck in mind from the start.

Try to write a GUI application in Gtk-rs, or a game engine with the vector clocks array workaround, and you will see that many of us do indeed know Rust when we complain about fighting the compiler.

Re: My Vision of D’s Future

#178

Post by p0nce »

abaga129 wrote: post #132
jordigh wrote: post #90

Earlier quoted context omitted.

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.

I actually didn't know this! Very cool. I guess it's similar to calling .ToList() on IEnumerable in C#.

Most range function return a "Voldemort" that preserve lazyness if you put it in an `auto` local. Or you can use .array to get a slice out of it.

Re: My Vision of D’s Future

#179

Post by destructionator »

jacobush wrote: post #7
einr wrote: post #4

Earlier quoted context omitted.

The domain is dlang.org, the github repository is called dlang, the titles of their pages are things like "Dlang tour" and "Dlang forums". It's already searchable as dlang with no issues.

I guess I also mean actually referring to it more as DLang (or something) so people start calling it that. "D" is so hopeless to even use in conversation. Even "Rust" is miles better, and that's not exactly a brilliant name either.

Yeah, you don't want to know how many times I have said "I work with the D Programming Language" and people are like "are you a psychologist like deprogramming brainwashed people?"

Though I usually just shoot back "no computers. code people just suck at names"

Re: My Vision of D’s Future

#180

Post by destructionator »

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…

I've been working on that with my dpldocs.info site. Dub packages get linked to it automatically unless they manually override (which I didn't want to allow in the name of standardization but got overruled :( )... but like tons of things are still just plain missing docs and nothing I can do about that automatically.

We are considering hurting their search result score based on doc coverage tho.

Post reply on HN