5 ms·

Sigh. Ownership and borrowing are so much less baroque in D than in Rust. And compile times are superb. In a better world, we would all be using D instead of

Sigh. Ownership and borrowing are so much less baroque in D than in Rust. And compile times are superb. In a better world, we would all be using D instead of C, C++ or Rust. However in this age of Kali...

pjmlp 8mo ago
Slowly it is going to be only skills.md. I agree with the sentiment, I really like D and find a missing opportunity that it wasn't taken off regarding adoption. Most of what made D special in D is nowadays partially available in mainstream languages, making the adoption speech even harder, and lack of LLM training data doesn't help either.
- bigstrat2003 8mo ago
  > lack of LLM training data doesn't help either. That shouldn't stop any self-respecting programmer.
  - feastingonslop 8mo ago
    Nor does it stop self-respecting LLMs.
  - usrnm 8mo ago
    Self-respecting programmers write assembly for the machines they built themselves. I swear, kids these days have no respect for the craft
  - gigatexal 8mo ago
    Exactly. We wrote code before LLMs and we can after their advent too
    - pjmlp 8mo ago
      Yeah, that is why carpenters are still around and no one buys Ikea.
      - tjr 8mo ago
        Is your proposition that programmers are now incapable of writing code?
        pjmlp 8mo ago
        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 ones that can invert a tree, calculate how many golf balls fit into a plane, and are elected to work at the AI dungeons as the new druids.
        anonzzzies 8mo ago
        Same for ERP/CRM/HRM and some financial systems ; all systems that were heavy 'no-code' (or a lot of configuration with knobs and switches rather than code) before AI are now just going to lose their programmers (and the other roles); the business logic / financial calcs etc were already done by other people upfront in excel, visio etc ; now you can just throw that into Claude Code. These systems have decades of rigid code practices so there is not a lot of architecting/design to be done in the first place.
        tmtvl 8mo ago
        While I don't share this cynical worldview, I am mildly amused by the concept of a future where, Warhammer 40,000 style, us code monkeys get replaced by tech priests who appease the machine gods by burning incense and invoking hymns.
        gigatexal 8mo ago
        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.
  - pjmlp 8mo ago
    Self respecting developers are an endangered species, otherwise we would not have so much Electron crap. Those that learn to do robot maintenance, are the ones left at the factory.
- baruch 8mo ago
  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.
  - pjmlp 8mo ago
    I based my opinion on this recent thread, https://forum.dlang.org/thread/bvteanmgrxnjiknrkeyg@forum.dlang.org 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.
    - baruch 8mo ago
      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.
- gmueckl 8mo ago
  My experience is that all LLMs that I have tested so far did a very good job producing D code. I actually think that the average D code produced has been superior to the code produced for the C++ problems I tested. This may be an outlier (the problems are quite different), but the quality issues I saw on the C++ side came partially from the ease in which the language enables incompatible use of different features to achieve similar goals (e.g. smart_ptr s new/delete).
chhs 8mo ago
For those curious what ownership and borrowing looks like in D: https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/ https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in...
- randfur 8mo ago
  I don't know D so I'm probably missing some basic syntax. If pointers cannot be copied how do you have multiple objects referencing the same shared object?
  - andsoitis 8mo ago
    > If pointers cannot be copied They can.
- uecker 8mo ago
  Is there any experience on how this works in practice?
- fooker 8mo ago
  This is a somewhat simplistic view of ownership and borrowing for modern programming languages. Pointers are not the only 'pointer's to resources. You can have handles specific to your codebase or system, you can have indices to objects in some flat array that the rest of your codebase uses, even temporary file names. An object oriented (or 'multi paradigm') language has to account for these and not just literal pointers. This is handled reasonably well both in Rust and C++. (In the spirit of avoiding yet another C++ vs Rust flamewar here, yes the semantics are different, no it doesn not make sense for C++ to adopt Rust semantics)
  - tgv 8mo ago
    How does Rust (or C++) treat array indices as resources? And won't that defy the reason to use indices over pointers?
    - fooker 8mo ago
torginus 8mo ago
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 incredibly difficult to handle. Tbh - this is with good reason, 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, both for the compiler and the programmer. And it's a simple case, OOP offers tons of tools to make the programmers job even more difficult - virtual methods, object chains with callbacks, etc. It's just not a clean programming style. Edit: Just to make it clear, I am not pointing out these problems, to sell you or even imply that I have the solution. I'm not saying programming style X is better.
- FeepingCreature 8mo ago
  I work at a D company. We tend to use OOP only for state owners with strict dependencies, so it's rare to even get cycles. It is extremely useful for modeling application state. However, all the domain data is described by immutable values and objects are accessed via parameters as much as fields. When commandline apps were everywhere, people dreamed of graphical interfaces. Burdened by having to also do jobs that it was bad at, the commandline got a bad reputation. It took the dominance of the desktop for commandline apps to find their niche. In a similar way, OOP is cursed by its popularity. It has to become part of a mixed diet so that people can put it where it has advantages, and it does have advantages.
- arcadia_leak 8mo ago
  On the flipside, with OOP is usually quite easy to put a debugger breakpoint on a particular line and see the full picture of what the program is doing. In diehard FP (e.g. Haskell) it's hard to even place a breakpoint, let alone see the complete state. In many cases, where implementing a piece of logic without carrying a lot of state is impossible, functional programming can also become very confusing. This is especially true when introducing certain theoretical concepts that facilitate working with IO and state, such as Monad Transformers.
fuzztester 8mo ago
Kali Yuga. https://en.wikipedia.org/wiki/Kali_Yuga https://en.wikipedia.org/wiki/Kali_Yuga

pjmlp 8mo ago

Slowly it is going to be only skills.md. I agree with the sentiment, I really like D and find a missing opportunity that it wasn't taken off regarding adoption. Most of what made D special in D is nowadays partially available in mainstream languages, making the adoption speech even harder, and lack of LLM training data doesn't help either.

bigstrat2003 8mo ago
> lack of LLM training data doesn't help either. That shouldn't stop any self-respecting programmer.
- feastingonslop 8mo ago
  Nor does it stop self-respecting LLMs.
- usrnm 8mo ago
  Self-respecting programmers write assembly for the machines they built themselves. I swear, kids these days have no respect for the craft
- gigatexal 8mo ago
  Exactly. We wrote code before LLMs and we can after their advent too
  - pjmlp 8mo ago
    Yeah, that is why carpenters are still around and no one buys Ikea.
    - tjr 8mo ago
      Is your proposition that programmers are now incapable of writing code?
      - pjmlp 8mo ago
        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 ones that can invert a tree, calculate how many golf balls fit into a plane, and are elected to work at the AI dungeons as the new druids.
        anonzzzies 8mo ago
        Same for ERP/CRM/HRM and some financial systems ; all systems that were heavy 'no-code' (or a lot of configuration with knobs and switches rather than code) before AI are now just going to lose their programmers (and the other roles); the business logic / financial calcs etc were already done by other people upfront in excel, visio etc ; now you can just throw that into Claude Code. These systems have decades of rigid code practices so there is not a lot of architecting/design to be done in the first place.
        tmtvl 8mo ago
        While I don't share this cynical worldview, I am mildly amused by the concept of a future where, Warhammer 40,000 style, us code monkeys get replaced by tech priests who appease the machine gods by burning incense and invoking hymns.
        gigatexal 8mo ago
        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.
- pjmlp 8mo ago
  Self respecting developers are an endangered species, otherwise we would not have so much Electron crap. Those that learn to do robot maintenance, are the ones left at the factory.
baruch 8mo ago
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.
- pjmlp 8mo ago
  I based my opinion on this recent thread, https://forum.dlang.org/thread/bvteanmgrxnjiknrkeyg@forum.dlang.org 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.
  - baruch 8mo ago
    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.
gmueckl 8mo ago
My experience is that all LLMs that I have tested so far did a very good job producing D code. I actually think that the average D code produced has been superior to the code produced for the C++ problems I tested. This may be an outlier (the problems are quite different), but the quality issues I saw on the C++ side came partially from the ease in which the language enables incompatible use of different features to achieve similar goals (e.g. smart_ptr s new/delete).

chhs 8mo ago

For those curious what ownership and borrowing looks like in D: https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/ https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in...

randfur 8mo ago
I don't know D so I'm probably missing some basic syntax. If pointers cannot be copied how do you have multiple objects referencing the same shared object?
- andsoitis 8mo ago
  > If pointers cannot be copied They can.
uecker 8mo ago
Is there any experience on how this works in practice?
fooker 8mo ago
This is a somewhat simplistic view of ownership and borrowing for modern programming languages. Pointers are not the only 'pointer's to resources. You can have handles specific to your codebase or system, you can have indices to objects in some flat array that the rest of your codebase uses, even temporary file names. An object oriented (or 'multi paradigm') language has to account for these and not just literal pointers. This is handled reasonably well both in Rust and C++. (In the spirit of avoiding yet another C++ vs Rust flamewar here, yes the semantics are different, no it doesn not make sense for C++ to adopt Rust semantics)
- tgv 8mo ago
  How does Rust (or C++) treat array indices as resources? And won't that defy the reason to use indices over pointers?
  - fooker 8mo ago

torginus 8mo ago

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 incredibly difficult to handle. Tbh - this is with good reason, 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, both for the compiler and the programmer. And it's a simple case, OOP offers tons of tools to make the programmers job even more difficult - virtual methods, object chains with callbacks, etc. It's just not a clean programming style. Edit: Just to make it clear, I am not pointing out these problems, to sell you or even imply that I have the solution. I'm not saying programming style X is better.

FeepingCreature 8mo ago
I work at a D company. We tend to use OOP only for state owners with strict dependencies, so it's rare to even get cycles. It is extremely useful for modeling application state. However, all the domain data is described by immutable values and objects are accessed via parameters as much as fields. When commandline apps were everywhere, people dreamed of graphical interfaces. Burdened by having to also do jobs that it was bad at, the commandline got a bad reputation. It took the dominance of the desktop for commandline apps to find their niche. In a similar way, OOP is cursed by its popularity. It has to become part of a mixed diet so that people can put it where it has advantages, and it does have advantages.
arcadia_leak 8mo ago
On the flipside, with OOP is usually quite easy to put a debugger breakpoint on a particular line and see the full picture of what the program is doing. In diehard FP (e.g. Haskell) it's hard to even place a breakpoint, let alone see the complete state. In many cases, where implementing a piece of logic without carrying a lot of state is impossible, functional programming can also become very confusing. This is especially true when introducing certain theoretical concepts that facilitate working with IO and state, such as Monad Transformers.

fuzztester 8mo ago

Kali Yuga. https://en.wikipedia.org/wiki/Kali_Yuga https://en.wikipedia.org/wiki/Kali_Yuga