On Monday, 11 July 2016 at 14:02:09 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 11 July 2016 at 13:24:14 UTC, Chris wrote:
I bet you that if D hadn't had GC when it first came out,
people would've mentioned manual memory management as a reason
not to use GC. I never claimed that D was _propelled_ by GC,
but that it was a feature that most users would expect. Not
having it would probably have done more harm than having it.
Actually, I am certain that GC is a feature that _nobody_ would
expect from a system level language, outside the Go-crowd.
I am no longer dabbling in D, but could not resist:
- UK Royal Navy with Algol 68 RS
- Xerox PARC with Mesa/Cedar
- DEC/Olivetti/Compaq with Modula-3
- ETHZ with Oberon, Oberon-2, Active Oberon, Component Pascal
- Microsoft with Spec#, System C# and the upcoming .NET Native C#
7.0+ features
(http://joeduffyblog.com/2015/12/19/safe-native-code/,
https://www.infoq.com/news/2016/06/systems-programming-qcon)
- Astrobe with Oberon for micro-controlers (ARM Cortex-M4,
Cortex-M3 and
Xilinx FPGA Systems)
- PTC Perc Ultra with Java
- IS2T with their MicroEJ OS Java/C platform
The biggest problem with D isn't the GC, is lack of focus to make
it stand out versus .NET Native, Swift, Rust, Ada, SPARK, Java,
C++17.
