On 20.09.19 03:41, Timon Gehr wrote:
> in it's usage patterns

its. its usage patterns...

On Thursday, 19 September 2019 at 20:34:47 UTC, Walter Bright wrote:
> It's like how the first intercontinental railroad was built. It was all quick-and-dirty, slap dash, unsafe, and ramshackle. It was also built entirely with muscle. But once it was done, and trains could be run on it, suddenly it was incredibly useful, money was coming in, etc., and piece by piece the crappy construction was fixed. It could not have been built otherwise.

Like auto-decoding? A compiler isn't a railroad. You can build your implementation without forcing itself into stable/master. If you need to build it as quickyl and unsafely as you can, one rail at a time and plug the holes as you find them. Fine, that sounds extremely *unstable*. You can do that without integrating it into stable/master.

On 9/19/2019 6:17 PM, Timon Gehr wrote:
> Anyway, I have actually done this but you just ignored the explanation and went back to claiming that my suggestions do not meet this requirement.

If you can link to your proposal, polished or not, that would be helpful.

On 20.09.19 05:10, Walter Bright wrote:
> On 9/19/2019 6:17 PM, Timon Gehr wrote:
>> Anyway, I have actually done this but you just ignored the explanation and went back to claiming that my suggestions do not meet this requirement.
> 
> If you can link to your proposal, polished or not, that would be helpful.

It was in private emails. I'll try to create a self-contained write-up for general consumption next week, I have a paper deadline on Wednesday.

On Thursday, 19 September 2019 at 10:17:43 UTC, Walter Bright wrote:
> Note that Rust has user base of 50,000. There's pretty strong evidence that it works. I haven't seen any articles or ripostes showing that it doesn't work.

Sorry to say that but Rust community is full of extremists. The promises of the Rust language has to taken with grain of salt. I've seen many negative opinions about the actual Rust usage.

Let me list just 3 points of the Rust language issues on software development(in general):

1. No garbage collector - this means no fully automatic memory management (cycles).
2. Despite the Rust funboys' claims a compiler won't fix all memory bugs at compile time, just to name array accesses, but that is not all.
3. No GUI library because of the language limitations.

Of course any memory safety checks at compile time are nice but I would be careful with paying too much for it.

Because of its design Rust seems to be less productive than other popular languages .

Cheers,
Piotrek

On 9/20/2019 5:17 AM, Timon Gehr wrote:
> It was in private emails. I'll try to create a self-contained write-up for general consumption next week, I have a paper deadline on Wednesday.

Thank you, that'll be good! Post it here when ready.

On 9/20/2019 9:46 AM, Piotrek wrote:
> Sorry to say that but Rust community is full of extremists. The promises of the Rust language has to taken with grain of salt. I've seen many negative opinions about the actual Rust usage.
> 
> Let me list just 3 points of the Rust language issues on software development(in general):
> 
> 1. No garbage collector - this means no fully automatic memory management (cycles).
> 2. Despite the Rust funboys' claims a compiler won't fix all memory bugs at compile time, just to name array accesses, but that is not all.
> 3. No GUI library because of the language limitations.
> 
> Of course any memory safety checks at compile time are nice but I would be careful with paying too much for it.
> 
> Because of its design Rust seems to be less productive than other popular languages .

I agree that Rust appears to be significantly harder to write code in. I do not know why GUI libraries appear to be a big problem for Rust.

But consider also that functional programming has its problems as well, both in terms of expressivity and performance.

D supports FP as a useful paradigm, not as a religion. It allows one to easily mix&match FP with imperative code.

I figure we can do the same for ownership/borrowing, that's why it has a separate function attribute (@live) for it.

On Friday, 20 September 2019 at 21:51:17 UTC, Walter Bright wrote:
> D supports FP as a useful paradigm, not as a religion. It allows one to easily mix&match FP with imperative code.
>
> I figure we can do the same for ownership/borrowing, that's why it has a separate function attribute (@live) for it.

Personally I am supporter of this approach and I think it is very comfortable for an average software developer.

My observation as a programmer is that in general easier solutions win. This is a simplification of course because there are other critical factors like tools, libraries, compatibility, cost etc.

For example I can watch Python victory march in the IT industry. It devastates other languages in terms of adoption. Yet it is slow, has garbage collector and other "features" which are considered not nice by the programming elite. But on the other hand it has almost all functionalities you would think of and they work quite well with each other. Just search for a library, import a module and call a function. Easy, elegant and effective.

And I think it is good to look at "academic solutions" like borrow checker from a proper perspective as they usually don't work seamlessly in large projects and can cost more than they give.

Cheers,
Piotrek

On Friday, 20 September 2019 at 21:51:17 UTC, Walter Bright wrote:
> D supports FP as a useful paradigm, not as a religion. It allows one to easily mix&match FP with imperative code.
>
> I figure we can do the same for ownership/borrowing, that's why it has a separate function attribute (@live) for it.

That really depends on what you mean by "mix-and-match".

If you mean as a transition path, where you try to eliminate most of the non-@live code as fast as you can, then yes.

If you mean, like with const, some parts of the code use it, some parts don't, but the latter can call the former while remaining @safe, then no.

Given @live as you described it, non-@live functions calling @live functions would have to be @system or @trusted, which isn't a state you want half your codebase to be in.

eg:

    @safe @live
    SmartPtr!int createPtr() {
        return SmartPtr!int();
    }

    @safe @live
    void removePtr(ref SmartPtr!int ptr) {
        ptr.reset();
    }

    @safe
    int* identity(return ref int n) { return &n; }

    @safe
    void test() {
        auto ptr = createPtr;
        int* p = identity(ptr.get());
        removePtr(ptr);
        *p = 1; 		// Memory corruption
    }

On 9/23/2019 1:34 AM, Olivier FAURE wrote:
> Given @live as you described it, non-@live functions calling @live functions would have to be @system or @trusted, which isn't a state you want half your codebase to be in.

@live rules only apply to the internals of the @live function. At some point there must be a presumption that functions that call the @live function or the functions the @live function calls conform at least to the @live function interface.

Otherwise there is simply no way to incrementally adopt @live.