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

191–200 of 211 posts

Re: My Vision of D’s Future

#191

Post by ttkciar »

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…

I don't disagree with anything you say :-) but it bears pointing out that D already lets you call into C libraries without glue.

This means you can write C and use the entire wide C ecosystem, but use D for the parts of the program which make sense in D, painlessly.

Re: My Vision of D’s Future

#192

Post by pjmlp »

jstimpfle wrote: post #189
pjmlp wrote: post #186

Earlier quoted context omitted.

Ah the beauty of use-after-free and memory corruption issues. /s

Try to find one here: https://github.com/jstimpfle/language Not every project can be written 100% in this style, but the problem is very often programmers trying to mimick C++, e.g. doing object oriented fine-grained initialization/destruction stuff in C.

Will actually have a go at it.

As Google, Microsoft, Apple, Amazon have been reporting in multiple occasions, the problem goes beyond programmers trying to mimick C++.

To the point that future Android versions will require hardware memory tagging enabled on ARM devices.

Re: My Vision of D’s Future

#193

Post by jstimpfle »

pjmlp wrote: post #192
jstimpfle wrote: post #189

Earlier quoted context omitted.

Try to find one here: https://github.com/jstimpfle/language Not every project can be written 100% in this style, but the problem is very often programmers trying to mimick C++, e.g. doing object oriented fine-grained initialization/destruction stuff in C.

Will actually have a go at it. As Google, Microsoft, Apple, Amazon have been reporting in multiple occasions, the problem goes beyond programmers trying to mimick C++. To the point that future Android versions will require hardware memory tagging enabled on ARM devices.

Sure, I'm just saying that a lot of it is due to unsuitable approaches.

If you're actually going to look at it, I just want to make clear that I've never fuzzed it or anything, beyond running valgrind maybe twice (should be mentioned in the git log). And on the functional side, I don't even know what state this project is in. I think I lost interest in it when I needed to implement yet another way to encode x86-64 instructions, since having both floats and doubles is a requirement to run interesting things with OpenGL.

Let me know what problems you find!

Re: My Vision of D’s Future

#194

Post by he_the_great »

anaphor wrote: post #135
abaga129 wrote: post #131

Earlier quoted context omitted.

That's a fair point. I'm not necessarily against having to do it, I just would like there to be a more obvious indication of how to convert the result to an array. It took a lot of searching the first time I came across this. Perhaps it's just my own incompetence though!

It's definitely not your incompetence. I started learning D a few months ago and it didn't click until someone on IRC explained it clearly to me. It's not in the tutorial or anything unless I missed it.

It is the first thing I added to my articles when I introduced range based operations :

https://dev.to/jessekphillips/count-of-a-list-in-d-49k4

Re: My Vision of D’s Future

#195

Post by he_the_great »

p0nce wrote: post #146
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.

I have programmed in both for years (commercially) and don't understand the comments about D being like C++. This is a night and day difference to me.

It is less about how it feels and more about how it looks.

And appearance really only changes when you hit templates. And with D you can't tell (as an outsider) so it just looks like the non templated C++.

Re: My Vision of D’s Future

#196

Post by he_the_great »

p0nce wrote: post #153
ibobev wrote: post #119

Earlier quoted context omitted.

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?

Because Walter wrote a native compiler. I could see the same fate for nim, Walter writing a native compiler for fun that is.

Re: My Vision of D’s Future

#197

Post by he_the_great »

snagglegaggle wrote: post #21
jordigh wrote: post #13

Earlier quoted context omitted.

I find D easier to use than Rust or Go because of familiarity. It is very obviously C and C++ inspired but without all the sharp edges. I also love D's metaprogramming. It feels almost like lisp. Go's lack of generics doesn't allow this and Rust's macros don't feel as comfortable for me. Yes, D is smaller but it's also big enough for me. I don't feel like I'm missing out on much when I'm using D. If I need a library…

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).

I think D is still working through lack of support for dynamic libs (lots of headway was made so I may be wrong)

It is funny how Go sold it as a feature, but it was always a deficiency in D (and yes, it just happened out of the box.)

That isn't to say C dynamic libraries didn't work, that is a linker thing, but it would be the same in Go.

Re: My Vision of D’s Future

#198

Post by he_the_great »

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.

While not a targeted answer to why not go/rust, this is my case

https://dev.to/jessekphillips/my-case-for-d-444p

Re: My Vision of D’s Future

#199

Post by zombinedev »

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?

To escape the shit show that C and C++ are in their unique ways. In my experience, one of the worst things was working on a proprietary 1M+ LoC codebase. Everything was so painful (despite the feats of engineering being put in the internal infra to support the development processes and the great team members I worked with) that I'll never go back to anything like that if I have the choice.

I'm also dissatisfied with some of the design decisions accepted into C++11/14/17/20. (Some were fixable and just plainly shortsighted IMO, but others probably not, due to the language legacy).

Don't get me wrong, I love learning from the C++ community (conferences, tech talks, blogs and checking out how open-source projects that I'm interested in are implemented), but once that I had tasted the power and freedom of D going back to C++ feels like a huge step in the wrong direction.

And also being not only a user, but a contributor is immensely empowering. A PR to the standard library, runtime, compiler or package manager can take anywhere from days to mere hours (depending on the complexity of change), while attempting a change with a similar impact to C++ would likely take anywhere between months to years. And yes, I can see the value of the ISO C++ standardization process, but it's definitely not for me.

Re: My Vision of D’s Future

#200

Post by zombinedev »

snagglegaggle wrote: post #21
jordigh wrote: post #13

Earlier quoted context omitted.

I find D easier to use than Rust or Go because of familiarity. It is very obviously C and C++ inspired but without all the sharp edges. I also love D's metaprogramming. It feels almost like lisp. Go's lack of generics doesn't allow this and Rust's macros don't feel as comfortable for me. Yes, D is smaller but it's also big enough for me. I don't feel like I'm missing out on much when I'm using D. If I need a library…

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).

You're mistaken. By default D statically links all D dependencies (leaving only libc and possibly OpenSSL (if you need it)) to be dynamically linked (which has it's advantages), but if you want you can statically link all dependencies (including the C ones), just like you can with C or C++. D produces the same format of object files as C/C++ which makes this just as easy.
Post reply on HN