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.
