GCs in the news

[Paulo Pinto via Digitalmars-d]

On Friday, 18 July 2014 at 09:25:46 UTC, Chris wrote:
> On Thursday, 17 July 2014 at 18:19:04 UTC, H. S. Teoh via 
> Digitalmars-d wrote:
>> On Thu, Jul 17, 2014 at 05:58:14PM +0000, Chris via 
>> Digitalmars-d wrote:
>>> On Thursday, 17 July 2014 at 17:49:24 UTC, H. S. Teoh via 
>>> Digitalmars-d
>>> wrote:
>> [...]
>>> >AFAIK some work still needs to be done with std.string; 
>>> >Walter for
>>> >one has started some work to implement range-based 
>>> >equivalents for
>>> >std.string functions, which would be non-allocating; we just 
>>> >need a
>>> >bit of work to push things through.
>>> >
>>> >DMD 2.066 will have @nogc, which will make it easy to 
>>> >discover which
>>> >remaining parts of Phobos are still not GC-free. Then we'll 
>>> >know
>>> >where to direct our efforts. :-)
>>> >
>>> >
>>> >T
>>> 
>>> That's good news! See, we're getting there, just bear with 
>>> us. This
>>> begs the question of course, how will this affect existing 
>>> code? My
>>> code is string intensive.
>>
>> I don't think it will affect existing code (esp. given 
>> Walter's stance
>> on breaking changes!). Probably the old GC-based string 
>> functions will
>> still be around for backwards-compatibility. Perhaps some of 
>> them might
>> be replaced with non-GC versions where it can be done 
>> transparently, but
>> I'd expect you'd need to rewrite your string code to take 
>> advantage of
>> the new range-based stuff. Hopefully the rewrites will be 
>> minimal (e.g.,
>> pass in an output range as argument instead of getting a 
>> returned
>> string, replace allocation-based code with a UFCS chain, 
>> etc.). The
>> ideal scenario may very well be as simple as tacking on
>> `.copy(myBuffer)` at the end of a UFCS chain. :-P
>>
>>
>> T
>
> That sounds good to me! This gives me time to upgrade my old 
> code little by little and use the new approach when writing new 
> code. Phew!
>
> By the way, my code is string intensive and I still have some 
> suboptimal (greedy) ranges here and there. But believe it or 
> not, they're no problem at all. The application (a plugin for a 
> screen reader) is fast and responsive* (according to user 
> feedback) like any other screen reader plugin, and it hasn't 
> crashed for ages (thanks to GC?) - knock on wood! I use a lot 
> of lazy ranges too plus some pointer magic for work intensive 
> algorithms. Plus D let me easily model the various relations 
> between text and speech (for other use cases down the road). 
> Maybe it is not a real time system, but it has to be 
> responsive. So far, GC hasn't affected it negatively. Once the 
> online version will be publicly available, I will report how 
> well vibe.d performs. Current results are encouraging.
>
> As regards Java, the big advantage of D is that it compiles to 
> a native DLL and all users have to do is to double click on it 
> to install. No "please download JVM" nightmare. I've been 
> there. Users cannot handle it (why should they?), and to 
> provide it as a developer is a waste of time and resources, and 
> it might still go wrong which leaves both the users and the 
> developers angry and frustrated.
>
> * The only thing that bothers me is that there seems to be a 
> slight audio latency problem on Windows, which is not D's 
> fault. On Linux it speaks as soon as you press <Enter>.

Java has AOT compilers available since the early days. Most 
developers just tend to ignore them, because they are not part of 
the free package.

--
Paulo