digitalmars.D.announce - SerpentOS departs from Dlang
- M.M. (10/10) Sep 15 2023 In February there were some exciting news on the usage of dlang
- ryuukk_ (46/56) Sep 15 2023 That's unfortunate..
- Adam Wilson (16/19) Sep 16 2023 I would guess that the following is the bigger problem:
- Richard (Rikki) Andrew Cattermole (9/12) Sep 16 2023 The approach that I think will work well for us is to support reference
- sighoya (6/12) Sep 16 2023 On Saturday, 16 September 2023 at 10:22:31 UTC, Richard (Rikki)
- Richard (Rikki) Andrew Cattermole (8/22) Sep 16 2023 Basically DIP1000 handles the final leg of lifetime management, rather
- Adam Wilson (9/11) Sep 16 2023 How dare you bring the High Heresy of write barriers into D! I
- Richard (Rikki) Andrew Cattermole (26/30) Sep 16 2023 The scope of each doesn't match up, and you'd still need the RC specific...
- ryuukk_ (15/45) Sep 17 2023 I hope we'll see tagged union + tuple come first before that mess
- Richard (Rikki) Andrew Cattermole (16/16) Sep 17 2023 The announcement post from Ikey included as its only explicit mention of...
- Imperatorn (5/12) Sep 16 2023 To be fair though, you could just have a map between string and
- Greggor (33/92) Sep 20 2023 I do not think the lack of a little bit of syntax sugar is what
In February there were some exciting news on the usage of dlang within serpent-os linux distribution, quite a large open source project of Ikey Doherty and the team around him. Unfortunately, the project decided to leave dlang behind, and to embrace golang and rust instead... in part due to some hiccups in dlang and due to contributors pushing for more mainstream languages: https://serpentos.com/blog/2023/09/06/oxidised-moss/ Pity that it did not succeed. It would be a great showcase for the marvelous dlang.
Sep 15 2023
On Friday, 15 September 2023 at 17:39:41 UTC, M.M. wrote:In February there were some exciting news on the usage of dlang within serpent-os linux distribution, quite a large open source project of Ikey Doherty and the team around him. Unfortunately, the project decided to leave dlang behind, and to embrace golang and rust instead... in part due to some hiccups in dlang and due to contributors pushing for more mainstream languages: https://serpentos.com/blog/2023/09/06/oxidised-moss/ Pity that it did not succeed. It would be a great showcase for the marvelous dlang.That's unfortunate.. Ikey seems to still want to use D, so the main driving factor is the contributors, i wonder what are the exact reasons, pseudo memory safety can't be the only reason To be honest, I wouldn't blame contributors for looking at more mainstream languages, who still want to do their switch cases this way: ```D switch (it) { case MySuperLongEnum.MySuperLongValueA: result = do_something_a(); break; case MySuperLongEnum.MySuperLongValueB: result = do_something_b(); break; case MySuperLongEnum.MySuperLongValueC: result = do_something_c(); break; } ``` When other languages have it cleaner: ```D result = switch (it) { .MySuperLongValueA: do_something_a(); .MySuperLongValueB: do_something_b(); .MySuperLongValueC: do_something_c(); } ``` Improving ergonomics won't necessarily attract people, probably not, but i'm pretty sure that'll make contributors of existing projects not request to change language because the ergonomics are so poor their language and even improve their compiler to avoid the urge to switch to Go (NativeAOT), even Java made appropriate language changes in hope to stay relevant, why only D should be frozen? Acting like the world depend on D D has many benefits, but some areas need lot of love, this reminds me of this dude in an online chat, he said the reason why he stick to Rust was because of Rust's enum.. not because of memory safety Hopefully more wake up calls like this one will resonate with the D foundation
Sep 15 2023
On Friday, 15 September 2023 at 21:49:17 UTC, ryuukk_ wrote:Ikey seems to still want to use D, so the main driving factor is the contributors, i wonder what are the exact reasons, pseudo memory safety can't be the only reasonI would guess that the following is the bigger problem: "we don't quite have the resources to also be an upstream for the numerous D packages we'd need to create and maintain to get our works over the finish line." This has long been a chicken-egg problem for D. We need more packages to attract more users, but we need more users building packages before we can attract more users. DIP1000 is also a bit of marketing problem. We kinda-sorta promise that someday you'll be able to build memory safe programs without a GC. We need to either push through and get it done, or admit we're not actually going to get there and cut it. I know there are ref-counted languages so theoretically it should be workable, but the in a language as complex as D there may be dragons on the edges. In any case, we should not be marketing something we can't actually do.
Sep 16 2023
On 16/09/2023 9:02 PM, Adam Wilson wrote:I know there are ref-counted languages so theoretically it should be workable, but the in a language as complex as D there may be dragons on the edges.The approach that I think will work well for us is to support reference counting on structs & classes, and make them not adhere to DIP1000. Then you borrow memory from them, and DIP1000 takes over. This minimizes the surface area of the language that needs to understand reference counting and life time handling. So our one dimensional approach with DIP1000, will absolutely shine. I will be doing the DIP for RC due to its cost of it and the fact that modern backends do understand it and can make it cheaper.
Sep 16 2023
On Saturday, 16 September 2023 at 10:22:31 UTC, Richard (Rikki) Andrew Cattermole wrote:The approach that I think will work well for us is to support reference counting on structs & classes, and make them not adhere to DIP1000.Does that mean you are against dip1000 or do you want both?I will be doing the DIP for RC due to its cost of it and the fact that modern backends do understand it and can make it cheaper.Will it be automated reference counting with a special type of GC doing the job or a local RC container?
Sep 16 2023
On 17/09/2023 12:25 AM, sighoya wrote:On Saturday, 16 September 2023 at 10:22:31 UTC, Richard (Rikki) Andrew Cattermole wrote:Basically DIP1000 handles the final leg of lifetime management, rather than managing the actual ownership of memory. It comes into play after you borrow from a container.The approach that I think will work well for us is to support reference counting on structs & classes, and make them not adhere to DIP1000.Does that mean you are against dip1000 or do you want both?Its basically what we do now with copy constructors + destructors, but inside dedicated methods. Although I do want a write barrier on each struct/class, to allow for cyclic handling especially for classes.I will be doing the DIP for RC due to its cost of it and the fact that modern backends do understand it and can make it cheaper.Will it be automated reference counting with a special type of GC doing the job or a local RC container?
Sep 16 2023
On Saturday, 16 September 2023 at 12:34:24 UTC, Richard (Rikki) Andrew Cattermole wrote:Although I do want a write barrier on each struct/class, to allow for cyclic handling especially for classes.How dare you bring the High Heresy of write barriers into D! I thought that it was well understand that even mentioning Write Barriers is a mortal sin against the Church of nogc. Kidding aside. If you do this, you might as well turn them on everywhere. After that it's a easy stroll to a non-blocking moving GC, which would end most complaints about the GC (nobody complains about the .NET GC anymore).
Sep 16 2023
On 17/09/2023 11:46 AM, Adam Wilson wrote:Kidding aside. If you do this, you might as well turn them on everywhere. After that it's a easy stroll to a non-blocking moving GC, which would end most complaints about the GC (nobody complains about the .NET GC anymore).The scope of each doesn't match up, and you'd still need the RC specific write barriers. So when I say write barrier what I mean is: ```d class MyRoot : void { void opRCWriteBarrier(size_t fieldOffset, void* pointer) { myCyclicDetector.set(cast(void*)this, fieldOffset, pointer); } void opRCSub() { if (atomicOp!"-="(this.refCount, 1) > 0) myCyclicDetector.collect(cast(void*)this); } } class Child : MyRoot { Array!int array; void func() { array = new Array!int(); // this.opRCWriteBarrier(array.offsetof, cast(void*)array); } } ``` Only needs to support classes + structs (I think), so its surface area is pretty small. Oh and Walter has approved anyone to experiment with write barriers ages ago, although nobody has.
Sep 16 2023
On Sunday, 17 September 2023 at 00:55:22 UTC, Richard (Rikki) Andrew Cattermole wrote:On 17/09/2023 11:46 AM, Adam Wilson wrote:I hope we'll see tagged union + tuple come first before that mess you are describing, because to me this sound like a giant waste of effort, time and opportunity You'll never attract more people if you focus on OOP / GC, that kind of code is repulsive to be honest Tagged Union alone will help build libraries that doesn't require that OOP crap and help reduce the need of a GC significantly, more structs, less class, more values less heap allocated garbage for a collector to stop the world D has ton of features that help avoid GC completely, let's focus on more of that Atila, didn't you say "allocator good", so where are they? leadership is also frozen?Kidding aside. If you do this, you might as well turn them on everywhere. After that it's a easy stroll to a non-blocking moving GC, which would end most complaints about the GC (nobody complains about the .NET GC anymore).The scope of each doesn't match up, and you'd still need the RC specific write barriers. So when I say write barrier what I mean is: ```d class MyRoot : void { void opRCWriteBarrier(size_t fieldOffset, void* pointer) { myCyclicDetector.set(cast(void*)this, fieldOffset, pointer); } void opRCSub() { if (atomicOp!"-="(this.refCount, 1) > 0) myCyclicDetector.collect(cast(void*)this); } } class Child : MyRoot { Array!int array; void func() { array = new Array!int(); // this.opRCWriteBarrier(array.offsetof, cast(void*)array); } } ``` Only needs to support classes + structs (I think), so its surface area is pretty small. Oh and Walter has approved anyone to experiment with write barriers ages ago, although nobody has.
Sep 17 2023
"Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> The announcement post from Ikey included as its only explicit mention of something bad about D itself that DIP1000 was incomplete. My mention of reference counting as a way to allow for a complete story for DIP1000 matched this goal that also matched what other people wanted here. Not everyone has the same priorities, especially when it comes to comparing a minor feature that is almost in the language already, to a major feature that will take years to complete. Lets be clear on something, I want sum types. I need sum types for value type exceptions which are waiting on only sum types. I do not believe that Walter's DIP is complete enough to be a "good" design to further this goal. Disparaging me because I placed a higher priority on something critical to my 110k+ LOC code base performance wise, does not aid in your goal of the addition of a major feature which pretty much everyone wants at some level.
Sep 17 2023
On Friday, 15 September 2023 at 21:49:17 UTC, ryuukk_ wrote:On Friday, 15 September 2023 at 17:39:41 UTC, M.M. wrote:To be fair though, you could just have a map between string and func like result = func[myEnumName] or use metaprogramming. But yes, D would benefit from having real pattern matching.[...]That's unfortunate.. Ikey seems to still want to use D, so the main driving factor is the contributors, i wonder what are the exact reasons, pseudo memory safety can't be the only reason [...]
Sep 16 2023
On Friday, 15 September 2023 at 21:49:17 UTC, ryuukk_ wrote:On Friday, 15 September 2023 at 17:39:41 UTC, M.M. wrote:I do not think the lack of a little bit of syntax sugar is what is hurting D. Also `with` is your friend. ```D auto result = (){with(MySuperLongEnum) final switch(it){ case MySuperLongValueA: return do_something_a(); case MySuperLongValueB: return do_something_b(); case MySuperLongValueC: return do_something_c(); }}(); ``` full version that will compile, if you want to play with this. ```D safe: enum MySuperLongEnum{ MySuperLongValueA, MySuperLongValueB, MySuperLongValueC, } int do_something_a(){ return 1; } int do_something_b(){ return 42; } int do_something_c(){ return 99; } void main(){ auto it = MySuperLongEnum.MySuperLongValueB; auto result = (){with(MySuperLongEnum) final switch(it){ case MySuperLongValueA: return do_something_a(); case MySuperLongValueB: return do_something_b(); case MySuperLongValueC: return do_something_c(); }}(); import std.stdio; writeln("result: ", result); } ```In February there were some exciting news on the usage of dlang within serpent-os linux distribution, quite a large open source project of Ikey Doherty and the team around him. Unfortunately, the project decided to leave dlang behind, and to embrace golang and rust instead... in part due to some hiccups in dlang and due to contributors pushing for more mainstream languages: https://serpentos.com/blog/2023/09/06/oxidised-moss/ Pity that it did not succeed. It would be a great showcase for the marvelous dlang.That's unfortunate.. Ikey seems to still want to use D, so the main driving factor is the contributors, i wonder what are the exact reasons, pseudo memory safety can't be the only reason To be honest, I wouldn't blame contributors for looking at more mainstream languages, who still want to do their switch cases this way: ```D switch (it) { case MySuperLongEnum.MySuperLongValueA: result = do_something_a(); break; case MySuperLongEnum.MySuperLongValueB: result = do_something_b(); break; case MySuperLongEnum.MySuperLongValueC: result = do_something_c(); break; } ``` When other languages have it cleaner: ```D result = switch (it) { .MySuperLongValueA: do_something_a(); .MySuperLongValueB: do_something_b(); .MySuperLongValueC: do_something_c(); } ``` Improving ergonomics won't necessarily attract people, probably not, but i'm pretty sure that'll make contributors of existing projects not request to change language because the ergonomics are so poor their language and even improve their compiler to avoid the urge to switch to Go (NativeAOT), even Java made appropriate language changes in hope to stay relevant, why only D should be frozen? Acting like the world depend on D D has many benefits, but some areas need lot of love, this reminds me of this dude in an online chat, he said the reason why he stick to Rust was because of Rust's enum.. not because of memory safety Hopefully more wake up calls like this one will resonate with the D foundation
Sep 20 2023