On Friday, 27 May 2022 at 05:06:54 UTC, Walter Bright wrote:
> ...
> Rust is famous for forcing programmers to not just recode their programs, but redesign them from the ground up. How they managed to sell that is amazing.

Rust is designed for performance and safety, and people have confidence that the language design and compiler, actually accomplishes this.

You don't have to 'opt in'. Instead, you have to consciously opt out. This principle is really important for the future of programming lanaguages.

So in that sense it's not at all surprising that people would want to recode for performance and safety.

What is surprising, is that they're willing to do it in Rust (given it's syntax is so cognitively demanding).

But that's what happens when academics get involved in language design ;-)

Going from C, C++, C#, Java .. to D, is relatively painless.

This simply cannot be said, when going to Rust.

This is the lesson the designers of Rust should have taken from D.

Imagine how popular Rust would be now, if they had done that.

These forums would be pretty quiet indeed, if that had happened.

On Friday, 27 May 2022 at 12:27:00 UTC, forkit wrote:
> On Friday, 27 May 2022 at 05:06:54 UTC, Walter Bright wrote:
>> ...
>> Rust is famous for forcing programmers to not just recode their programs, but redesign them from the ground up. How they managed to sell that is amazing.
>
> Rust is designed for performance and safety, and people have confidence that the language design and compiler, actually accomplishes this.
>
> You don't have to 'opt in'. Instead, you have to consciously opt out. This principle is really important for the future of programming lanaguages.
>
> So in that sense it's not at all surprising that people would want to recode for performance and safety.
>
> What is surprising, is that they're willing to do it in Rust (given it's syntax is so cognitively demanding).
>
> But that's what happens when academics get involved in language design ;-)
>
> Going from C, C++, C#, Java .. to D, is relatively painless.
>
> This simply cannot be said, when going to Rust.
>
> This is the lesson the designers of Rust should have taken from D.
>
> Imagine how popular Rust would be now, if they had done that.
>
> These forums would be pretty quiet indeed, if that had happened.

One thing people here seem to miss is that Rust isn't just a memory safety thing anymore.

The memory safety is still a very big draw, yes obviously, but the language as a whole has a lot of goodies that draw people to it.

I know a handful of rust programmers, most of them don't really care about the memory safety primarily but rather memory safety *and* all the "functional" stuff it inherited from ML.

For example doing things like sum and product types as a library whether it be C++ or D just looks incredibly tired and banal compared to doing it properly and cohesively (pattern matching for example) in the language. This can be rectified in D, we just need to actually do it. Tuples have been on the cards for years.

On Friday, 27 May 2022 at 05:06:54 UTC, Walter Bright wrote:
>
> Rust is famous for forcing programmers to not just recode their programs, but redesign them from the ground up. How they managed to sell that is amazing.

I think it's because they don't focus on interop with other languages, especially other than C. It's "my way or the highway". And Rust provides many benefits over C/C++ making people willing to make the complete switch.

In comparison, D is trying to be a language that can partially replace and interact with existing C++ codebases, even adding language features to support such workflow.

Not arguing whether one behavior is better than the other, but it's easier to force programmers to redesign their programs if they don't have an easy transition path. If it's a hard transition path, might as well, do the redesigns at this point.

On Friday, 27 May 2022 at 09:43:02 UTC, Nick Treleaven wrote:
> On Thursday, 26 May 2022 at 22:54:22 UTC, deadalnix wrote:
>>
>> If immutable instead meant immutable in most places, you you can mutate it with this weird construct, then it is effectively useless as a language construct, because it restrict my expressiveness on one axis without granting me greater expressiveness on another.
>
> scope actually does allow that. Any local heap allocation only passed to scope parameters can be allocated on the stack instead of the heap.
>
> void f(scope T);
>
> T v = new T; // can be stack allocated
> f(v);

To finish my point, scope allows using `new` in @nogc functions. And it enables allocation optimizations, so scope can't just be for a static analyzer.

On 27.05.22 07:25, rikki cattermole wrote:
> 
> A question Timon came up with that I answered:
> 
> ```d
> int[][] func(int[] a, int[] b){
>      return [a,b];
> }
> ```
> 
> (for return value): ``// ownership: [first argument, second argument]``

(What I don't like about this is that it conflates ownership for different levels of indirection, the memory of the resulting array is actually GC-owned.)

On Friday, 27 May 2022 at 06:14:53 UTC, rikki cattermole wrote:
> I forgot to mention this in my other reply, when I talk about lifetimes I am not meaning about memory allocation/deallocation. That's a solved problem even if reference counting is not available on classes (we should do this but for other reasons).
>
> What I care about is escape analysis, to make sure say an owning container, does not have a member of it escape its lifetime. Which of course would be bad, due to the fact that the data structure can deallocate it.
>
> The problem I'm interested in here, is that the compiler guarantees that the order of destruction happens in the right order. This is something the GC does not do, but one that the compiler can and should be doing.
>

The reason you can't do RC on classes, at least safely, is BECAUSE there is no escape analysis.