A D vs. Rust example (page 5)

On Friday, 21 October 2022 at 14:46:16 UTC, IGotD- wrote:

Swift added reference counting as GC (much because of objective-C) and the result is that the language is quite usable, much more easy to use than Rust. You will not end up with senseless life time compiler error as in Rust.

Swift is probably the best option for writing applications for Apple products, but I don't feel that it will be accepted for portable system level programming, no matter how it changes in the future.

Even if it became a Rust/C++ replica it would still be perceived as being beholden to a singular entity. I can see why the Carbon docs put so much emphasis on no entity having more than 50% influence. "Backed by Google" is a selling point, but "Owned by Google" is a liability.

As more languages appear I think having a more cooperative collaborative approach to design will be something people look for.

Selecting a specific language is a big investment as languages get more complex (even TypeScript has grown to become rather complex). Developers don't want a single "political group" to block a design extension that matters to 20% of the users.

Since languages copy features from each other they are sometimes not all that different in ordinary programming, but cultures can be very different still. So that dimension will perhaps be more and more important in the next few decades.

On Thursday, 20 October 2022 at 15:33:06 UTC, rikki cattermole wrote: > On 21/10/2022 4:25 AM, Don Allen wrote: >> Where I do think D would do well by emulating Rust is in the area of helpful compiler warnings: noting unused variables, constants and imported symbols, pointing out unnecessary parentheses, etc. > > IDE's such as IntelliJ IDEA (D's plugin) call Dscanner all the time to verify code and get warnings. > > So in practice this shouldn't be an issue. In my experience, it is an issue. dub lint does not warn about unused imports or unused constants, for example. I also don't use an IDE, unless you consider nvim an IDE. And I don't use dub to build my code (I'm open to it, but I've found the documentation thoroughly inadequate), so using its lint to check my code is more than a bit of a pain. So for me, the D existing tools to statically evaluate code in a manner similar to the Rust compiler are just not where I would like them to be.

On 22/10/2022 9:11 AM, Don Allen wrote: > And I don't use dub to build my code (I'm open to it, but I've found the documentation thoroughly inadequate), so using its lint to check my code is more than a bit of a pain. DScanner of course is separate from dub, so that isn't an issue if you do something different. > So for me, the D existing tools to statically evaluate code in a manner similar to the Rust compiler are just not where I would like them to be. DScanner is currently being rewritten to use dmd-fe, so these semantically required checks will be implementable (as long as all files required to compile a module is provided).

On 10/21/2022 3:19 AM, matheus wrote: > For example, I wrote this a while ago: "The problem that took him 5 years to fix in C++, I solved in a minute with D". > > https://forum.dlang.org/thread/oyfejgtjsupbdgckfdjz@forum.dlang.org I repeat my request to make it a HackerNews or Reddit article!

October 21, 2022

Re: A D vs. Rust example

Posted by Steven Schveighoffer
in reply to Don Allen

Permalink

Steven Schveighoffer

Posted in reply to Don Allen

Permalink

On 10/20/22 10:46 PM, Don Allen wrote:

I've written about 10,000 lines of Rust over several years, revised many times in consultation with a couple of people in the Rust community who were particularly helpful. I've been writing code professionally and otherwise for longer than most of you, since I'm now 80 (first line of code in 1960 -- IBM 1620 assembly language). I understand Rust pretty well at this point, so I don't think the "newcomer" description applies.

OK, apologies.

The language is more difficult to master than other I've used (a lot). And if you insist on never writing "unsafe", there are things that are simply impossible to do that are routine in more traditional languages.

I agree that if you have to use escapes in your safe code to write useful programs, the utility of the memory safety goes way down. This is why I'm very keen to see D @safe be much easier to isolate.

No. Nested functions don't see their enclosing environment in Rust.

Hm... closures in D typically mean an allocation. So maybe my terminology is messed up.

> >

Many people discount D because their attempts to make it do the things in the way they are used to result in horrible performance, or weird problems.

I did run into that in D, mostly in the area of needing to be aware of preventing the GC from snatching strings I'd passed to C code (sqlite) (you and I shared that adventure last year). This came about in my case because I was porting C code to D, which is mostly very easy, but I missed this gotcha.

Yes, I remember. I'm still not satisfied with the lack of ability to ensure something is stored on the stack.

-Steve

On 10/20/2022 7:46 PM, Don Allen wrote: > I've written about 10,000 lines of Rust over several years, revised many times in consultation with a couple of people in the Rust community who were particularly helpful. I've been writing code professionally and otherwise for longer than most of you, since I'm now 80 (first line of code in 1960 -- IBM 1620 assembly language). I understand Rust pretty well at this point, so I don't think the "newcomer" description applies. I'm glad you wrote this. I thought I was the oldest D programmer! I'm very pleased there are more of us using D! I hope I'm as sharp as you are when I'm 80.

On 10/21/2022 5:52 PM, Steven Schveighoffer wrote: > Hm... closures in D typically mean an allocation. So maybe my terminology is messed up. The original closure implementation in D did not allocate, and simply errored if an allocation was necessary. Sometimes I wonder if it would have been better to not have generalized it.

On 10/21/2022 6:44 AM, Don Allen wrote: > Which is contrary to the purpose of using closures -- to capture free variables in the lexical environment, rather than having to pass them as arguments. What you have done above could (and should) be re-written with ordinary functions. The way dip1000 works with closures is to treat the uplevel variables as if they are passed by ref to the nested function. Which is of course how they are implemented.

fn main() { let mut foo = 5; let mut bar = || { foo = 17; }; let mut baz = || { foo = 42; }; bar(); println!("{}", &mut foo); baz(); println!("{}", &mut foo); }

fn main() { struct State { foo: i32 } impl State { fn bar(&mut self) { self.foo = 17; } fn baz(&mut self) { self.foo = 42; } } let mut state = State { foo: 0 }; state.bar(); println!("{}", state.foo); state.baz(); println!("{}", state.foo); }

Forums