On Sunday, 21 September 2014 at 01:46:13 UTC, Andrei Alexandrescu wrote:
> On 9/20/14, 5:30 PM, deadalnix wrote:
>> On Saturday, 20 September 2014 at 16:27:33 UTC, Andrei Alexandrescu wrote:
>>>> I don't think ARC is needed.
>>>>
>>>> library RC + borrowing + uniqueness/moving = WIN
>>>
>>> s/WIN/Rust/
>>
>> Well Rust does some things well. We are going in the same direction
>> anyway (type qualifier, uniqueness) expect we do it in an ad hoc manner
>> that is guaranteed to yield a C++ish result.
>
> Rust looked a lot more exciting when I didn't know much about it. -- Andrei

Ho come on, there is a reason why I'm here and not on rust's mailing list. I'm aware of various shortcomings of rust. Reading my message as a promotion of rust is a gross strawman.

And here is the thing. You and Walter closed one door to this kind of feature when discussed with Bartoz a while ago and won't admit you are wrong. Then whole thing degenerate in some ridiculous church war where all rhetorical trick and logical fallacy is good to use.

That is pretty much how it degenerated with the concept vs static if discussion. The whole debate become completely ridiculous (yes, your dismissal of concept is almost as ridiculous as Bjarne's rebuttal of static if). Because at this point, this is not about what is best, but about who is right.

Back to the subject, that door was closed few years ago. Now we are discussing pile of hacks again and again and again. The final complexity is WAY higher than the initial proposal. Be it Bartoz's, rust's, isolated or whatever variation of the concept, this is pretty much a given by now that it is needed.

As far as I'm concerned, isolated/owned (not even talking about rust's concepts like burrowing) on the GC should probably be valid in @nogc, and only the promotion to TL, shared or immutable heap should be invalid in @nogc. You combine that with require that you throw isolated/owned/whatever, and the whole discussion we are having here becomes moot (as well as various it can reduce friction between the GC world and the non GC world greatly).

On Sunday, 21 September 2014 at 02:10:13 UTC, bearophile wrote:
> Andrei Alexandrescu:
>
>> Rust looked a lot more exciting when I didn't know much about it.
>
> I didn't remember ever seeing you excited about Rust :-) In past you (rightfully) didn't comment much about Rust. But do you have more defined ideas about it now? Do you still think D has a chance against Rust?
>
> Bye,
> bearophile

It is clear that rust has some serious limitations.
 - It interact badly with the existing world (other languages).
 - It is slow to compile.
 - Constraints too much the dev in some paradigms, which obviously won't fit all area of programming.
 - It bets on many unproven mechanism (ie see error handling). Some of them may be real hit, but I doubt ALL of them will be, and these which won't be will have to be worked around, adding complexity.
 - The macro system is plain horrible, and the only way to do code generation.

Rust has many cool goodies, but it is generally too radical.

On 9/20/14, 7:10 PM, bearophile wrote:
> Andrei Alexandrescu:
>
>> Rust looked a lot more exciting when I didn't know much about it.
>
> I didn't remember ever seeing you excited about Rust :-) In past you
> (rightfully) didn't comment much about Rust. But do you have more
> defined ideas about it now? Do you still think D has a chance against Rust?

I don't think Rust has a chance against D. -- Andrei

On Saturday, 20 September 2014 at 16:56:32 UTC, Andrei Alexandrescu wrote:
> On 9/20/14, 8:08 AM, Jacob Carlborg wrote:
>> On 2014-09-20 16:33, Paulo Pinto wrote:
>>
>>> It requires compiler support, though.
>>
>> The first thing I asked in this thread was "Are you suggesting we
>> implement ARC?" and the answer was "Yes" [1]. So it looks like Andrei
>> already wants to implement ARC. My definition of ARC is that the
>> compiler inserts the calls to retain/release (or whatever you call them).
>>
>> [1]
>> http://forum.dlang.org/thread/lvhiam$1pno$1@digitalmars.com#post-lvi0ve:2429il:241:40digitalmars.com
>
> Please don't take me in a court of law. But yes, I am talking about the compiler inserting calls to increment and decrement reference counts. -- Andrei

I suggest the compiler insert calls to whatever "lifetime events" may cause an increment/decrement.  Then, the druntime can provide the implementation.

I believe with these runtime hooks in place platform-specific optimizations and even alternative memory managers can be experimented with.

I refer you to an enlightening quote I once found on a raytracing site that really captures the beauty of software:
"You know you've been raytracing too long when you've been asked how you did that thing you did by the author of the raytracer you used to do it."

Just build the capability, and let the community surprise you with their ingenuity.

Mike

I'm just throwing a new ThisOutThereException:

What if we modified the exception hierarchy to have it so "Throwable"s are GC allocated but there's an alternate set of classes down another line that either must be manually managed or are RC. Thus, there's no breakage.

Something like:

class Throwable : __UnifiedThrowable ...

class NoGCThrowable : __UnifiedThrowable ...


That way any code that's catching/handling Throwables doesn't need to change but we start making it so that code that needs to be NoGC handles the NoGCThrowable types. This would mean code could be migrated gradually to the new method (and, if truly desireable, the regular throwables could be deprecated eventually).

Just an idea.

Am 21.09.2014 04:50, schrieb Andrei Alexandrescu:
> On 9/20/14, 7:10 PM, bearophile wrote:
>> Andrei Alexandrescu:
>>
>>> Rust looked a lot more exciting when I didn't know much about it.
>>
>> I didn't remember ever seeing you excited about Rust :-) In past you
>> (rightfully) didn't comment much about Rust. But do you have more
>> defined ideas about it now? Do you still think D has a chance against
>> Rust?
>
> I don't think Rust has a chance against D. -- Andrei
>

The real question is which language, from all that want to replace C++, will eventually get a place at an OS vendors SDK.

So far, the winning ones seem to be Swift on Apple side, and .NET Native-C++/CLX on Microsoft side (who knows what are they doing with M#).

Maybe someone in the commercial UNIX (FOSS is too bound with C), real time or embedded OS space?

--
Paulo

On Sunday, 21 September 2014 at 04:59:12 UTC, Paulo Pinto wrote:
> Am 21.09.2014 04:50, schrieb Andrei Alexandrescu:
>> On 9/20/14, 7:10 PM, bearophile wrote:
>>> Andrei Alexandrescu:
>>>
>>>> Rust looked a lot more exciting when I didn't know much about it.
>>>
>>> I didn't remember ever seeing you excited about Rust :-) In past you
>>> (rightfully) didn't comment much about Rust. But do you have more
>>> defined ideas about it now? Do you still think D has a chance against
>>> Rust?
>>
>> I don't think Rust has a chance against D. -- Andrei
>>
>
> The real question is which language, from all that want to replace C++, will eventually get a place at an OS vendors SDK.
>
> So far, the winning ones seem to be Swift on Apple side, and .NET Native-C++/CLX on Microsoft side (who knows what are they doing with M#).
>
> Maybe someone in the commercial UNIX (FOSS is too bound with C), real time or embedded OS space?
>
> --
> Paulo

Interop, interop, interop.  Walter and Andrei are right when they talk about the importance of C++ interop - not only do you get to leverage those libraries, but it reduces the barrier to entry for D in more environments.

Swift will never be more important than Objective C was - which is to say it'll be the main development language on Apple products and probably nothing else.  That has real value, but the limits on it are pretty hard and fast (which says more about Apple than the language itself.)

.NET suffers a similar problem in spite of the community's best efforts with Mono - it'll always be a distant 2nd (or 5th or 20th) on other platforms.  And on Windows, C++ won't get supplanted by .NET absent a sea-change in the mindset of the Windows OS group - which is notoriously resistant to change (and they have a colossal existing code base which isn't likely to benefit from the kind of inflection point Apple had moving to a BSD and porting/rewriting scads of code.)

So C/C++ is it for universal languages, really (outside of the web server space, where you have a large Java deployment.)  I don't think D needs to be the next .NET (of any flavor) or the next Swift, and I don't see as it is being positioned that way either - the target to me is clearly C/C++.  It doesn't need to compete with languages that have lesser universality, though it should (and does) borrow the good ideas from those languages.

I don't think D needs to look at *replacing* C++ in the near or mid term either - it still needs to convince people it deserves a place at the table.  And the easiest way to do that is to get this C++ interop story really nailed down, and make sure D's warts are smaller than C++'s.  And, of course, the GC strawman that native programmers always claim is more important than it really is.  I like the threads going on currently about ARC and related technologies - there's a real chance to innovate here.

On Sunday, 21 September 2014 at 05:55:20 UTC, Cliff wrote:
> .NET suffers a similar problem in spite of the community's best efforts with Mono - it'll always be a distant 2nd (or 5th or 20th) on other platforms.  And on Windows, C++ won't get supplanted by .NET absent a sea-change in the mindset of the Windows OS group - which is notoriously resistant to change (and they have a colossal existing code base which isn't likely to benefit from the kind of inflection point Apple had moving to a BSD and porting/rewriting scads of code.)
>

A bit OT: but Mono seems to be a popular platform for desktop application on linux. I have no idea why.

On Sunday, 21 September 2014 at 03:28:03 UTC, Mike wrote:
> I suggest the compiler insert calls to whatever "lifetime events" may cause an increment/decrement.  Then, the druntime can provide the implementation.
>
> I believe with these runtime hooks in place platform-specific optimizations and even alternative memory managers can be experimented with.
>

Your post gave me an idea already, so far we've only been focusing on Throwable, however... the solution for Error:s and Exception:s is actually asymmetric!

For the vast majority of applications the best possible implementation for Error:s is to simply leak the memory, this is definitely not true for Exceptions(but it could be true for a small subset of applications, short-lived tools).

Daniel

Am 21.09.2014 08:05, schrieb deadalnix:
> On Sunday, 21 September 2014 at 05:55:20 UTC, Cliff wrote:
>> .NET suffers a similar problem in spite of the community's best
>> efforts with Mono - it'll always be a distant 2nd (or 5th or 20th) on
>> other platforms.  And on Windows, C++ won't get supplanted by .NET
>> absent a sea-change in the mindset of the Windows OS group - which is
>> notoriously resistant to change (and they have a colossal existing
>> code base which isn't likely to benefit from the kind of inflection
>> point Apple had moving to a BSD and porting/rewriting scads of code.)
>>
>
> A bit OT: but Mono seems to be a popular platform for desktop
> application on linux. I have no idea why.

I think it may come from C++ hate that GNU/Linux enjoys, or at least it used to enjoy.

Back in the early days suggesting using C++ was an heresy, although corporate developers were slowly migrating to it in commercial UNIX settings.

So you got to do CORBA in C, OO in C (Gtk) and so on.

When I used to take part in gtkmm discussions  (early 2000), the usual C vs C++ discussions on GNOME mailing lists were quite common.

Qt and KDE were a no go for many, due to licesing issues.

So C++ usage was limited to those of us already into C++ that weren't that keen in using plain C. A minority,

Meanwhile, Microsoft released .NET and Miguel and others, which already had ported Microsoft technologies (Bonobo(COM), Evolution(Outlook)...) started Mono.

Given that they were also GNOME maintainers, there was this big discussion going on about GNOME becoming tainted with Mono.

To the point GNOME created Vala, which is basically C# that compiles to C and uses gobject as runtime system.

I used to be in the "we don't want .NET on GNU/Linux" side.

Nowadays I can only congratulate Miguel and the others that persisted against naysayers like myself. Specially given what happened with Oracle vs Google.

Which Xamarin and Microsoft took advantage of with the "Community license for open source".

Slowly, as the amount of users started to increase, I guess the GNU/Linux opinion about Mono, started to change.

So if you want to use a modern programming language, with bindings to
most common UI frameworks and ability to generate fast code, there aren't many other options.

Here I would say D could also fit the bill, but lacks visibility by the average GNU/Linux coder on the playground discussions.


This is just an opinion, maybe I am too far of the real reasons.

--
Paulo