Live data from Hacker News

D Programming Language

dlang.org

251–260 of 278 posts

Re: D Programming Language

#251
post #249

Earlier quoted context omitted.

> C# 14/.NET 10 Yes, they added AOT but it's still challenging to do anything that requires calling into the OS, because you're going to need the bindings. It will still add some overhead under the hood and more overhead will you need to add yourself to convert the data to blittable types and back. Mixing C# with other languages in the same project is also difficult because it only supports MSBuild. > You are forgett…

You also need bindings in D, nothing new there. Rust also has issues using anything besides cargo.

> You also need bindings in D, nothing new there.

You don't. Any D compiler is a C compiler too, so it can take C headers without bindings or any overhead added.

Re: D Programming Language

#252
post #249

Earlier quoted context omitted.

> C# 14/.NET 10 Yes, they added AOT but it's still challenging to do anything that requires calling into the OS, because you're going to need the bindings. It will still add some overhead under the hood and more overhead will you need to add yourself to convert the data to blittable types and back. Mixing C# with other languages in the same project is also difficult because it only supports MSBuild. > You are forgett…

You also need bindings in D, nothing new there. Rust also has issues using anything besides cargo.

> Rust also has issues using anything besides cargo.

D also has its own build system but it's not the only option. Meson officially supports building D sources. You could also easily integrate D with SCons, though there's no official support.

Re: D Programming Language

#253
post #249

Earlier quoted context omitted.

You also need bindings in D, nothing new there. Rust also has issues using anything besides cargo.

> You also need bindings in D, nothing new there. You don't. Any D compiler is a C compiler too, so it can take C headers without bindings or any overhead added.

You have forgotten the footnote that not everything has a C API, not BetterC supports everything in ISO C, or common extensions.

Hint, before keeping to discuss what D can and cannot do, better go look how long I have been around on D forums, or existing projects on my Github.

Re: D Programming Language

#254
post #249

Earlier quoted context omitted.

You also need bindings in D, nothing new there. Rust also has issues using anything besides cargo.

> Rust also has issues using anything besides cargo. D also has its own build system but it's not the only option. Meson officially supports building D sources. You could also easily integrate D with SCons, though there's no official support.

Well, you can do the same with Java and C#, assuming you actually know the ecosystem.

Re: D Programming Language

#255
post #253

Earlier quoted context omitted.

> You also need bindings in D, nothing new there. You don't. Any D compiler is a C compiler too, so it can take C headers without bindings or any overhead added.

You have forgotten the footnote that not everything has a C API, not BetterC supports everything in ISO C, or common extensions. Hint, before keeping to discuss what D can and cannot do, better go look how long I have been around on D forums, or existing projects on my Github.

> not everything has a C API

Anything that has stable ABI does.

> go look how long I have been around on D forums

You claimed higher up in this thread that D requires bindings to interoperate with C API. You don't seem that well informed really.

Re: D Programming Language

#256
post #85
post #51

I often see people lament the lack of popularity for D in comparison to Rust. I've always been curios about D as I like a lot of what Rust does, but never found the time to deep dive and would appreciate someone whetting my appetite. Are there technical reasons that Rust took off and D didn't? What are some advantages of D over Rust (and vice versa)?

> Are there technical reasons that Rust took off and D didn't? As someone who considered it back then when it actually stood a chance to become the next big thing, from what I remember, the whole ecosystem was just too confusing and simply didn't look stable and reliable enough to build upon long-term. A few examples: * The compiler situation: The official compiler was not yet FOSS and other compilers were not availa…

> This whole GC vs no-GC thingy

And I am here, enjoying both. Life is good.

Re: D Programming Language

#257
post #89

Earlier quoted context omitted.

Is Java even a "systems programming" language? I don't even know what that term means anymore; but afaik Java didn't really have reliable low-level APIs until recently.

Depends if one considers writing compilers, linkers, JITs, database engines, and running bare metal on embedded real time systems "systems programming".

so, "yes", but with added sarcasm? :D

Re: D Programming Language

#258
post #226

Earlier quoted context omitted.

Nick Offerman wants to have a word with you. Given the choice of building my own furniture and things or IKEA and I had the skills I’d go the build it myself route. It’s doable. It was before. And it still is. All we got now is super duper capable auto correct and text completion. Use it for what it is. Don’t let it replace you.

An actor, that happens do carpentry as hobby.

s/Nick Offerman/any talented carpenter.... you missed the point, though

Re: D Programming Language

#259
post #237

Earlier quoted context omitted.

The point is that if you need performance you need to drop below tracing GC, and depending on your use-case, if that's the majority of your code it makes sense to use a language that's built for that kind of programming (zero cost abstractions). Writing C# that doesn't allocate is like wearing a straightjacket and the language doesn't help you much with manual memory management. Linters kind of make it more manageabl…

I rather have the productivity of a GC (regardless of which kind), manual allocations on system/unsafe code blocks, and value types, than going back to bare bones C style programming, unless there are constraints in place that leave no other option. Note that even Rust's success, has triggered managed languages designers to research how far they can integrate linear, affine, effects, dependent types into their existi…

This is essentially how I feel -- GC by default with user control over zero-copy/stackalloc behavior.

Modern .NET isn't even difficult to avoid allocations, with the Span API and the work they've done to minimize unnecessary copies/allocs within the std lib.

(I say this as a Kotlin/JVM dev who watches from the sideline, so not even the biggest .NET guy around here)

Re: D Programming Language

#260
post #85
post #51

I often see people lament the lack of popularity for D in comparison to Rust. I've always been curios about D as I like a lot of what Rust does, but never found the time to deep dive and would appreciate someone whetting my appetite. Are there technical reasons that Rust took off and D didn't? What are some advantages of D over Rust (and vice versa)?

> Are there technical reasons that Rust took off and D didn't? As someone who considered it back then when it actually stood a chance to become the next big thing, from what I remember, the whole ecosystem was just too confusing and simply didn't look stable and reliable enough to build upon long-term. A few examples: * The compiler situation: The official compiler was not yet FOSS and other compilers were not availa…

The compiler situation

I think people forget this. I know a lot of folks that looked at D back when it needed to win mindshare to compete with the currently en vogue alternatives, and every one of them nope'd out on the licensing. By the time they FOSS'ed it, they'd all made decisions for the alternative, and here we are.

Post reply on HN