Here's a way to love go, write a language in it https://github.com/grubby/grubby
From Microsoft:
https://msdn.microsoft.com/en-us/library/dd233052%28v=vs.110...
https://msdn.microsoft.com/powershell
Xerox PARC used Cedar for the software implemented on Xerox 1132 (Dorado) and Xerox 1108 (Dandelion) systems, including interpreters delivered on the system:
It didn't have to be this way - Swift could have been written atop the JVM, v8 could have been implemented via Boehm, etc. For whatever reason, when it counts, the stuff under the hood doesn't use garbage collection.
It doesn't matter where those interpreters are being used, the fact is that they exist.
> Microsoft's C# CoreCLR is C++.
Yes, but they have moved their compilers to C# with the Rosylin project with MDIL and .NET Native moving more code to C# side.
Also check the Phoenix compiler framework, a LLVM like project from MSR using C#.
> Go's core runtime is in a Go-minus-GC subset.
Of course, there needs to exist a Genesis for the GC, but once it is there, 99% of the remaining infrastructure makes use of it.
If you take Nashorn engine running on Jikes, it is an 100% Java stack running a JavaScript interpreter.
> For whatever reason, when it counts, the stuff under the hood doesn't use garbage collection.
Most of the time it is just building on top of whatever already exists instead of starting from scratch.
Taking Swift as an example bootstraping the language would increase the burden designing it, as they are still far from fully stable design.
If they would throw away in man years invested into the LLVM, which happens to be written in C++, it would take ages before pure Swift compilers would ever manage to catch up.
However these shortcuts open the door for those not savvy in compiler design to use as ammunition against secure languages.
A compiler is a different matter. GCed languages are very compelling for static compilers. Even gcc uses GC internally.
The claim is that GCed languages make for poor interpreters - and also poor JIT compilers and runtimes.
> If you take Nashorn engine running on Jikes, it is an 100% Java stack running a JavaScript interpreter
Nashorn gets participation points, but it's not competitive with any of the major JS engines, all of which have C++ runtimes.
> Taking Swift as an example bootstraping the language would increase the burden designing it, as they are still far from fully stable design. If they would throw away in man years invested into the LLVM, which happens to be written in C++,
This still confuses the compiler with the runtime. The Swift compiler is indeed written in C++ using LLVM, but it could have easily been written in a GCed language without affecting much of anything.
But the runtime is separate, and it also happens to be written in C++. It's possible to imagine the Swift runtime written in a GCed language, but that is not what Apple chose to do.
Have you ever spent time with Graal, Truffle, PyPy?
30 years ago I used to take the flak for arguing about C++'s suitability for writing programming language tools in comp.compilers instead of C.
Yet here we are praising C++ virtues over other languages for writing interpreters and JITs.
One thing I learned in all those years reading compiler related papers, is that many times the main issues are actually human and not technical.
The majority just want to have something running, and take the shortcut of using whatever works to achieve their goals, instead of taking the effort that might bring the technology forward but would delay getting everything to work.
In practice, the STW mark and sweep phases are in the sub-millisecond range, and the GC runs not nearly as often as 20 times a second, so 10 ms of interruptions per 50 ms is the absolute worst case.
There is an inherent tradeoff between pauses, throughput and extra memory requirements.
If you're interested in the finer details, I'm sure the GC talk at golangUK later this month will discuss them all, and the slides and/or videos will eventually land here on Hacker News.