www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why are you using D instead of Rust?

reply Dr Machine Code <jckj33 gmail.com> writes:
Just would like to know you all opinions
Oct 22 2021
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 23 October 2021 at 04:25:21 UTC, Dr Machine Code 
wrote:

 Just would like to know you all opinions


I was using D long before Rust came along. It reeled me in from 
Java and C and I never looked back. It’s the only language I’ve 
used that I can honestly describe as fun. I have no reason to 
move to use Rust or any other language. I’m quite happy where I 
am.

And even if I were looking for something different, I don’t think 
Rust would be it. This may be superficial, but I just despise the 
syntax. That alone would be enough to keep me from even trying it 
without someone seriously persuading me otherwise.
Oct 22 2021
parent reply Dr Machine Code <jckj33 gmail.com> writes:
On Saturday, 23 October 2021 at 04:39:14 UTC, Mike Parker wrote:

 On Saturday, 23 October 2021 at 04:25:21 UTC, Dr Machine Code 
 wrote:

 Just would like to know you all opinions


 I was using D long before Rust came along. It reeled me in from 
 Java and C and I never looked back. It’s the only language I’ve 
 used that I can honestly describe as fun. I have no reason to 
 move to use Rust or any other language. I’m quite happy where I 
 am.





 And even if I were looking for something different, I don’t 
 think Rust would be it. This may be superficial, but I just 
 despise the syntax. That alone would be enough to keep me from 
 even trying it without someone seriously persuading me 
 otherwise.


Same here, I just despise the syntax and couldn't get much used 
to it. I've tried to use more than once
Oct 22 2021
parent Era Scarecrow <rtcvb32 yahoo.com> writes:
On Saturday, 23 October 2021 at 05:52:42 UTC, Dr Machine Code 
wrote:

 Same here, I just despise the syntax and couldn't get much used 
 to it. I've tried to use more than once


Same. I looked at Rust and decided it wasn't for me, as there's 
some familiar syntax and then new stuff i couldn't make heads or 
tails of.

  Same for C++, although my dislike for the language runs far 
deeper than Rust.
Dec 19 2021
prev sibling next sibling parent zjh <fqbqrr 163.com> writes:
On Saturday, 23 October 2021 at 04:25:21 UTC, Dr Machine Code 
wrote:

 Just would like to know you all opinions


Rust is just C++ with his hands tied.
Oct 22 2021
prev sibling next sibling parent workman <workman gmail.com> writes:
On Saturday, 23 October 2021 at 04:25:21 UTC, Dr Machine Code 
wrote:

 Just would like to know you all opinions


Because I RUST is hard and D is more easy,  I am stupid.
Oct 23 2021
prev sibling next sibling parent reply jfondren <julian.fondren gmail.com> writes:
On Saturday, 23 October 2021 at 04:25:21 UTC, Dr Machine Code 
wrote:

 Just would like to know you all opinions


I wrote the following code and was very pleased with it until I 
thought of showing it to a coworker who didn't know Rust. At that 
moment I was struck by the very low ratio of "does what the 
application needs doing"/"does what Rust needs doing", and the 
feeling of pride turned to embarrassment. I didn't want to have 
to explain why all the 'extra' code was needed, or what it did.

```rust

extern {
     fn crypt(key: *const c_char, salt: *const c_char) -> *c_char;
}

fn encrypts_to(key: &CString, salt: &CString, hash: &CString) -> 
bool {
     unsafe {
         let ret = crypt(key.as_ptr(), salt.as_ptr());
         if ret == std::ptr::null() { return false }
         hash.as_c_str() == CStr::from_ptr(ret)
     }
}

// ...


mod tests {
     use super::*;


     fn test_encrypts_to() {
         assert!(encrypts_to(
                 &CString::new("password").unwrap(),
                 &CString::new("$1$YzTLPnhJ$").unwrap(),
                 
&CString::new("$1$YzTLPnhJ$OZoHkjAYlIgCmOKQi.PXn.").unwrap(),
         ));
         assert!(encrypts_to(
                 &CString::new("monkey").unwrap(),
                 &CString::new("lh").unwrap(),
                 &CString::new("lhBnWgIh1qed6").unwrap(),
         ));
     }
}
```

the d equivalent:

```d
/+ dub.sdl:
     libs "crypt"
+/
extern (C) char* crypt(const(char)* key, const(char)* salt) 
 system;

bool encryptsTo(const(char)* key, const(char)* salt, const(char)* 
hash)  trusted {
     import std.string : fromStringz;

     return hash.fromStringz == crypt(key, salt).fromStringz;
}

unittest {
     assert(encryptsTo("password", "$1$YzTLPnhJ$", 
"$1$YzTLPnhJ$OZoHkjAYlIgCmOKQi.PXn."));
     assert(encryptsTo("monkey", "lh", "lhBnWgIh1qed6"));
     assert(encryptsTo("badsalt", "$$$", null));
}
```

This, long compile times, and losing sanity points over 
async/await servers is basically it for my objections to Rust at 
the time I gave d another look. Nowadays there would be more 
features that I'd miss from d, like better scripting, superior 
ctfe, generics, static reflection, and even code generation: Rust 
has a more syntax-abusive macro system but there's a lot of uses 
of it out there that are just "specialize this code over this 
list of types". And there's code like 
https://doc.rust-lang.org/stable/std/default/trait.Default.html#impl-Default-52

I think d/rust competition is pretty difficult atm. as d has a 
bunch of newbie hazards like betterC ("wow, this hello world is 
much faster! ... I can't use non-template functions from the 
standard library?") and ranges ("how do I get an array out of a 
MapResult?"), while Rust's relative noisiness as a language is 
balanced by the compiler's willingness to nearly write the noise 
for you with its error messages. Rust is mainly a lot readier in 
documentation to *explain* its WTFs, vs. d where something just 
seems odd (uncharitably: broken and misguided) for months until 
you run across a Steven Schveighoffer post about it.

But if you can get past the newbie experience, man, just look at 
the code.
Oct 23 2021
parent reply ag0aep6g <anonymous example.com> writes:
On 23.10.21 09:53, jfondren wrote:

 bool encryptsTo(const(char)* key, const(char)* salt, const(char)* hash) 
  trusted {
      import std.string : fromStringz;
 
      return hash.fromStringz == crypt(key, salt).fromStringz;
 }


That function can't be  trusted. "Any function that traverses a C string 
passed as an argument can only be  system."

https://dlang.org/spec/function.html#safe-interfaces
Oct 23 2021
next sibling parent jfondren <julian.fondren gmail.com> writes:
On Saturday, 23 October 2021 at 11:36:58 UTC, ag0aep6g wrote:

 On 23.10.21 09:53, jfondren wrote:

 bool encryptsTo(const(char)* key, const(char)* salt, 
 const(char)* hash)  trusted {
      import std.string : fromStringz;
 
      return hash.fromStringz == crypt(key, salt).fromStringz;
 }


 That function can't be  trusted. "Any function that traverses a 
 C string passed as an argument can only be  system."

 https://dlang.org/spec/function.html#safe-interfaces


Fair enough. The extra types of the Rust version are one solution 
to that if a  trusted interface is still wanted. But since in d 
this function is so trivial, what I actually did was inline it in 
a safer function that only accepted a string.
Oct 23 2021
prev sibling next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Saturday, 23 October 2021 at 11:36:58 UTC, ag0aep6g wrote:

 On 23.10.21 09:53, jfondren wrote:

 bool encryptsTo(const(char)* key, const(char)* salt, 
 const(char)* hash)  trusted {
      import std.string : fromStringz;
 
      return hash.fromStringz == crypt(key, salt).fromStringz;
 }


 That function can't be  trusted. "Any function that traverses a 
 C string passed as an argument can only be  system."

 https://dlang.org/spec/function.html#safe-interfaces


I think that should be: "Any function that traverses a C string 
_not verified to be null terminated_ can only be system".

If that check is done in the D wrapper, the function can be 
correctly trusted.
Oct 23 2021
parent reply ag0aep6g <anonymous example.com> writes:
On 23.10.21 14:01, Paolo Invernizzi wrote:

 On Saturday, 23 October 2021 at 11:36:58 UTC, ag0aep6g wrote:


[...]

 That function can't be  trusted. "Any function that traverses a C 
 string passed as an argument can only be  system."

 https://dlang.org/spec/function.html#safe-interfaces


 
 I think that should be: "Any function that traverses a C string _not 
 verified to be null terminated_ can only be system".
 
 If that check is done in the D wrapper, the function can be correctly 
 trusted.


You cannot verify that a `char*` is properly terminated. You have to 
change the parameter type. And when you do that, the caller is not 
passing a C string as an argument anymore.
Oct 23 2021
parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Saturday, 23 October 2021 at 12:11:53 UTC, ag0aep6g wrote:

 On 23.10.21 14:01, Paolo Invernizzi wrote:

 On Saturday, 23 October 2021 at 11:36:58 UTC, ag0aep6g wrote:


 [...]

 That function can't be  trusted. "Any function that traverses 
 a C string passed as an argument can only be  system."

 https://dlang.org/spec/function.html#safe-interfaces


 
 I think that should be: "Any function that traverses a C 
 string _not verified to be null terminated_ can only be 
 system".
 
 If that check is done in the D wrapper, the function can be 
 correctly trusted.


 You cannot verify that a `char*` is properly terminated. You 
 have to change the parameter type. And when you do that, the 
 caller is not passing a C string as an argument anymore.


You are right, of course.

It's the caller that needs to assure that the char* was really 
pointing to a null terminated string, so the caller could be 
trusted, and the crypt function should be kept system.
Oct 23 2021
prev sibling parent reply russhy <russhy gmail.com> writes:
Rust has many problems

- ultra slow to compile
- ugly syntax
- sect like community
- NPM like dependency hell, add one dependency, downloads 
9488694864 other dependencies 90% of them are unmaintained anymore
- annoying compiler
- unflexible language
Oct 23 2021
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 23 October 2021 at 15:26:29 UTC, russhy wrote:

 Rust has many problems

 - ultra slow to compile
 - ugly syntax
 - sect like community
 - NPM like dependency hell, add one dependency, downloads 
 9488694864 other dependencies 90% of them are unmaintained 
 anymore
 - annoying compiler
 - unflexible language


Rust is suffering

https://youtu.be/6x5BNcHyiiI
Oct 23 2021
prev sibling next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 23 October 2021 at 04:25:21 UTC, Dr Machine Code 
wrote:

 Just would like to know you all opinions


Mainly because you're so unproductive with Rust. It takes so many 
more keystrokes and thinking to even get anywhere. And for what 
benefit? A marginally more safe code base? 🤔

I've written safety critical code for years. Rust isn't even 
proven in use yet.

Take a quick look at this:
https://www.cvedetails.com/vulnerability-list.php?vendor_id=19029&product_id=48677&version_id=0&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&month=0&cweid=0&order=1&trc=19&sha=95e4d3703da65f4f319b5bfa6167ff26c6a83c13

And this:
https://github.com/rust-lang/rust/issues


Shouldn't those list be like... Shorter? 🤔

D has a balance of productivity and safety. We can improve D and 
get a nice language. But we need more people and/or focus to do 
that.

That's my opinion
Oct 23 2021
parent reply =?ISO-8859-1?Q?Lu=EDs?= Ferreira <contact lsferreira.net> writes:
On Sat, 2021-10-23 at 08:29 +0000, Imperatorn via Digitalmars-d wrote:

 On Saturday, 23 October 2021 at 04:25:21 UTC, Dr Machine Code=20
 wrote:

 Just would like to know you all opinions


=20
 Mainly because you're so unproductive with Rust. It takes so many=20
 more keystrokes and thinking to even get anywhere. And for what=20
 benefit? A marginally more safe code base? =F0=9F=A4=94
=20
 I've written safety critical code for years. Rust isn't even=20
 proven in use yet.
=20
 Take a quick look at this:
 https://www.cvedetails.com/vulnerability-list.php?vendor_id=3D19029&produ=


ct_id=3D48677&version_id=3D0&page=3D1&hasexp=3D0&opdos=3D0&opec=3D0&opov=3D=
0&opcsrf=3D0&opgpriv=3D0&opsqli=3D0&opxss=3D0&opdirt=3D0&opmemc=3D0&ophttpr=
s=3D0&opbyp=3D0&opfileinc=3D0&opginf=3D0&cvssscoremin=3D0&cvssscoremax=3D0&=
year=3D0&month=3D0&cweid=3D0&order=3D1&trc=3D19&sha=3D95e4d3703da65f4f319b5=
bfa6167ff26c6a83c13

=20


We should definitly setup heuristic based fuzzing tho. I guess this is
not a good realistic metric for our side because AFAIK we are not being
extensively fuzzing either the standard library or the reference
compiler implementation.


 And this:
 https://github.com/rust-lang/rust/issues
=20


The scale of the issue list is not so straightforward to measure. There
is definitly more activity on Github than on our Bugzilla.


=20
 Shouldn't those list be like... Shorter? =F0=9F=A4=94
=20
 D has a balance of productivity and safety. We can improve D and=20
 get a nice language. But we need more people and/or focus to do=20
 that.
=20
 That's my opinion


I totally agree. Productivity, readability and safety are well balanced
for what D offers.


--=20
Sincerely,
Lu=C3=ADs Ferreira   lsferreira.net
Oct 23 2021
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 23 October 2021 at 15:31:09 UTC, Luís Ferreira wrote:

 On Sat, 2021-10-23 at 08:29 +0000, Imperatorn via Digitalmars-d 
 wrote:

 [...]


 We should definitly setup heuristic based fuzzing tho. I guess 
 this is not a good realistic metric for our side because AFAIK 
 we are not being extensively fuzzing either the standard 
 library or the reference compiler implementation.


 [...]


 The scale of the issue list is not so straightforward to 
 measure. There is definitly more activity on Github than on our 
 Bugzilla.


 [...]


 I totally agree. Productivity, readability and safety are well 
 balanced for what D offers.


Good point about fuzzing
Oct 23 2021
parent =?ISO-8859-1?Q?Lu=EDs?= Ferreira <contact lsferreira.net> writes:
On Sat, 2021-10-23 at 20:09 +0000, Imperatorn via Digitalmars-d wrote:

 On Saturday, 23 October 2021 at 15:31:09 UTC, Lu=C3=ADs Ferreira wrote:

 On Sat, 2021-10-23 at 08:29 +0000, Imperatorn via Digitalmars-d=20
 wrote:

 [...]


=20
 We should definitly setup heuristic based fuzzing tho. I guess=20
 this is not a good realistic metric for our side because AFAIK=20
 we are not being extensively fuzzing either the standard=20
 library or the reference compiler implementation.
=20

 [...]


=20
 The scale of the issue list is not so straightforward to=20
 measure. There is definitly more activity on Github than on our=20
 Bugzilla.
=20

 [...]


=20
 I totally agree. Productivity, readability and safety are well=20
 balanced for what D offers.


=20
 Good point about fuzzing


I will add that to my TODO list :)

--=20
Sincerely,
Lu=C3=ADs Ferreira   lsferreira.net
Oct 23 2021
prev sibling next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Saturday, 23 October 2021 at 04:25:21 UTC, Dr Machine Code 
wrote:

 Just would like to know you all opinions


D has GC which is a proven success in the real world in getting 
stuff done.
Oct 23 2021
parent bachmeier <no spam.net> writes:
On Saturday, 23 October 2021 at 11:17:10 UTC, Adam D Ruppe wrote:

 On Saturday, 23 October 2021 at 04:25:21 UTC, Dr Machine Code 
 wrote:

 Just would like to know you all opinions


 D has GC which is a proven success in the real world in getting 
 stuff done.


I wouldn't use D if it didn't have a GC. It all depends on what 
you're doing, and for me, Rust brings nothing useful to the table.
Oct 26 2021
prev sibling next sibling parent reply SealabJaster <sealabjaster gmail.com> writes:
On Saturday, 23 October 2021 at 04:25:21 UTC, Dr Machine Code 
wrote:

 Just would like to know you all opinions


Never had a reason to use it.

The syntax looks like a language designer's wet dream.

I just don't see the point of using it for anything above systems 
programming, since a GC gives similar memory guarantees while 
being much easier to work with.

Also, it's proggit's beloved darling which clearly means it's a 
hipster language... /s ;3
Oct 23 2021
parent reply Kagamin <spam here.lot> writes:
On Saturday, 23 October 2021 at 11:24:42 UTC, SealabJaster wrote:

 I just don't see the point of using it for anything above 
 systems programming, since a GC gives similar memory guarantees 
 while being much easier to work with.


I do system programming with D. Ironically, system programming 
has trivial memory management, so rust doesn't really have much 
to show there, in fact it's bloated business applications like a 
browser where you might need a complex memory management system.
Oct 25 2021
parent reply user1234 <user1234 12.de> writes:
On Monday, 25 October 2021 at 08:14:36 UTC, Kagamin wrote:

 On Saturday, 23 October 2021 at 11:24:42 UTC, SealabJaster 
 wrote:

 I just don't see the point of using it for anything above 
 systems programming, since a GC gives similar memory 
 guarantees while being much easier to work with.


 I do system programming with D. Ironically, system programming 
 has trivial memory management, so rust doesn't really have much 
 to show there, in fact it's bloated business applications like 
 a browser where you might need a complex memory management 
 system.


mmh what about the big headlines everywhere when there was that 
thing made in rust for the linux kernel.
Oct 25 2021
parent reply Kagamin <spam here.lot> writes:
On Monday, 25 October 2021 at 09:26:16 UTC, user1234 wrote:

 I do system programming with D. Ironically, system programming 
 has trivial memory management, so rust doesn't really have 
 much to show there, in fact it's bloated business applications 
 like a browser where you might need a complex memory 
 management system.


 mmh what about the big headlines everywhere when there was that 
 thing made in rust for the linux kernel.


AFAIK rust has bound checking, which is nice to have in system 
programming. It can be done in C too, but for some reason they 
chose to introduce a new language than change the C tradition. 
Granted, when bound checking is built into the language, it 
becomes more useful.
Oct 25 2021
parent reply user1234 <user1234 12.de> writes:
On Monday, 25 October 2021 at 09:35:52 UTC, Kagamin wrote:

 On Monday, 25 October 2021 at 09:26:16 UTC, user1234 wrote:

 I do system programming with D. Ironically, system 
 programming has trivial memory management, so rust doesn't 
 really have much to show there, in fact it's bloated business 
 applications like a browser where you might need a complex 
 memory management system.


 mmh what about the big headlines everywhere when there was 
 that thing made in rust for the linux kernel.


 AFAIK rust has bound checking, which is nice to have in system 
 programming. It can be done in C too, but for some reason they 
 chose to introduce a new language than change the C tradition. 
 Granted, when bound checking is built into the language, it 
 becomes more useful.


it was only about that ? so _"space safety"_ ?
Oct 25 2021
parent Kagamin <spam here.lot> writes:
On Monday, 25 October 2021 at 09:51:56 UTC, user1234 wrote:

 it was only about that ? so _"space safety"_ ?


I suppose it gets lifetimes correctly too.
Oct 25 2021
prev sibling next sibling parent Ben Jones <fake fake.fake> writes:
On Saturday, 23 October 2021 at 04:25:21 UTC, Dr Machine Code 
wrote:

 Just would like to know you all opinions


I think I tried rust before I knew about D, but a the time, I 
wanted to define a mathematical vector type and couldn't do what 
I wanted because rust didn't have(but I think gained recently?) 
non type template parameters.  In D (and C++ which I was using at 
the time) it's easy:

`struct(size_t dim) Vec{  double[dim] data; ... }`

I did play around with rust for a bit anyway but found it too 
unfamiliar coming from C++, and then I found out about D
Oct 23 2021
prev sibling next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Saturday, 23 October 2021 at 04:25:21 UTC, Dr Machine Code 
wrote:

 Just would like to know you all opinions


https://www.youtube.com/watch?v=75Ju0eM5T2c
Oct 23 2021
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 24 October 2021 at 01:57:21 UTC, Guillaume Piolat 
wrote:

 On Saturday, 23 October 2021 at 04:25:21 UTC, Dr Machine Code 
 wrote:

 Just would like to know you all opinions


 https://www.youtube.com/watch?v=75Ju0eM5T2c


Word
Oct 24 2021
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 23 October 2021 at 04:25:21 UTC, Dr Machine Code 
wrote:

 Just would like to know you all opinions


Why did you pick Rust specifically?

I am not using either for anything that matters. Mostly because I 
haven't found a case where D or Rust provided a foundation to 
build on that others don't. Rust, as a language, is trying to 
solve a problem I usually don't have, at a significant modeling 
cost.  Their approach might be worthwhile for larger executables 
built by larger teams.

Rust seems to have one major feature (tracking resource use). D 
is trying to provide all features and not really excelling at any 
particular domain. What prevents D from pursuing a multi paradigm 
approach is that it lacks a modular compiler implementation, so 
it has hit an evolutionary wall.

Rust has more of a cultural wall that will keep it true to its 
main focus, but that also prevents evolution. Rust and C++ 
attract programmers that accept complexity, as such, they are 
likely to become more complex over time. So programmers that feel 
those languages are difficult to learn are unlikely to be happy 
with where they are heading. Some might argue that D has 
comparable cultural challenges.

Right now it is difficult to say where D is heading. Seems to me 
that a restructuring of the compiler is needed, but there does 
not seem to be plan for it, so it is ulikely to happen.
Oct 24 2021
prev sibling next sibling parent reply Antonio <antonio abrevia.net> writes:
On Saturday, 23 October 2021 at 04:25:21 UTC, Dr Machine Code 
wrote:

 Just would like to know you all opinions


Try to write this in Rust

```d
T[] sorted(T)(T[] xs) {
   return  xs.length == 0 ? [] :
     xs[1..$].filter!(x=> x < xs[0]).array.sorted ~
     xs[0..1] ~
     xs[1..$].filter!(x=> x >= xs[0]).array.sorted;

void main() {
   [1,6,2,3,1,9,3].sorted.writeln;
}
```

D is not Scala... but it is more expressive than Rust (Thanks to 
UFCS, Ranges & GC).
Oct 24 2021
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 10/24/21 1:57 PM, Antonio wrote:

 On Saturday, 23 October 2021 at 04:25:21 UTC, Dr Machine Code wrote:

 Just would like to know you all opinions


 Try to write this in Rust


Are you saying Rust makes it difficult to write inefficient algorithms? 
I have to learn more about Rust then. ;)


 ```d
 T[] sorted(T)(T[] xs) {
    return  xs.length == 0 ? [] :
      xs[1..$].filter!(x=> x < xs[0]).array.sorted ~
      xs[0..1] ~
      xs[1..$].filter!(x=> x >= xs[0]).array.sorted;

 void main() {
    [1,6,2,3,1,9,3].sorted.writeln;
 }
 ```


I am glad we can do that but the number of arrays allocated there is *I 
think* 4 per sorted() call. Ouch!

And picking the first element as the pivot is known to hurt worst-case 
performance horribly. (For example, passing already (or nearly) sorted 
data will be very bad there.)


 D is not Scala... but it is more expressive than Rust (Thanks to UFCS,
 Ranges & GC).


D is not Haskell either so let's at least pick a random pivot. ;)

Ali
"Who possibly missed a joke."
Oct 24 2021
parent reply Antonio <antonio abrevia.net> writes:
On Sunday, 24 October 2021 at 21:18:06 UTC, Ali Çehreli wrote:


 I am glad we can do that but the number of arrays allocated 
 there is *I think* 4 per sorted() call. Ouch!


 D is not Haskell either so let's at least pick a random pivot. 
 ;)

 Ali
 "Who possibly missed a joke."


Hi Ali,

This is only an example of expressiveness: no one in is right 
mind (I don't know if this is how it is said in english) will 
include this piece of code as a real sorting code.

But, and this is really interesting, the expression performs 
really well compared with other programming languages similar 
ones:  Python, Julia, Scala, Javascript, Crystal, Nim:  no one of 
them beats D.  https://github.com/ddcovery/expressive_sort

Javascript sorprised me a lot.  It is incredibly performant 
compared with Python, Julia, Scala... even Nim!!!:

I tried with Rust, but it was impossible to create an 
intelligible version.


May be an expression is useless but, at least, it is an 
expression :-).
Oct 24 2021
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 10/24/21 3:45 PM, Antonio wrote:


 no one in is right mind (I
 don't know if this is how it is said in english) will include this piece
 of code as a real sorting code.


Cool! Making sure that no unsuspecting novice will take it as real 
sorting code... :)

Ali
Oct 24 2021
parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Monday, 25 October 2021 at 00:33:21 UTC, Ali Çehreli wrote:

 On 10/24/21 3:45 PM, Antonio wrote:


 no one in is right mind (I
 don't know if this is how it is said in english) will include


 this piece

 of code as a real sorting code.


 Cool! Making sure that no unsuspecting novice will take it as 
 real sorting code... :)

 Ali


Someone here in the forum pointed out this video ...

Quick sort in a strong pure functional language, with in-place 
mutation automatically done by the optimiser: really amazing 
stuff!

https://youtu.be/vzfy4EKwG_Y?t=1668
Oct 25 2021
prev sibling next sibling parent JN <666total wp.pl> writes:
On Saturday, 23 October 2021 at 04:25:21 UTC, Dr Machine Code 
wrote:

 Just would like to know you all opinions


I started with D before Rust existed. Also, I can't get around 
Rust syntax, I don't find it fun to look at. And in the projects 
I like to do, memory safety is not of utmost importance and the 
borrow checker gets in my way more than I'd like it to.

What I like about Rust however is how quickly their ecosystem is 
growing and how they have a good focus on features. Good focus on 
features means they have very good foundations in de-facto 
official things like HTTP libraries or serialization.
Oct 24 2021
prev sibling next sibling parent bauss <jj_1337 live.dk> writes:
On Saturday, 23 October 2021 at 04:25:21 UTC, Dr Machine Code 
wrote:

 Just would like to know you all opinions


Rust wasn't really that popular or stable when I first discovered 
D and started using it.

By the time I discovered Rust, my D journey had already begun and 
I've yet to find a reason to discard D, even tho it's like a 
decade since I first began using it now.

I have used Rust however and I'm not against using it but I'm not 
going to replace D.

Rust is a tool, just like D is and each serves a different 
purpose.

I like D because I can quickly prototype an application, can't 
say the same for Rust.
Oct 25 2021
prev sibling next sibling parent reply harakim <harakim gmail.com> writes:
On Saturday, 23 October 2021 at 04:25:21 UTC, Dr Machine Code 
wrote:

 Just would like to know you all opinions


In 2006, I set out to learn as many programming languages as I 
could so I would always be able to pick the best one. I had a 
notebook and kept notes about each one. I think I got through 56 
languages before I realized D checked all my boxes and I just 
gave up.

I have been using D off and on since then. I am not an expert 
because I don't use it at work and I don't program as a hobby as 
much as I used to, but even still, I have never run into a 
problem I could not solve elegantly with the D language. That's a 
pretty good endorsement. When it comes to technology, I complain 
a lot! When I'm looking for a language for a side project, I 
always start with D.

I can't imagine Rust solves a problem that I have and if it did, 
it wouldn't solve any of my other problems better than D. The 
syntax reminds me of everything I don't like about C++, while the 
rules remind me of everything I didn't like about Scala.

As someone who has worked in multiple languages professionally 
and explored many languages personally, I believe D to be the 
all-around best programming language available. With a little 

and Java for productivity. With more specific tutorials and 
documentation, it could start making inroads professionally as 
well.
Oct 29 2021
next sibling parent zjh <fqbqrr 163.com> writes:
On Friday, 29 October 2021 at 07:19:18 UTC, harakim wrote:

 On Saturday, 23 October 2021 at 04:25:21 UTC, Dr Machine Code


Hopes D can get better and better.
Oct 29 2021
prev sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 29 October 2021 at 07:19:18 UTC, harakim wrote:

 On Saturday, 23 October 2021 at 04:25:21 UTC, Dr Machine Code 
 wrote:

 [...]


 In 2006, I set out to learn as many programming languages as I 
 could so I would always be able to pick the best one. I had a 
 notebook and kept notes about each one. I think I got through 
 56 languages before I realized D checked all my boxes and I 
 just gave up.

 [...]


That's exactly my journey. If D could just get a bit more tidy 
(reduce attributes etc) and improve the ecosystem, it would be 
perfect.
Oct 29 2021
parent harakim <harakim gmail.com> writes:
On Friday, 29 October 2021 at 10:57:51 UTC, Imperatorn wrote:

 On Friday, 29 October 2021 at 07:19:18 UTC, harakim wrote:

 On Saturday, 23 October 2021 at 04:25:21 UTC, Dr Machine Code 
 wrote:

 [...]


 In 2006, I set out to learn as many programming languages as I 
 could so I would always be able to pick the best one. I had a 
 notebook and kept notes about each one. I think I got through 
 56 languages before I realized D checked all my boxes and I 
 just gave up.

 [...]


 That's exactly my journey. If D could just get a bit more tidy 
 (reduce attributes etc) and improve the ecosystem, it would be 
 perfect.


That's my opinion too. I think it's time to iron out the kinks in 
the language and library and make something stable. Then build an 
ecosystem around it. I could get behind that!

On Friday, 29 October 2021 at 08:34:53 UTC, deadalnix wrote:

 On the other hand, you can present D code to a decent dev who 
 never used D and they'll be able to make sense of it.


I mostly agree, but I don't think that's true of templates.
Oct 29 2021
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
On Saturday, 23 October 2021 at 04:25:21 UTC, Dr Machine Code 
wrote:

 Just would like to know you all opinions


By far the most important reason is foreign syntax. This create a 
giant barrier for no good reason.

On the other hand, you can present D code to a decent dev who 
never used D and they'll be able to make sense of it.
Oct 29 2021
prev sibling parent IGotD- <nise nise.com> writes:
On Saturday, 23 October 2021 at 04:25:21 UTC, Dr Machine Code 
wrote:

 Just would like to know you all opinions


Programming rust as a high level language only using the 
primitives in the standard library, you probably will do find. 
Aesthetics is not one of the strong sides of Rust in my opinion 
though and when you compare codes in Rosetta you often find that 
the rust implementation is longer.

When you step outside the box, then the ugliness starts to show 
up.

I was investigating the intrusive collections in Rust.

https://github.com/Amanieu/intrusive-rs

One notable file, src/adapter.rs you will see a macro 
intrusive_adapter. The purpose of the macro is to expand an 
entire implementation of the algorithm. I guess the author has 
done this because the generic system in Rust is too limited than 
using standard generics. If you abuse this macro you can in 
practice create a new expanded implementation for every source 
file you use it in which can lead to longer compile times and 
code duplication. You'd hope that the compiler is smart enough to 
remove duplicates of the same type.

One thing you notice is that the macro almost unreadable. I don't 
often agree with Walter but not allowing macros in D I do agree 
with. Adding macros to D would risk making the readability 
unbearable.

With many other languages, implementing these algorithms are 
often done in a few 100 lines but the Rust implementation is 
huge. You also notice that general code isn't that readable 
either.

In these cases you'd think that an offsetof compiler statement in 
order to find the offset of a member variable in a struct would 
help. Problem is that Rust doesn't have any offsetof. Rust has 
been around of over 10 years and offsetof is one of the first 
things you'd implement but not in Rust. There are crates that 
implements this and there you also notice how the authors has 
implemented hacks to achieve this simple thing.


The more I use Rust and look under the hood, the more what the 
h... revelations I get. I can see how Rust might appeals to the 
C++ crowd who likes the over complicated parts in C++ and that 
way gives them hubris when they circumvent the limitations of 
Rust.
Dec 16 2021