Smart pointers instead of GC?

[Paulo Pinto]

On Tuesday, 4 February 2014 at 12:46:58 UTC, Ola Fosheim Grøstad 
wrote:
> On Tuesday, 4 February 2014 at 11:57:25 UTC, Paulo Pinto wrote:
>> On Tuesday, 4 February 2014 at 11:13:03 UTC, Don wrote:
>
>>> Yeah, I dunno what "systems language" means really.
>>
>> For me it means you can write an OS with it, even if some tiny 
>> parts require the use of Assembly glue.
>
>
> Pretty close to my definition, but I would add:
>
> - you should be able to write a performant OS with it
> - you should be able to use all core language features when 
> doing so
> - the mapping to hardware should be obvious
> - thus the runtime should be transparent/easy to grasp
>
> Basically I think a system level language should provide a 
> minimal library and runtime that you can extend to a OS-level 
> library that you use for implementing all services on your OS.
>
> I think GC+Phobos should be an extension of such a minimal set 
> up.
>
> ---
>
> I don't think ARC is needed for D, because I think you use RC 
> only when needed when writing latency sensitive code and use 
> primarily other strategies (unique pointers, embedded objects 
> etc).
>
> I do think that interop with C++ is a good strategy. Language 
> level support for C++11 pointer types would be a good addition 
> now that they are being used quite extensively. Interop with 
> C++ is more important than Objective-C.
>
> Having a system library core that is GC free would be nice. I 
> think this should be done on the name space level. I.e. having 
> one optimized "core" section that is 100% GC free and one more 
> extensive "std" section that requires GC to be available.
>
> I don't think it is realistic to have all libraries being 
> non-GC. It is better to have useful libraries that are somewhat 
> inefficient than not having them due to complexity issue.
>
> It is better to have a very easy to use and extensible to XML 
> DOM library than to have a more obfuscated and less extensible 
> XML DOM library without GC. But the XML parser library should 
> be GC free.


In Oberon and Modula-3's control over GC tends to be a  bit 
easier than D's current design, because of a few points:

- No implicit allocations outside NEW
- No closures
- You can use untraced pointers in unsafe modules.

However it would be nice to know if anyone here has real life 
experience with Lisp Machines and how was their performance.

--
Paulo