Permalink
ReplyI think D can safely be used in production. If the sublanguage of D that you actually know all works well, then it's good to go! :D
October 30, 2022 Re: Is D really that bad? | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Imperatorn | ||||
October 30, 2022 Re: Is D really that bad? | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Daniel Donnelly, Jr. | On Sunday, 30 October 2022 at 19:05:35 UTC, Daniel Donnelly, Jr. wrote: >I think D can safely be used in production. If the sublanguage of D that you actually know all works well, then it's good to go! :D I think so too. But sometimes I get the feeling there's a belief that you can't. I want to understand where this belief comes from. If you can use C in production you can use D in production. It's kinda weird that someone can state "D isn't production ready" while at the same time say "Zig is production ready" when their own community explicitly says "don't use it in production", "it's unstable". It does not compute my friends. Clarification: | |||
October 30, 2022 Re: Why is D's GC slower than GO's? | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Walter Bright | On Sunday, 30 October 2022 at 18:42:58 UTC, Walter Bright wrote: > On 10/30/2022 1:29 AM, Paulo Pinto wrote: >> Swift and Objective-C, the system programing languages of Apple also have multiple pointer types. > > Do you have a reference? I did some googling, and didn't come up with anything. You can read the documentation over here, https://clang.llvm.org/docs/AutomaticReferenceCounting.html https://developer.apple.com/library/archive/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011226 https://docs.swift.org/swift-book/LanguageGuide/AutomaticReferenceCounting.html And if there is some legacy Objective-C 2.0 GC code lying around, there is https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/GarbageCollection/Introduction.html#//apple_ref/doc/uid/TP40002431 Basically the attribute qualifiers for pointers and class properties, specially in Objective-C case, and the Swift Objective-C interop, influence the semantics and type semantics of what ARC does with the pointers and their compatibility with raw pointers that aren't managed by ARC. And the now dead tracing GC experiement, also had its own flavour of GC managed pointers alongside raw ones. | |||
October 30, 2022 Re: Why is D's GC slower than GO's? | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Paulo Pinto | On Sunday, 30 October 2022 at 19:26:56 UTC, Paulo Pinto wrote: > > You can read the documentation over here, > > https://clang.llvm.org/docs/AutomaticReferenceCounting.html > > https://developer.apple.com/library/archive/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011226 > > https://docs.swift.org/swift-book/LanguageGuide/AutomaticReferenceCounting.html > > And if there is some legacy Objective-C 2.0 GC code lying around, there is > > https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/GarbageCollection/Introduction.html#//apple_ref/doc/uid/TP40002431 > > Basically the attribute qualifiers for pointers and class properties, specially in Objective-C case, and the Swift Objective-C interop, influence the semantics and type semantics of what ARC does with the pointers and their compatibility with raw pointers that aren't managed by ARC. > > And the now dead tracing GC experiement, also had its own flavour of GC managed pointers alongside raw ones. Just for completeness, the Swift developers are currently experimenting with an ownership model. Because this overlaps a little bit what is happening with D, I provide you a link. https://github.com/apple/swift/blob/main/docs/OwnershipManifesto.md This would mean that Swift would be more Rust like and this also includes runtime no aliasing checks. If this will make into version 7 remains to be seen. | |||
October 30, 2022 Re: Why is D's GC slower than GO's? | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Paulo Pinto | On 10/30/2022 12:26 PM, Paulo Pinto wrote: > You can read the documentation over here, > > https://clang.llvm.org/docs/AutomaticReferenceCounting.html > > https://developer.apple.com/library/archive/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011226 > > https://docs.swift.org/swift-book/LanguageGuide/AutomaticReferenceCounting.html I didn't realize you classified ARC as a separate pointer type. You can't do pointy things with it like pointer arithmetic, or taking the address of a variable with it. It's sort of like an associative array in D is a special type, but not what I'd consider a pointer type. Even class references in D are not really a special pointer type. But thank you for the references. > And if there is some legacy Objective-C 2.0 GC code lying around, there is > > https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/GarbageCollection/Introduction.html#//apple_ref/doc/uid/TP40002431 > > Basically the attribute qualifiers for pointers and class properties, specially in Objective-C case, and the Swift Objective-C interop, influence the semantics and type semantics of what ARC does with the pointers and their compatibility with raw pointers that aren't managed by ARC. > > And the now dead tracing GC experiement, also had its own flavour of GC managed pointers alongside raw ones. Does that mean it had managed pointers, and abandoned them? | |||
October 30, 2022 Re: Why is D's GC slower than GO's? | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Imperatorn | On 10/30/2022 11:51 AM, Imperatorn wrote:
> On Sunday, 30 October 2022 at 18:42:58 UTC, Walter Bright wrote:
>> On 10/30/2022 1:29 AM, Paulo Pinto wrote:
>>> Swift and Objective-C, the system programing languages of Apple also have multiple pointer types.
>>
>> Do you have a reference? I did some googling, and didn't come up with anything.
>
> https://mobikul.com/pointers-in-swift/
Interesting. I didn't know that.
| |||
October 30, 2022 Re: Why is D's GC slower than GO's? | ||||
|---|---|---|---|---|
| ||||
Posted in reply to IGotD- | On 10/30/2022 1:14 PM, IGotD- wrote:
> Just for completeness, the Swift developers are currently experimenting with an ownership model. Because this overlaps a little bit what is happening with D, I provide you a link.
>
> https://github.com/apple/swift/blob/main/docs/OwnershipManifesto.md
>
> This would mean that Swift would be more Rust like and this also includes runtime no aliasing checks. If this will make into version 7 remains to be seen.
"If a storage reference expression evaluates to a storage reference that is implemented by a variable, then the formal access duration of that access may not overlap the formal access duration of any other access to the same variable unless both accesses are reads."
That's exactly like ownership/borrowing. D does it in @live functions.
| |||
October 30, 2022 Re: Why is D's GC slower than GO's? | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Walter Bright | On Sunday, 30 October 2022 at 22:36:15 UTC, Walter Bright wrote: >That's exactly like ownership/borrowing. D does it in @live functions. I don't understand why is it not a goal to replace the GC with Swift / Nim-like reference counting. Stuff like Did you already consider and rejected this approach? You may also want to read this document: "Memory Management in Lobster". See the "Ownership Analysis" header specifically. I think this approach can finally rid us of endless GC bikeshedding, plus most people would be okay with reference counting at kernel level. Only thing to worry about is reference cycles, Nim solves that using tracing and Swift solves that using weak pointers. | |||
October 31, 2022 Re: Is D really that bad? | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Imperatorn | On Sunday, 30 October 2022 at 19:16:22 UTC, Imperatorn wrote: >It's kinda weird that someone can state "D isn't production ready" while at the same time say "Zig is production ready" when their own community explicitly says "don't use it in production", "it's unstable". It does not compute my friends. Given that there are plenty of people using D in production right now, I'd say it doesn't matter at all when someone says something like that. There always have been and always will be naysayers expressing negative opinions about D, and many of them aren't going to change their minds no matter what any of us do or say. You can't change minds that aren't open to changing. Meanwhile, the rest of us are using D to get stuff done and/or working to make it better. The best thing anyone who likes the language can do is to keep using it and promote their work. Write about it, share it, make videos about it, etc. There are people out there who are open to trying new languages. Content showing how we're using D to solve real-world problems will potentially entice them to try it. You can see that in discussion threads asking current D users how they came to D: it was this article, or that video, or that project. I rarely engage with anyone bashing D on reddit/HN or wherever anymore. There's usually no point to it. I'll leave a comment to correct misinformation when I see it (e.g., "there used to be two standard libraries, one GC and one non-GC, and the GC library won" was a recent one I found), or to clarify something. My comments in that case are for people reading the thread, not for the person I'm replying to. Sometimes the original commenter will reply with something like, "Thanks. I didn't know that." or "My info must be out of date.", but that's very rare in my experience. My advice: if you're happy with D, then ignore the crap people say and just get on with it. Work on your project, report issues, fix issues if you can, and if you can make the time, blog about your experiences. | |||
October 31, 2022 Re: Why is D's GC slower than GO's? | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Templated Person | On 31/10/2022 12:38 PM, Templated Person wrote:
> On Sunday, 30 October 2022 at 22:36:15 UTC, Walter Bright wrote:
>> That's exactly like ownership/borrowing. D does it in @live functions.
>
> I don't understand why is it not a goal to replace the GC with Swift / Nim-like reference counting. Stuff like `@live` already is in the works and can be used to optimize some reference count operations away.
Indeed a borrow checker could be used to elide calls to reference counting when you borrow the memory.
If only it wasn't opt-in on a function, and instead was guaranteed based upon the fact that it was borrowed...
Of course eliding can also occur if we have proper reference counting primitives for structs/classes. LLVM has directives for this to allow eliding regardless of what the frontend does.
It would also solve the const/immutable problem for reference counting types :)
| |||
Copyright © 1999-2021 by the D Language Foundation