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

221–230 of 278 posts

Re: D Programming Language

#221

Post by torginus »

pjmlp wrote: post #49
torginus wrote: post #31

Earlier quoted context omitted.

OOP and ownership are two concepts that mix poorly - ownership in the presence of OOP-like constructs is never simple. The reason for that is OOP tends to favor constructs where each objects holds references to other objects, creating whole graphs, its not uncommon that from a single object, hundreds of others can be traversed. Even something so simple as calling a member function from a member function becomes incre…

It worked alright for Rust, and yes Rust does support OOP, there are many meanings to what is OOP from CS point of view. I have ported Ray Tracing in One Weekend into Rust, while keeping the same OOP design from the tutorial, and affine types were not an impediment to interfaces, polymorphism and dynamic dispatch.

I don't think it worked well for Rust - in fact one of the core issues of Rust imo, is that it somewhat encourages this OOP style which can cause major headaches when you design an app in a traditional OO way - object compostion, complex and stateful, non-copyable objects full of 'smart' behavior, necessitating clones, and state that needs to be reconciled.

The whole concept of OOP is a major conceptual regression in how it treats aliasing, which is a major headache for compiler writers, necessitating either whole program analysis or JIT like techniques.

Re: D Programming Language

#222

Post by torginus »

abbbyz wrote: post #54
torginus wrote: post #31

Earlier quoted context omitted.

OOP and ownership are two concepts that mix poorly - ownership in the presence of OOP-like constructs is never simple. The reason for that is OOP tends to favor constructs where each objects holds references to other objects, creating whole graphs, its not uncommon that from a single object, hundreds of others can be traversed. Even something so simple as calling a member function from a member function becomes incre…

>one of the biggest flaws of OOP is that if x.foo() calls x.bar() in the middle, x.bar() can clobber a lot of local state, and result in code that's very difficult to reason about That's more a problem of having mutable references, you'd have the same problem in a procedural language.

Very few OO languages track reference mutability with any level of rigor. In C/C++ most devs don't even know what restrict is or how to write code using it correctly (which is very difficult an bug prone), const is unfortunately not enough.

In fact I don't even know of any production language that handles variable mutability with any rigor other than Rust.

Re: D Programming Language

#223

Post by pjmlp »

schveiguy wrote: post #199
pjmlp wrote: post #88

Earlier quoted context omitted.

GCC usually drops frontends if there are no maintainers around, it already happened to gcj, and I am waiting for the same to happen to gccgo any time now, as it has hardly gotten any updates since Go 1.18. The team is quite small and mostly volunteers, so there is the question how long can Walter Bright keep at it, and who will keep it going afterwards when he passes the torch.

gdc is 100% Iain Buclaw. But he and Walter collaborate on needs for gcc compatibility, as long as Iain is around, gdc will be around. It is true we have a small team. But we are a dedicated team.

And was for several releases delayed due to personal issues, which is understandable in a small team among open source projects, however it is a problem.

Re: D Programming Language

#224

Post by baruch »

pjmlp wrote: post #46
baruch wrote: post #19

Earlier quoted context omitted.

I work with D and LLMs do very well with it. I don't know if it could be better but it does D well enough. The problem is only working on a complex system that cannot all be held in context at once.

I based my opinion on this recent thread, https://forum.dlang.org/thread/bvteanmgrxnjiknrkeyg@forum.dl... Which the discussion seems to imply it kind of works, but not without a few pain points.

The complaints are against the open-weight LLMs, I didn't try them much. I do use mostly Claude as that's what the company is paying for. They don't pay for laptops with GPUs or locally hosted LLMs to test those.

It's not like it knows perfect D, it does make mistakes and I don't work on a C++ or Rust project to compare its behavior. Generating templates from scratch is a bit of a challenge but given we have plenty of examples in our code with some prodding it manages to write well enough.

Re: D Programming Language

#225

Post by pjmlp »

torginus wrote: post #221
pjmlp wrote: post #49

Earlier quoted context omitted.

It worked alright for Rust, and yes Rust does support OOP, there are many meanings to what is OOP from CS point of view. I have ported Ray Tracing in One Weekend into Rust, while keeping the same OOP design from the tutorial, and affine types were not an impediment to interfaces, polymorphism and dynamic dispatch.

I don't think it worked well for Rust - in fact one of the core issues of Rust imo, is that it somewhat encourages this OOP style which can cause major headaches when you design an app in a traditional OO way - object compostion, complex and stateful, non-copyable objects full of 'smart' behavior, necessitating clones, and state that needs to be reconciled. The whole concept of OOP is a major conceptual regression in…

Hardly any different from structs with function pointers that are so praised among C and Zig devs.

Re: D Programming Language

#226

Post by pjmlp »

gigatexal wrote: post #206
pjmlp wrote: post #21

Earlier quoted context omitted.

Eventually yes, when incapable becomes a synonymous with finding a job in an AI dominated software factory industry. Enterprise CMS deployment projects have already dropped amount of assets teams, translators, integration teams, backend devs, replaced by a mix of AI, SaaS and iPaaS tools. Now the teams are a fraction of the size they used to be like five years ago. Fear not, there will be always a place for the few o…

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.

Re: D Programming Language

#227

Post by pjmlp »

ibgeek wrote: post #213
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 used to think of D as the same category as C# and Java, but I realized that it has two important differences. (I am much more experienced with Java/JVM than C#/.Net, so this may not all apply.) 1. Very load overhead calling of native libraries. Wrapping native libraries from Java using JNI requires quite a bit of complex code, configuring the build system, and the overhead of the calls. So, most projects only use l…

1. Java nowadays has Panama

2. Java and C# can also generate native binaries, just like Go, no need for VM.

3. C++ nowadays has concepts, modules and compile time execution

This wasn't true in 2010, but D has let them catch up with missing features.

Re: D Programming Language

#228

Post by pjmlp »

debugnik wrote: post #205
cardanome wrote: post #164

Earlier quoted context omitted.

> The fact that C# is becoming the GC language in game dev is proving my point. That is just the Unity effect. Godot adopted C# because they get paid to do so by Microsoft. C# allows for far lees control over the garbage collection compared to D. The decision to use C# is partly responsible for the bad reputation of Unity games as it causes a lot of stutters when people are not very careful about how to manage the me…

C# wouldn't be a problem for Unity if they hadn't mapped most engine abstractions to class hierarchies with reflection-based dispatch instead of value-type handles and the seldom interface, and had dropped the Boehm GC. .NET has actually got a lot of features to avoid allocations on the hot paths.

The problem is called Mono, and Unity's refusal to pay for an update.

Re: D Programming Language

#229

Post by p0nce »

jakkos wrote: 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?

This talk explain why, it's not technical: https://www.youtube.com/watch?v=XZ3w_jec1v8

> What are some advantages of D over Rust (and vice versa)?

Advantages for D: Build faster, in typical programs you would need about 20 packages not 100, COM objects, easy meta-programming, 3 compilers. GC, way better at scripting.

Advantages for Rust: borrow-checker is better. rustup.

Re: D Programming Language

#230

Post by pjmlp »

rafaelmn wrote: post #193
gavinray wrote: post #177

Earlier quoted context omitted.

The "GC is slow"/"JIT/VM's are slow" is such a tired, dated take at this point. Look at C#'s competitive placings with C++/Rust on The Computer Benchmark game due to .NET's ruthless optimization.

Ironically those optimizations came from .NET avoiding GC and introducing primitives to avoid it better. And .NET is moving heavily into the AoT/pre-compilation direction for optimization reasons as well (source generators, AoT). If you look at the change logs for the past few versions of the framework from perf perspective the most significant moves are : introduce new primitives to avoid allocating, move more logic…

So what, that is exactly the point.

A programming language having a GC doesn't mean every single allocation needs to be on the heap.

C# is finally at the sweet spot languages like Oberon, Modula-3 and Eiffel were on the late 90's, and unfortunely were overshadowed by Java's adoption.

Go and Swift (RC is a GC algorithm) are there as well.

D could be there as well on the mainstream, if there was a bit more steering into what they want to be, instead of having others catching up on its ideas.

That is what made me look into the language after getting Andrei Alexandrescu's book.

Post reply on HN