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

Why I Like D

aradaelli.com

Post reply on HN
Print view View original

91–100 of 134 posts

Re: Why I Like D

#91

Post by WebFreak001 »

christophilus wrote: post #35

What’s the web story like in D these days? The thing I really like about Go is how easy it is to spin up a decently high performance web service.

if you want to use vibe.d as a fairly complete solution to most tasks. You will not have the fastest web service, but you will be really productive. I think with vibe.d you can easily beat node.js in comfort for writing web services, especially because most errors can be found and fixed at compile time already.

vibe.d is pretty similar to express.js

There are also other non-vibe web service libraries like arsd cgi (can't tell you much about that one) or hunt-framework (which is probably the highest performance library for the D ecosystem if you can believe the benchmarks, but doesn't have much documentation)

Re: Why I Like D

#92

Post by WebFreak001 »

raphlinus wrote: post #17
WalterBright wrote: post #12

Earlier quoted context omitted.

All languages (even C to some extent) that are in wide use evolve towards new and better ways, and obsolete old ways. I don't even recognize C++ anymore, and I wrote a frakkin compiler for it.

Speaking of people who have written C++ compilers, what do you think of Circle? Have you given any thought to targeting GPU shaders from D? I think "C-like low level control but with strong compile time metaprogramming" might be something of a sweet spot, though there is a lot of complexity to the space (mostly the oddball storage spaces).

there is DCompute for writing D programs on the GPU: https://github.com/libmir/dcompute

it's pretty awesome

Re: Why I Like D

#93

Post by sundarurfriend »

epage wrote: post #18
VHRanger wrote: post #11

Yes, I just wished more people liked D so it got momentum.

I first learned C++ 20+ years ago. While I've appreciated it, I also knew its shortcomings and had been looking for a replacement. D had some missteps along the way that lost some initial traction. I also wouldn't be surprised if timing was a factor with more C++ warts being added while the programming community has learned more lessons along the way that could be applied to the next languages (Go, Rust). As I follow…

> - Compiler availability (DMD vs GCC)

> - Split stdlib

Oh, yes, even as a complete outsider who merely reads D related threads from time to time, I remember these coming up repeatedly years ago. Both on HN and the programming side of reddit, among the top comments on D related threads. The tone was one of these being showstopper issues too.

To be clear, I have no experience with D myself - the point is just about the PR side of things and how things seemed to an outsider.

Re: Why I Like D

#94

Post by sundarurfriend »

LAC-Tech wrote: post #34
zozbot234 wrote: post #26

Earlier quoted context omitted.

Is it RESF, or is it Rust's unique feature of memory safety (and data race safety) without GC? D is a nice language to be sure, but it's going to have trouble matching these features. Of course, this is not meant as a criticism of D - other languages like Jai are practically in the same boat. The C++ folks are at least aware of the challenge, as is clear from the C++ Core Guidelines effort.

Rust definitely has a lot of merits. I was definitely following it, and excited by its release. But you cannot deny the RESF was obnoxious. And pervasive. But ultimately successful - the people who voiced their dislike would get down-voted to oblivion.

RESF = Rust Evangelism Strike Force apparently, for those not in the know.

Re: Why I Like D

#95

Post by p0nce »

gitgud wrote: post #67

Interesting language // Increment all elements by one (array-wise expression) half[] += 1; Is this really that useful? Seems like a weirdly specific code smell...

Yes it is useful, because "array ops" auto-vectorize well and you can write complex function that are vectorized. It's a bit like expression templates but with compiler support. Typically if something can be written as an array op expression it isn't worth rewriting with intrinsics or assembly. For me it's a killer feature :)

You can also mix and match scalar and slices, so for audio code it's quite cool:

    a[0..frames] += b[0..frames] * volume;

Re: Why I Like D

#96

Post by mhh__ »

sundarurfriend wrote: post #93
epage wrote: post #18

Earlier quoted context omitted.

I first learned C++ 20+ years ago. While I've appreciated it, I also knew its shortcomings and had been looking for a replacement. D had some missteps along the way that lost some initial traction. I also wouldn't be surprised if timing was a factor with more C++ warts being added while the programming community has learned more lessons along the way that could be applied to the next languages (Go, Rust). As I follow…

> - Compiler availability (DMD vs GCC) > - Split stdlib Oh, yes, even as a complete outsider who merely reads D related threads from time to time, I remember these coming up repeatedly years ago. Both on HN and the programming side of reddit, among the top comments on D related threads. The tone was one of these being showstopper issues too. To be clear, I have no experience with D myself - the point is just about th…

They come up now still, in part because people read old hackernews threads and don't actually read our docs or other information i.e. the standard library issue (Tango vs. Phobos) has been resolved for 10 years.

Re: Why I Like D

#97

Post by mhh__ »

gitgud wrote: post #67

Interesting language // Increment all elements by one (array-wise expression) half[] += 1; Is this really that useful? Seems like a weirdly specific code smell...

Loops are a code smell ;)

In this case the syntax lowers to a template which handles the iteration for you. It is not special, it gets treated the same by the compiler backend, but it will almost definitely be inlined & vectorized if the compiler is allowed to.

GCC and LLVM are actually clever enough to call memset for you if they deem it profitable.

Re: Why I Like D

#98

Post by mhh__ »

WalterBright wrote: post #57
LAC-Tech wrote: post #28

Earlier quoted context omitted.

I've seen that guys name around before, I assume he knows who Walter is and was making a joke.

The other WalterBright is the evil one.

Have you been time travelling recently?

(https://en.m.wikipedia.org/wiki/Primer_(film))

Re: Why I Like D

#99

Post by dkorpel »

jhhh wrote: post #89
WalterBright wrote: post #85

Earlier quoted context omitted.

UFCS is one of the most popular features. It's utility is in extending the functionality of a struct without adding member functions that would get private access, but don't need private access. It helps keep structs small and simple, rather than becoming kitchen sinks.

I don't disagree that it can be useful (eg. from one of the other projects mentioned in the thread: https://github.com/Netflix/vectorflow/blob/master/src/vector... ), and I definitely saw plenty of people that liked it. I think it existed in the same realm as a feature like lisp macros which are incredibly useful but when overused can turn the code into an inscrutable mess. The question for me was always how much the…

> b!(c.d)(a)

The template parameter after a ! without parentheses is always 1 token, so it's never one of the first two interpretations.

Furthermore, the point is that often when writing generic code, you're not supposed to care what the `.d` means specifically. For example, an `InputRange` is defined to have `.front`, `.empty` and `.popFront` properties. Is `.empty` a member variable, function, or constant? Doesn't matter, as long as it results in a boolean.

This does require some getting used to. A common question from newcomers is how to explicitly spell out the type in a situation like this:

  import std.algorithm;
  void main()
  {
      auto x = [10, 20, 30].map!(x => x*2);
  }
The answer is: you cannot! You know it's an `InputRange`, so you can access `.front`, `.empty`, `.popFront`, and pass it to range functions, but it's not a simple type like `int[]`.

While it's flexible, generic code is also complex. Many D standard library functions don't take a simple `string`, but a 'generic input range of a code unit'. (UTF-8, UTF-16, UTF-32). The resulting template machinery that this spawns is not pleasant to work with, so I understand your concern.

In my own D code, I often use regular arrays, foreach loops and if-statements instead of ranges, map and filter etc.

Re: Why I Like D

#100

Post by gitgud »

sodapopcan wrote: post #72
gitgud wrote: post #67

Interesting language // Increment all elements by one (array-wise expression) half[] += 1; Is this really that useful? Seems like a weirdly specific code smell...

I don't know D and just learning this syntax myself, and I'm genuinely interested in where you feel the smell is because I really like this syntax! For example: I know Ruby, so here is what I'm used to: half.map { |i| i + 1 } I also know Elixir: Enum.map(half, fn i -> i + 1 end) ...and JS, I guess because we have to: half.map(i => i + 1) // It looks just like the Ruby one ...vs whatever the Python version is... I don…

Sorry I should have been more clear. Incrementing every element in an array is much less useful than ".map()" which can execute a function on every element.

It just seems like a weirdly specific syntactic sugar... which is a "language smell"... to me

Post reply on HN