On 2020-03-26 20:30, Steven Schveighoffer wrote:

> Don't  pick Swift though, they change stuff all the time, it probably is going to die soon, I doubt anyone will put up with that.

In Swift 5, Apple stabilized the ABI. With every new version of Xcode, when you open your old project you get the option to automatically upgrade the code to the latest version. That's not something we're offering.

-- 
/Jacob Carlborg

On Friday, 27 March 2020 at 09:26:35 UTC, Walter Bright wrote:
> On 3/26/2020 10:00 AM, jmh530 wrote:
>> I was talking about a hypothetical python person thinking about learning D, not about me personally.
>
> Consider how the Rust folk have been successful at getting people to entirely re-engineer their programs and data structures and learn an entirely different language to get a small increment in memory safety.
>
> Rust's marketing department is very good.

It's not marketing. They created a solution to a problem no one else has been able to. Trying the language, and it solving your problems and then continuing to use the language afterwards isn't marketing. It is a completely refined package all the way down to it's package manager.

It's not just memory safety. Have you used Rust? How you written Rust? Have you had to deal with a new version of Rust that breaks all your code? Have you used cargo? Have you used a cargo package that uses a different version of Rust that you use and it just works TM?

Rust is memory safe, but to attribute its success entirely on that is moronic. A GC is memory safe, do you think Rust would have been as successful with a GC? Rust provides more guarantees than simply being memory safe. Something a GC doesn't provide.

On Friday, 27 March 2020 at 04:20:47 UTC, Mathias Lang wrote:
> And since exceptional claims calls for exceptional proof, I wanted to check whether or not your libraries would be any different. It took me less than 5 minutes to find this: https://github.com/atilaneves/unit-threaded/issues/176

That's a good example of why @trusted is broken.

And guess what the "proper" solution is?

https://github.com/atilaneves/unit-threaded/commit/b7457d5d317a2eb1f2bbb2ece9a80f3b26b71600#diff-1e0b7d3d93f30ae83fa8d01f92dfd5aaR59

Unsafe blocks like from Rust (aka hacky @trusted lambda in D). The whole way @trusted works itself creates buggy unsafe code. You shouldn't be calling unsafe code from safe code, unless it is explicitly marked as unsafe.

Here in this case, the "proper" way to solve this problem is the harder uglier way to solve it. Is that the design philosophy that should be striven toward? I remember from the other thread Walter saying that syntax is ugly on purpose so as to be avoided. Funnily a lot of the times it's the proper way to solve the problem yet the syntax is still ugly because someone doesn't seem to understand why.

On Saturday, 28 March 2020 at 13:53:28 UTC, Arine wrote:
> On Friday, 27 March 2020 at 09:26:35 UTC, Walter Bright wrote:
>> On 3/26/2020 10:00 AM, jmh530 wrote:
>>> I was talking about a hypothetical python person thinking about learning D, not about me personally.
>>
>> Consider how the Rust folk have been successful at getting people to entirely re-engineer their programs and data structures and learn an entirely different language to get a small increment in memory safety.
>>
>> Rust's marketing department is very good.
>
> It's not marketing. They created a solution to a problem no one else has been able to.

I think they created a solution to a problem 99.9% of programmers don't have, which is "how to be memory safe without using a tracing GC". The reason it's marketing genius is it'll convince people who really really think "GCs are slow" without ever having run a profiler. Genius, I tells ya. Genius.

On Saturday, 28 March 2020 at 14:18:46 UTC, Atila Neves wrote:
> On Saturday, 28 March 2020 at 13:53:28 UTC, Arine wrote:
>> On Friday, 27 March 2020 at 09:26:35 UTC, Walter Bright wrote:
>>> On 3/26/2020 10:00 AM, jmh530 wrote:
>>>> I was talking about a hypothetical python person thinking about learning D, not about me personally.
>>>
>>> Consider how the Rust folk have been successful at getting people to entirely re-engineer their programs and data structures and learn an entirely different language to get a small increment in memory safety.
>>>
>>> Rust's marketing department is very good.
>>
>> It's not marketing. They created a solution to a problem no one else has been able to.
>
> I think they created a solution to a problem 99.9% of programmers don't have, which is "how to be memory safe without using a tracing GC". The reason it's marketing genius is it'll convince people who really really think "GCs are slow" without ever having run a profiler. Genius, I tells ya. Genius.

Like I said, Rust provides more than only a safety guarantee. Something that a GC can't provide (on its own at least).

I see a lot of projects that are using C converting to Rust. That includes projects that Apple, Microsoft, etc is working on. D is advertised as a replacement for C and C++, but it really isn't. It's designed to be easily convertible from those languages but obviously that hasn't worked out, you don't get a benefit by keeping most of your same code and then trying to shoehorn in different design principles. People don't use C and C++ just cause they "think" GCs are slow. They use it because GCs don't fit their requirements. Otherwise there's a plethora of better languages that are built around solely using a GC, that have more options in terms of a better suited GC. I see Rust being used exactly where it makes sense to see it being used. As a systems programming language where C would otherwise have been used. I've also seen it used to replace GC languages like Go on servers as well:

Anyways, here's a good example of where GC failed to meet their requirements, and Rust solved their problem as it doesn't use a GC.

https://blog.discordapp.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f

> On Monday, 30 March 2020 at 15:49:55 UTC, Arine wrote:
> People don't use C and C++ just cause they "think" GCs are slow.

True. They use those languages because they were already using those languages.

> They use it because GCs don't fit their requirements.

Most of the time, because they *think* GCs don't fit their requirements.

On Monday, 30 March 2020 at 15:49:55 UTC, Arine wrote:
> Anyways, here's a good example of where GC failed to meet their requirements,

Cases like this happen, but more often than not it's just, like, their opinion man.

On 30.03.20 18:50, Atila Neves wrote:
> 
> 
> On Monday, 30 March 2020 at 15:49:55 UTC, Arine wrote:
>> Anyways, here's a good example of where GC failed to meet their requirements,
> 
> Cases like this happen, but more often than not it's just, like, their opinion man.

They were moving from _Go_ to Rust. The GC-related issue they were having seems as good an excuse as any to justify the move. :)

On 3/30/20 1:24 PM, Timon Gehr wrote:
> On 30.03.20 18:50, Atila Neves wrote:
>>
>>
>> On Monday, 30 March 2020 at 15:49:55 UTC, Arine wrote:
>>> Anyways, here's a good example of where GC failed to meet their requirements,
>>
>> Cases like this happen, but more often than not it's just, like, their opinion man.
> 
> They were moving from _Go_ to Rust. The GC-related issue they were having seems as good an excuse as any to justify the move. :)

Ya, I have not used go, but I would suspect that some of these issues have mechanisms to mitigate GC problems in D.

Sociomantic avoids unpredictable GC cycles, but doesn't disable it (they still allow collections periodically IIRC). And they are built to be as fast as possible.

That doesn't mean D would beat Rust in a competition on who makes the best discord software. It really depends on a lot of factors, and I don't think generalizing Go and D to be the same because they both have a GC is fair or accurate.

-Steve

On Monday, 30 March 2020 at 15:49:55 UTC, Arine wrote:
> I've also seen it used to replace GC languages like Go on servers as well:
>
> Anyways, here's a good example of where GC failed to meet their requirements, and Rust solved their problem as it doesn't use a GC.
>
> https://blog.discordapp.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f

Let's be honest, *anything* would be better than Go, for a reasonable value of "anything". ;-)

On Monday, 30 March 2020 at 17:24:44 UTC, Timon Gehr wrote:
> On 30.03.20 18:50, Atila Neves wrote:
>> 
>> 
>> On Monday, 30 March 2020 at 15:49:55 UTC, Arine wrote:
>>> Anyways, here's a good example of where GC failed to meet their requirements,
>> 
>> Cases like this happen, but more often than not it's just, like, their opinion man.
>
> They were moving from _Go_ to Rust. The GC-related issue they were having seems as good an excuse as any to justify the move. :)

Reading the comments, lot of them are related to the fact that they switched in May 2019 from go 1.9 to rust _nightly_, while, for example Go 1.12 was released in Feb 2019.

They updated the notes saying that they tested 1.10 without noticing any improvements ... folks asks for comparison against 1.13 at least ...

Well, knowing how much work was done in improving the GC performance in go in the latest releases, I think Timon is right!