[fotad]

D community spent most time argue something not important and miss 2 big opportunities.

1. Cloud - D is perfect for serverless if D improve its GC and standard library, language like go probably won't even exists in first place.

2. Mobile - in early day, mobile is slow and has low memory, If D has good tools and GUI framework, it will take off. Even today, it's difficult to crate app for mobile using D.

LLVM probably the last straw that D out of favor, before LLVM, crate product ready language is difficult, now, everyone is creating their own language...

[pjmlp]

A couple of remarks.

For all the praise LLVM gets, already in the mid-70's compiler based frameworks were a thing, IBM PL.8 RISC project, and early 1980's Amsterdam Compiler Toolkit are two notable examples of similar stacks.

Go would still exist, because Google would never picked D for their cloud projects, and its adoption grew from Go creators working at Google. See how sucessfull Oberon and Limbo projects from the same authors were, before their Google days.

While C++, Java and .NET now have most of the features that D was known for when Andrei Alexandrescu published his Programming in D book, I still think the execution in D is better packaged, although yeah, wihtout the related ecosystem and IDE tooling, it is an hard sell.

Maybe "slow and steady" still will surprise us, like it took Rails to make Ruby known outside Japan, or maybe it is too late no matter what.

Future will tell.

[JonChesterfield]

A compiler translates from language A to language B, hopefully improving it along the way. If you let A = B, you get the compiler pipeline model. It's popular because it's effective and obvious.

LLVM has the core IR structure as an in memory structure and as a text format and as a binary format. The easy, lossless (modulo partial implementation of new features) conversion between the formats was a really big deal. I'd be interested to hear of prior art on it.

In particular, it means developers can diff the IR between passes and generally apply textbased tooling to it during debugging, and you can do things like link time optimisation really easily by combining separate files then running them through the optimiser.

LLVM is creaking a little under its age, and I don't think it's ideal that it's written in C++, but the flexible architecture is legitimately better than I've seen in other compilers. In particular, it has been a competitive edge over GCC.

[pjmlp]

One that I left out, Project Phoenix from Microsoft Research, using MSIL for similar purposes, with C# and C++ compilers.

Unfortunely when they killed the project, little was left on the Internet, and they have other projects with the same name.

https://en.wikipedia.org/wiki/Microsoft_Phoenix

https://devblogs.microsoft.com/cppblog/channel-9-video-andy-...

The paper "An overview of the PL.8 compiler" refers to how they implemented a multi-stage IL pipeline to write a mostly safe systems programming for IBM RISC project.

https://dl.acm.org/doi/10.1145/800230.806977

Unfortunely there isn't much publicly available, and IBM eventually pivoted the RISC efforts into AIX, thus abandoning this effort.

Amsterdam Compiler Toolkit used EM intermediate language as its bitcode format,

https://en.wikipedia.org/wiki/Amsterdam_Compiler_Kit

If you delve into ACM, IEEE, SIGPLAN and related stuff, there will be similar projects, LLVM ended up getting the spotlight thanks to Apple and Google's sponsorship, followed by others in the industry.

I still hope that GraalVM (nee MaximeVM at Sun Research Labs) will keep going, as it is yet another approach for compiler toolkits, with a safer language.

[DeathArrow]

>One that I left out, Project Phoenix from Microsoft Research, using MSIL for similar purposes, with C# and C++ compilers.

Can't CoreCLR be used for the same stuff?

[pjmlp]

Not really, this was something like LLVM.

For some workflows, it might be doable, for the whole package, what people use compiler frameworks for, CoreCLR still lacks many knobs.

[5-]

nit:

project oberon, though in many ways related, is by wirth.

you were probably thinking of alef (the early csp language) on plan9 (the bell-labs' research unix successor).

limbo and its os/vm inferno were an attempt to commercialise those ideas amid the java craze.

[pjmlp]

Only if you ignore all the Oberon versions that came after 1.0.

So if we are being pedantic, Oberon-V,

https://www.research-collection.ethz.ch/bitstream/handle/20....

Inferno is Plan 9's successor, and Limbo embodies the ideas that Alef failed to deliver, replaced by a C based library instead.

Regardless if Inferno and Limbo were a way to fight against Java based OSes, they failed in the market.

[5-]

> Oberon-V [robert griesemer's phd]

thanks! i didn't know of this connection.

[pjmlp]

Which is basically the reason why Go has Oberon-2 method syntax and SYSTEM package as unsafe.