5 ms·

People on C++ chat balked when I brought up the idea that garbage collectors were not inherently evil things, and that some languages with a (for a few of these

People on C++ chat balked when I brought up the idea that garbage collectors were not inherently evil things, and that some languages with a (for a few of these, optional) GC -- like D, Nim, and (written a particular way) even C#, could be used for systems programming or OS'es.

pjmlp 5y ago
Asian Bing used to be powered by Midori for a while. Search Joe Duffy's keynote at one of Rustconf, towards the end he mentions that even proven wrong with Midori running in front of them, the Windows team was telling him it wasn't possible. By the way, F-Secure ships security keys with firmware written in bare metal Go.
Rochus 5y ago
These are two different questions: should C++ have a GC, and is a GC language suitable for systems programming. There is actually already a GC which works well with C++ and is also used by some of the mentioned languages: https://www.hboehm.info/gc/ https://www.hboehm.info/gc/. Personally I think the C++ specification is already far too big and complex (so why adding even more stuff). A lot of GC languages were more or less successfully used to develop operating systems (even Lisp, Smalltalk and Java). From my point of view Oberon is not particularly suited for this purpose, but obviously it was used to implement the Oberon system (using some dark corners of the SYSTEM module and undocumented language features).
- pjmlp 5y ago
  1990's Oberon does indeed lack some features, as pointed out in EthOS paper, however Active Oberon has all the required features, comparable to Modula-3. And A2 is much more pleasant to use. This is why it is my favourite version of Oberon linage. Now it is mostly nostalgia, so it gets down to use Go, .NET Native, D, Nim, Swift, whatever, to reach similar goals. As for C++ GCs, the approaches taken by Unreal C++, C++/CLI and C++/CX are quite alright. However the whole language politics at Microsoft seem to have placed C++/CLI and C++/CX on the extinction path, and C++/WinRT is surely not a replacement for anyone that enjoys productivity over a renewed ATL experience.
  - Rochus 5y ago
    Just wanted to mention that I finally released my Oberon+ version (including an IDE with semantic navigation and source-level debugger for Win, Mac and Linux), see http://oberon-lang.ch http://oberon-lang.ch. Also posted it on HN today: https://news.ycombinator.com/item?id=27855767 https://news.ycombinator.com/item?id=27855767. Currently the compiler generates LuaJIT bytecode (the VM is integrated with the IDE); a .Net CLI backend is work in progress, and an LLVM version is planned.
  - Rochus 5y ago
    What do you mean by "EthOS paper"? Can you please provide a reference?
    - pjmlp 5y ago
      Sure, "Insight ETHOS: On object-orientation in operating systems" http://dx.doi.org/10.3929/ethz-a-000666071 http://dx.doi.org/10.3929/ethz-a-000666071 Scattered across the sections there are some remarks on some of the issues that lack of untraced references, or the existing finalization mechanisms were cause of attrition. In Active Oberon those complains are no longer valid. By the way, the author is relatively well know in research area nowadays.
      - Rochus 5y ago
        Thanks, interesting; I have looked through the PhD report, but think that Active Oberon only addresses a fraction of the issues; e.g. the "loopholes" described in section 4.4.3 are still present even in more recent Oberon versions; and issues like low level bit manipulation were apparently not the topic of the PhD, but only addressed recently (in http://cas.inf.ethz.ch/projects/a2/repository/raw/trunk/LanguageReport/OberonLanguageReport.pdf http://cas.inf.ethz.ch/projects/a2/repository/raw/trunk/Lang... or my version of the language).
        pjmlp 5y ago
        Active Oberon also addresses having better mechanisms for finalization and untraced references, which allows for more fine grained memory management.

pjmlp 5y ago

Asian Bing used to be powered by Midori for a while. Search Joe Duffy's keynote at one of Rustconf, towards the end he mentions that even proven wrong with Midori running in front of them, the Windows team was telling him it wasn't possible. By the way, F-Secure ships security keys with firmware written in bare metal Go.

Rochus 5y ago

These are two different questions: should C++ have a GC, and is a GC language suitable for systems programming. There is actually already a GC which works well with C++ and is also used by some of the mentioned languages: https://www.hboehm.info/gc/ https://www.hboehm.info/gc/. Personally I think the C++ specification is already far too big and complex (so why adding even more stuff). A lot of GC languages were more or less successfully used to develop operating systems (even Lisp, Smalltalk and Java). From my point of view Oberon is not particularly suited for this purpose, but obviously it was used to implement the Oberon system (using some dark corners of the SYSTEM module and undocumented language features).

pjmlp 5y ago
1990's Oberon does indeed lack some features, as pointed out in EthOS paper, however Active Oberon has all the required features, comparable to Modula-3. And A2 is much more pleasant to use. This is why it is my favourite version of Oberon linage. Now it is mostly nostalgia, so it gets down to use Go, .NET Native, D, Nim, Swift, whatever, to reach similar goals. As for C++ GCs, the approaches taken by Unreal C++, C++/CLI and C++/CX are quite alright. However the whole language politics at Microsoft seem to have placed C++/CLI and C++/CX on the extinction path, and C++/WinRT is surely not a replacement for anyone that enjoys productivity over a renewed ATL experience.
- Rochus 5y ago
  Just wanted to mention that I finally released my Oberon+ version (including an IDE with semantic navigation and source-level debugger for Win, Mac and Linux), see http://oberon-lang.ch http://oberon-lang.ch. Also posted it on HN today: https://news.ycombinator.com/item?id=27855767 https://news.ycombinator.com/item?id=27855767. Currently the compiler generates LuaJIT bytecode (the VM is integrated with the IDE); a .Net CLI backend is work in progress, and an LLVM version is planned.
- Rochus 5y ago
  What do you mean by "EthOS paper"? Can you please provide a reference?
  - pjmlp 5y ago
    Sure, "Insight ETHOS: On object-orientation in operating systems" http://dx.doi.org/10.3929/ethz-a-000666071 http://dx.doi.org/10.3929/ethz-a-000666071 Scattered across the sections there are some remarks on some of the issues that lack of untraced references, or the existing finalization mechanisms were cause of attrition. In Active Oberon those complains are no longer valid. By the way, the author is relatively well know in research area nowadays.
    - Rochus 5y ago
      Thanks, interesting; I have looked through the PhD report, but think that Active Oberon only addresses a fraction of the issues; e.g. the "loopholes" described in section 4.4.3 are still present even in more recent Oberon versions; and issues like low level bit manipulation were apparently not the topic of the PhD, but only addressed recently (in http://cas.inf.ethz.ch/projects/a2/repository/raw/trunk/LanguageReport/OberonLanguageReport.pdf http://cas.inf.ethz.ch/projects/a2/repository/raw/trunk/Lang... or my version of the language).
      - pjmlp 5y ago
        Active Oberon also addresses having better mechanisms for finalization and untraced references, which allows for more fine grained memory management.