On Friday, 21 October 2022 at 07:02:01 UTC, rassoc wrote:
> On 21/10/2022 05:36, Don Allen via Digitalmars-d wrote:
>> As I said in my original post, this kind of code is very common in Scheme.
>>
>
> Right, I walked that path before, even shiny R7RS, and I'm glad I went to speech therapy for my lisp.
>
>> where multiple closures refer to several of them and the closures are called in multiple places
>>
>
> National Spaghetti Day is coming up on January 4th. ;)

You should have gone to another therapist to correct your tendency to offer opinions about code you haven't seen.

>
> In all seriousness, though, I'm not here to invalidate your experiences with Rust. While I've been using D for quite a bit now, I get to experience some pretty uncomfortable cognitive dissonance doing so. I still love it, but D often times offers a slightly less performant and reliable way to tackle a certain set of hard problems. Even if I never get to experience Rust professionally, I'm still quite happy that it set a new baseline for safe languages to come and evolve to.

Since you've said something substantive, I'll comment. I actually agree with you that Rust has shown the world that inherently memory- and thread-safe languages are possible. Haskell did some of that before Rust did, but they didn't quite finish the job.

But I think there is an opportunity to create a memory-safe language with a GC that avoids many of the difficulties of Rust. And I think thread-safety should be an option, not a requirement, because there are applications that are inherently single-threaded. Those applications should not have to adhere to the rules that keep multi-threaded applications safe, as is the case in Rust, the only alternative being to sprinkle your code with "unsafe" blocks, or use thread_local!, which works, but makes the code similarly messy.

On Friday, 21 October 2022 at 14:04:25 UTC, Don Allen wrote:
>
> But I think there is an opportunity to create a memory-safe language with a GC that avoids many of the difficulties of Rust. And I think thread-safety should be an option, not a requirement, because there are applications that are inherently single-threaded. Those applications should not have to adhere to the rules that keep multi-threaded applications safe, as is the case in Rust, the only alternative being to sprinkle your code with "unsafe" blocks, or use thread_local!, which works, but makes the code similarly messy.

It already exists and it is called Swift. A few engineers from the Rust team helped engineer Swift. The syntax similarities between Swift and Rust are obvious. In Swift they added a lot of lowering in order to hide the more explicit Rust syntax. If you see the results after the lowering then the Rust syntax shines through even more.

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 isn't safe as "nothing can go wrong" but safe enough for me. For embedded systems, Swift isn't an ideal candidate as it relies on its own foundation library, objective-C runtime and C++ standard library. Though there has been people who has successfully ported Swift to OS-less systems.