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

61–70 of 211 posts

Re: My Vision of D’s Future

#61

Post by giancarlostoro »

The_rationalist wrote: post #60
giancarlostoro wrote: post #58

I love D and one space I want to see more of is DMD on SBC's and moreso than that D running on WebAssembly, Go and Rust do it. I consider Rust and Go the main competitors to D, not sure if others would agree, but that's just my view. Other than that it's a great language.

Let's be real, in the real world D, go or rust are not competitors to anything. Just take a look at http://www.modulecounts.com to see the gap between language ecosystems.

I'm not sure I agree with "real world" being the number of publicly available packages. Better metric is companies using those languages:

https://dlang.org/orgs-using-d.html

https://www.rust-lang.org/production/users

and we know plenty are using Go in prod, including Slack, Google (heavily for YouTube's database layer), and many others.

Re: My Vision of D’s Future

#62

Post by axaxs »

jordigh wrote: post #57
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…

Yes, there's an extra barrier with D because of type checking, but in exchange, you get compile-time checks. I actually kind of like those template errors because they tell you what kind of Python-like compile-time duck-typing D is trying to use! Oh, and you can also use type deductions for function declarations! Just make it a template and let D figure out for you what type you want, or use typeof to record the type…

That second feature sounds really neat. I'd always wished Go had implemented something like this, even if just for numeric types.

Re: My Vision of D’s Future

#63

Post by yiyus »

rickette wrote: post #10
jacobush wrote: post #3

As long as we search for stuff on the internet with text terms (i.e. Google ) you've got to enhance the name of the language. If only something boring as DLang, please please do this. I feel bouts of sympathy every time I think of D, and I'm not even a hard core fan or anything. No need to change the logo or anything. Just sneak in something actually searchable ( dlang , or whatever ) in footers and headers of docume…

It's beyond me why most languages fall into this trap: C, C++, C#, D, Go, etc. All hard to search for. Granted some of these predate the internet, but most do not. Almost looks like some kind of secret agreement between language designers.

What you call trap I call tradition. There is a limited number of one letter names, getting your language to be identified with one is a big achievement. For D in particular, there has been a long competition to become "the next C" and the name has helped D to always be considered a contender.

And it does not poses such a problem for searching engines in practice. At the end of the day, you never search for "C", you search for something like "pointer to function in C" and probably much more specific, so any search engine will give you right results.

Re: My Vision of D’s Future

#65

Post by Ygg2 »

giancarlostoro wrote: post #61
The_rationalist wrote: post #60

Earlier quoted context omitted.

Let's be real, in the real world D, go or rust are not competitors to anything. Just take a look at http://www.modulecounts.com to see the gap between language ecosystems.

I'm not sure I agree with "real world" being the number of publicly available packages. Better metric is companies using those languages: https://dlang.org/orgs-using-d.html https://www.rust-lang.org/production/users and we know plenty are using Go in prod, including Slack, Google (heavily for YouTube's database layer), and many others.

Why did you link to start of production page?

https://www.rust-lang.org/production/users

has all production users (it admittedly has a lot of Bitcoin Startups). But lacks some important users like Microsoft (for ripgrep in Visual Studio Code) and Facebook for its usage of Rust for Mercurial (admittedly this isn't production ready).

Re: My Vision of D’s Future

#66

Post by anderspitman »

atilaneves wrote: post #54
gravypod wrote: post #15

> Traditionally this is done by specifying data structures and RPC calls in an Interface Definition Language (IDL) then translating that to the supported languages, with a wire protocol to go along with it. > With D, none of that is necessary. One can write the production code in D and have libraries automagically make that code callable from other languages. If you're using an RPC IDL you explicitly do not want to s…

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?

Re: My Vision of D’s Future

#67

Post by grok2 »

skocznymroczny wrote: post #51
mhd wrote: post #37

What about -betterC? I always thought this was a nice "pivot" for D. It would be great to have more support for this direction. You can't avoid malloc there, but maybe some instrumenting for leak detection or some libc replacements that exploit or are exploited by the language. Other than that, I'm okay with anything that was already in Eiffel or Modula-3…

BetterC was created at first to make it easier to port D compiler from C to D. Then people realized that it might be interesting to have D without GC and without runtime, because it makes it trivial to port to other platforms such as embedded, mobile or WASM. The problem is, betterC is kind of in that awkward spot. It's not comparable to the "real" D, and if you can live with betterC, you might as well just use C and…

But as a language doesn't betterC provides lots more useful features than C (the module system, meta-programming (imagine C with generics), scope() and many other useful things) that make it really a better language than C while still keeping C interop. I agree that it is in an awkward spot though -- and would have benefited from being it's own separate programming language. It would have been a killer feature if it could also compile standard C at the same time!

Re: My Vision of D’s Future

#68

Post by giancarlostoro »

Ygg2 wrote: post #65
giancarlostoro wrote: post #61

Earlier quoted context omitted.

I'm not sure I agree with "real world" being the number of publicly available packages. Better metric is companies using those languages: https://dlang.org/orgs-using-d.html https://www.rust-lang.org/production/users and we know plenty are using Go in prod, including Slack, Google (heavily for YouTube's database layer), and many others.

Why did you link to start of production page? https://www.rust-lang.org/production/users has all production users (it admittedly has a lot of Bitcoin Startups). But lacks some important users like Microsoft (for ripgrep in Visual Studio Code) and Facebook for its usage of Rust for Mercurial (admittedly this isn't production ready).

I hadn't been to their users page in a while. I'll update my post.

Re: My Vision of D’s Future

#69

Post by arunc »

BubRoss wrote: post #28
snagglegaggle wrote: post #21

Earlier quoted context omitted.

Good post. I haven't used D much, but the only way I really see it as "deficient" is its inability to easily create static binaries, like Go. But in a lot of ways that is never a hard requirement (it is nice, though).

Why can't D create static binaries? I've never heard that before.

I have never heard of that before. I create and link static libraries all the time. My exes are usually a drop in without any dependencies whatsoever.

Re: My Vision of D’s Future

#70

Post by grok2 »

grok2 wrote: post #67
skocznymroczny wrote: post #51

Earlier quoted context omitted.

BetterC was created at first to make it easier to port D compiler from C to D. Then people realized that it might be interesting to have D without GC and without runtime, because it makes it trivial to port to other platforms such as embedded, mobile or WASM. The problem is, betterC is kind of in that awkward spot. It's not comparable to the "real" D, and if you can live with betterC, you might as well just use C and…

But as a language doesn't betterC provides lots more useful features than C (the module system, meta-programming (imagine C with generics), scope() and many other useful things) that make it really a better language than C while still keeping C interop. I agree that it is in an awkward spot though -- and would have benefited from being it's own separate programming language. It would have been a killer feature if it…

It would have been a killer feature if in betterC mode it could compile standard C programs and be a drop-in replacement for GCC/Clang :-).
Post reply on HN