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

D Programming Language

dlang.org

Post reply on HN
Print view View original

151–160 of 278 posts

Re: D Programming Language

#151

Post by ceteia »

pron wrote: post #145
rafaelmn wrote: post #100

IMHO D just missed the mark with the GC in core. It was released in a time where a replacement for C++ was sorely needed, and it tried to position itself as that (obvious from the name). But by including the GC/runtime it went into a category with C# and Java which are much better options if you're fine with shipping a runtime and GC. Eventually Go showed up to crowd out this space even further. Meanwhile in the C/C+…

> GC/runtime 1. Runtime: A runtime is any code that is not a direct result of compiling the program's code (i.e. it is used across different programs) that is linked, either statically or dynamically, into the executable. I remember that when I learnt C in the eighties, the book said that C isn't just a language but a rich runtime. Rust also has a rich runtime. It's true that you can write Rust in a mode without a ru…

Does Rust really require reference counting? I thought Rust programs only used reference counting when types like Rc and Arc are used.

Swift seems to require reference counting significantly more than Rust.

Re: D Programming Language

#152

Post by cb321 »

DeathArrow wrote: post #134
optionalsquid wrote: post #129

Earlier quoted context omitted.

My (likely unfair) impression of D is that it feels a bit rudderless: It is trying to be too many things to too many people, and as a consequence it doesn't really stand out compared to the languages that commit to a paradigm. Do you want GC? Great! Do not want GC? Well, you can turn it off, and lose access to most things. Do you want a borrow-checker? Great, D does that as well, though less wholeheartedly than Rust.…

>My (likely unfair) impression of D is that it feels a bit rudderless: It is trying to be too many things to too many people, and as a consequence it doesn't really stand out compared to the languages that commit to a paradigm. My (likely unfair) impression of D is that it feels a bit rudderless: It is trying to be too many things to too many people, and as a consequence it doesn't really stand out compared to the la…

This can very clearly be said about C++ as well, which may have started out as C With Classes but became very kitchen sinky. Most things that get used accrete a lot of features over time, though.

FWIW, I think "standing out" due to paradigm commitment is mostly downstream of "xyz-purity => fewer ways to do things => have to think/work more within the constraints given". This then begs various other important questions, of course.. E.g., do said constraints actually buy users things of value overcoming their costs, and if so for what user subpopulations? Most adoption is just hype-driven, though. Not claiming you said otherwise, but I also don't think the kind of standing out you're talking about correlates so well to marketing. E.g., browsers marketed Javascript (which few praised for its PLang properties in early versions).

Re: D Programming Language

#153

Post by cb321 »

DeathArrow wrote: post #135

Every talk about D here seems to transform into "why D failed?".

I don't use D.. I find Nim helps with even lower ceremony. That said, it's hard for me to understand how "getting into gcc" is failure. The list of such PLangs is very short. People can be very parochial, though. They probably mean pretty shallow things (just one example, but something like "failed to convert me, personally", or "jobs I'd like to apply for", or etc.).

Maybe people should instead talk about how they use D or what they'd like to see added to D? In an attempt to be the change one wants to see, I'd say named arguments are a real win and there seem to be some stalled proposals for that in D last I checked.

Re: D Programming Language

#154

Post by brabel »

ceteia wrote: post #151
pron wrote: post #145

Earlier quoted context omitted.

> GC/runtime 1. Runtime: A runtime is any code that is not a direct result of compiling the program's code (i.e. it is used across different programs) that is linked, either statically or dynamically, into the executable. I remember that when I learnt C in the eighties, the book said that C isn't just a language but a rich runtime. Rust also has a rich runtime. It's true that you can write Rust in a mode without a ru…

Does Rust really require reference counting? I thought Rust programs only used reference counting when types like Rc and Arc are used. Swift seems to require reference counting significantly more than Rust.

Op saying Rust has a kind of GC is absurd. Rust keeps track of the lifetime of variables and drops them at the end of their lifecycle. If you really want to call that a GC you should at least make a huge distinction that it works at compile time: the generated code will have drop calls inserted without any overhead at runtime. But no one calls that a GC.

You see OP is trying to murk the waters when they claim C has a runtime. While there is a tiny amount of truth to that, in the sense that there’s some code you don’t write present at runtime, if that’s how you define runtime the term loses all meaning since even Assemblers insert code you don’t have to write yourself, like keeping track of offsets and so on. Languages like Java and D have a runtime that include lots of things you don’t call yourself, like GC obviously, but also many stdlib functions that are needed and you can’t remove because it may be used internally. That’s a huge difference from inserting some code like Rust and C do. To be fair, D does let you remove the runtime or even replace it. But it’s not easy by any means.

Re: D Programming Language

#155

Post by kitd »

that_guy_iain wrote: post #48
kitd wrote: post #25

Earlier quoted context omitted.

Weird post. How does one of today's 10,000 who have never heard of a subject learn about it?

All seriousness, do you honestly think this site has 10,000 new users a day? How many people do you think are on here that aren't very well informed? Honestly, I'm just wondering? Also, do you know it only gets to front page if the hardcore that go to new upvote it? How many hardcore people don't know what D is?

https://xkcd.com/1053/

And if you've never heard of the lucky 10000, QED.

Re: D Programming Language

#156

Post by ceteia »

arcadia_leak wrote: post #109
rafaelmn wrote: post #100

IMHO D just missed the mark with the GC in core. It was released in a time where a replacement for C++ was sorely needed, and it tried to position itself as that (obvious from the name). But by including the GC/runtime it went into a category with C# and Java which are much better options if you're fine with shipping a runtime and GC. Eventually Go showed up to crowd out this space even further. Meanwhile in the C/C+…

I'd rather say that the GC is the superpower of the language. It allows you to quickly prototype without focusing too much on performance, but it also allows you to come back to the exact same piece of code and rewrite it using malloc at any time. C# or Java don't have this, nor can they compile C code and seamlessly interoperate with it — but in D, this is effortless. Furthermore, if you dig deeper, you'll find that…

[dead]

Re: D Programming Language

#157

Post by that_guy_iain »

nottorp wrote: post #140
that_guy_iain wrote: post #67

Earlier quoted context omitted.

> Do you know the joke with "I'll repeat the joke to you until you understand it?". Nope. That's not a joke. That's not funny. > That's why some things get reposted and upvoted. In hope of getting someone else to understand them. No, they get reposted and upvoted by sock accounts in hope that someone will finally be interested in a 30 year old programming language. > By the way, do you complain about sock accounts wh…

> What does content marketing have to do with sock accounts? If you accuse interesting subjects of being pushed by sock accounts, why wouldn't content marketing, which has even more interest in getting to the front page, be pushed by sock accounts?

[flagged]

Re: D Programming Language

#158

Post by brabel »

rafaelmn wrote: post #122
fuhsnn wrote: post #107

Earlier quoted context omitted.

FIl-C, the new memory-safe C/C++ compiler actually achieved that through introducing a GC, with that in mind I'd say D was kind of a misunderstood prodigy in retrospect.

There's two classes of programs - stuff written in C for historic reasons that could have been written in higher level language but rewrite is too expensive - fill c. Stuff where you need low level - Rust/C++/Zig

FillC works fine with all C code no matter how low level. There’s a small performance overhead but for almost every scenario it’s an acceptable overhead!

Re: D Programming Language

#159

Post by pron »

brabel wrote: post #154
ceteia wrote: post #151

Earlier quoted context omitted.

Does Rust really require reference counting? I thought Rust programs only used reference counting when types like Rc and Arc are used. Swift seems to require reference counting significantly more than Rust.

Op saying Rust has a kind of GC is absurd. Rust keeps track of the lifetime of variables and drops them at the end of their lifecycle. If you really want to call that a GC you should at least make a huge distinction that it works at compile time: the generated code will have drop calls inserted without any overhead at runtime. But no one calls that a GC. You see OP is trying to murk the waters when they claim C has a…

> If you really want to call that a GC you should at least make a huge distinction that it works at compile time: the generated code will have drop calls inserted without any overhead at runtime. But no one calls that a GC.

Except for the memory management literature, because it's interested in the actual tradeoffs of memory management. A compiler inferring lifetimes, either automatically for some objects or for most objects based on language annotations, has been part of GC research for decades now.

The distinction of working at compile time or runtime is far from huge. Working at compile time reduces the work associated with modifying the counters in a refcounting GC in many situations, but the bigger differences are between optimising for footprint or for throughput. When you mathematically model the amount of CPU spent on memory management and the heap size as functions of the allocation rate and live set size (residency), the big differences are not whether calling `free` is determined statically or not.

So you can call that GC (as is done in academic memory management research) or not (as is done in colloquial use), but that's not where the main distinction is. A refcounting algorithm, like that found in Rust's (and C++'s) runtime is such a classic GC that not calling it a GC is just confusing.

Re: D Programming Language

#160

Post by arcadia_leak »

ceteia wrote: post #156
arcadia_leak wrote: post #109

Earlier quoted context omitted.

I'd rather say that the GC is the superpower of the language. It allows you to quickly prototype without focusing too much on performance, but it also allows you to come back to the exact same piece of code and rewrite it using malloc at any time. C# or Java don't have this, nor can they compile C code and seamlessly interoperate with it — but in D, this is effortless. Furthermore, if you dig deeper, you'll find that…

[dead]

D by definition meets the FFmpeg's criteria because it's also a C compiler. Because of that I never wondered how D performs in the benchmarks, as I know for sure that it can give me the performance of C where I need it.
Post reply on HN