For background -- and I am not an expert here -- their C++ frontend is widely known. I first heard of it because Visual C++'s Intellisense uses it, which was notable because VC does not use the msvc frontend for its own completion. I understand it's been either used or evaluated for other frontends in the past too. I worked as PM for one C++ product, and was fortunate to be able to learn a lot from our engineers; we didn't use it, but they thought highly of EDG.
It has a very strong reputation for being correct. And as such, I think open sourcing it will be a very beneficial thing for the C++ community.
What is not to like, job security, it is a compiled language, standard is still ongoing (there is even OOP support), one can write microservices in it, there are IDEs, and most relevant, it is still much less English to type than AI Markdown files.
As curses go, not a curse! <a href="https://github.com/loveOSS/awesome-cobol" rel="nofollow">https://github.com/loveOSS/awesome-cobol
I'm really confused by this list: every link I click on either doesn't work or takes me to a project for Go written in Go. I haven't been able to navigate to a single Cobol project.
Yeah, going back and checking, it is weird. My bad, I am a little embarrassed, I too find no cobol, only Go.
To make up for my transgression ...
Here is Doom in Cobol tho <a href="https://github.com/deios0/cobol-doom" rel="nofollow">https://github.com/deios0/cobol-doom
Rock Paper Scissors in Cobol as a Cloudflare Worker <a href="https://github.com/cloudflare/cobol-worker/blob/master/src/worker.cob" rel="nofollow">https://github.com/cloudflare/cobol-worker/blob/master/src/w...
Still excited to see C++ get slowly replaced by better languages.
There are essentially four C++ frontends: gcc, clang, MSVC, and EDG. Pretty much every C++ compiler is a reskinned version of one of those compilers. Most of the proprietary compilers have been slinking away from using EDG to using clang (e.g., Intel did this transition a few years ago).
The reason why the EDG frontend is being open-sourced is because EDG itself is closing up shop, and the open sourcing is an interim solution as EDG's customers work on migrating to using Clang instead. So... it's really not good news, because it means that one of the frontends is basically reaching end-of-life.
C++ is a sprawling language which will consume any available amount of effort or goodwill. So I don't expect you will see a "new life" for this codebase while continued effort on the "big three" compilers happens.
Where would that new life come from? As far as I am aware, there isn't exactly a thriving community around it which has been begging for a source release for ages, and with Clang and GCC there hasn't been a shortage of open-source C++ compilers either. And it's not exactly like the C++ ecosystem as a whole is booming, with it not having any answer to the memory safety problem.
From what I can tell this is just some retiring guys who want to make sure their life's work isn't lost to history, and who want to avoid screwing over their handful of remaining customers. Realistically, the best you can hope for is probably the occasional bugfix, and other open-source compilers scavenging it for a handful of useful clever ideas.
Maybe they're hoping the remaining customers will cooperate on keeping it up to speed? I know that f.ex. IAR are building their own backends,etc and might be an EDG customer, the MSVC IDE team aswell, now if they'll manage to get it working is another question but with the code in the open there's a chance at least.
Why not defect to clang? I'm sure some PHB's will suggest that (and that will be part of the survival, convincing those that supporting another party is a good thing).
Standardization does have it's issues, but the JS ecosystem always seems to be healthier when one implementation isn't too dominant. The question is if the C++ ecosystem is large enough to support multiple frontends.
The thing is, who's going to pull the cart? Giving stewardship to a nonprofit is perfectly fine from an IP perspective, and they'll have no trouble finding someone to herd some bugfixes, but what's going to happen when significant refactoring is needed to add support for C++26/29/etc?
Having your resident compiler expert upstream the occasional patch to keep your legacy product from dying is one thing, but which big tech company cares about this specific compiler enough to spin up an entirely new dedicated team for it? And who's going to choose a mostly-abandoned compiler front-end as a core part of a new product?
Sure, it can be done, but for each individual user defecting to clang must be looking very attractive right now.
If they're all downstream users and rebuilding their entire infrastructure on Clang might not be the most enticing thing if they're deeply embedded into EDG in their products and EDG can be kept alive with small costs per company.
I think that's the point of the whole point of a nonprofit stewardship, that a few developers each from the main customers can come together and cooperate well enough on the upstream that they don't have to take the entire cost of changing downstream to Clang or maintaining a frontend.
There are fundamental differences in the design of clang and EDG at IR level that would affect whether clang can work for your use cases at all. I don't know enough in this area, so I won't say anything incorrect that would embarrass myself, but that's something you could look into.
I estimate there were very roughly 50 customers in the end. (I was an EDG engineer and didn't work on admin stuff — so it might be off, but not much. I'm estimating based on support tickets origins.) That's down from maybe double that at our max (again, my estimate). I heard of fairly few customers switching to Clang or other projects (Intel being the most notable exception). Most of our customers we "lost" were due to mergers/acquisitions (i.e., two customers suddenly became just one).
This. Maintaining a C++ front end is a lot of hard work that requires expertise -- I wouldn't be surprised if there are a bunch of CS PhDs in the team. You don't just randomly hire someone to work on compilers like with web development. I seriously doubt there will be a lot of contributions coming from the community. Maybe bug fixes, but likely not keeping up with C++ standards.
Well, if you're fine with not being up to date in terms of C++ standards there is also the OpenWatcom C/C++ compiler[0]. Jiří Malák (the main v2 dev) is doing a herculean job maintaining and improving it.
According to some older comment by jmalak, it is compatible with C++98/C++03 with some C++11 features though, yes, it isn't C++11 compatible (there are some stubs for C++11 that i can see in the code but nothing implemented).
And that's a thing though, SFINAE hinted at it but more recent versions of C++ constexpr and consteval together with relaxed constexpr and "if constexpr" and "if consteval" together with compile-time dynamic typing forced the compiler to more or less include an interpreter in the frontend.
Adding some features of C++11 isn't close to building a C++ compiler capable of 11, 14, let alone 17, 20, 23 or 26.
If you can rip out a compliant parser, it might even be better to start over on a new compiler frontend if your current compiler frontend is targeting at pre-11 level.
In my day (2006–2011) Green Hills used EDG's frontend. I have the vague impression they might have already switched away. (I know Intel ICC already switched to Clang a while ago.) I'd be very surprised to learn that GHS had ever developed their own frontend.
I'm surprised it was using EDG. My memory of green hills is that it would regularly crash on valid C++, to the point where I assumed it could only be a shitty homegrown implementation.
> I'd be very surprised to learn that GHS had ever developed their own frontend.
Actually I take that back. At the dawn of time (1982), GHS definitely had its own frontend. They switched to EDG sometime before my time. I meant I'd be surprised to learn they'd switched from EDG to something home-grown.
This also meant that in my time there was a hefty "glue" layer between the EDG frontend and the GHS middle-end (the middle-end being the tree transformations and "indep" optimizations before you got into the back-end stuff): you had to take the structures EDG produced and turn them into the structures the GHS middle-end wanted.
I was there right when John Regehr's Csmith was first making big waves. We started using it, and also rolled our own fuzzer with more focus on embedded-software trouble spots, such as `volatile` and `packed` and I forget what else. (Guy Goldstein originated and led this, as I recall.) I don't actually remember the fuzzer finding a lot of crashes, but maybe it did, and I do remember its finding a lot of miscompilations, i.e., bad optimizations.
Oracle Studio C++ and IBM XL C++ still exist, but the old front-ends are almost dead. They were both able to achieve partial C++14 support before giving up and choosing a side. Oracle chose GCC, IBM chose Clang.
I might be wrong, but I always assumed that Gimple Lint / PC Lint has its own C++23 frontend too. It looks very different from what other compilers have.
vintagedave · · focus · HN ↗
For background -- and I am not an expert here -- their C++ frontend is widely known. I first heard of it because Visual C++'s Intellisense uses it, which was notable because VC does not use the msvc frontend for its own completion. I understand it's been either used or evaluated for other frontends in the past too. I worked as PM for one C++ product, and was fortunate to be able to learn a lot from our engineers; we didn't use it, but they thought highly of EDG.
It has a very strong reputation for being correct. And as such, I think open sourcing it will be a very beneficial thing for the C++ community.
carterschonwald · · focus · HN ↗
lelanthran · · focus · HN ↗
But also quite sad. They've announced that they are closing down.
genxy · · focus · HN ↗
bigbuppo · · focus · HN ↗
alex_suzuki · · focus · HN ↗
pjmlp · · focus · HN ↗
genxy · · focus · HN ↗
JBits · · focus · HN ↗
genxy · · focus · HN ↗
To make up for my transgression ...
Here is Doom in Cobol tho <a href="https://github.com/deios0/cobol-doom" rel="nofollow">https://github.com/deios0/cobol-doom
Rock Paper Scissors in Cobol as a Cloudflare Worker <a href="https://github.com/cloudflare/cobol-worker/blob/master/src/worker.cob" rel="nofollow">https://github.com/cloudflare/cobol-worker/blob/master/src/w...
Still excited to see C++ get slowly replaced by better languages.
pjmlp · · focus · HN ↗
jcranmer · · focus · HN ↗
The reason why the EDG frontend is being open-sourced is because EDG itself is closing up shop, and the open sourcing is an interim solution as EDG's customers work on migrating to using Clang instead. So... it's really not good news, because it means that one of the frontends is basically reaching end-of-life.
vintagedave · · focus · HN ↗
whobre · · focus · HN ↗
tialaramex · · focus · HN ↗
pjmlp · · focus · HN ↗
Now if they upstream the changes is another matter.
crote · · focus · HN ↗
From what I can tell this is just some retiring guys who want to make sure their life's work isn't lost to history, and who want to avoid screwing over their handful of remaining customers. Realistically, the best you can hope for is probably the occasional bugfix, and other open-source compilers scavenging it for a handful of useful clever ideas.
whizzter · · focus · HN ↗
Why not defect to clang? I'm sure some PHB's will suggest that (and that will be part of the survival, convincing those that supporting another party is a good thing).
Standardization does have it's issues, but the JS ecosystem always seems to be healthier when one implementation isn't too dominant. The question is if the C++ ecosystem is large enough to support multiple frontends.
crote · · focus · HN ↗
Having your resident compiler expert upstream the occasional patch to keep your legacy product from dying is one thing, but which big tech company cares about this specific compiler enough to spin up an entirely new dedicated team for it? And who's going to choose a mostly-abandoned compiler front-end as a core part of a new product?
Sure, it can be done, but for each individual user defecting to clang must be looking very attractive right now.
neutronicus · · focus · HN ↗
whizzter · · focus · HN ↗
I think that's the point of the whole point of a nonprofit stewardship, that a few developers each from the main customers can come together and cooperate well enough on the upstream that they don't have to take the entire cost of changing downstream to Clang or maintaining a frontend.
fg137 · · focus · HN ↗
daveedvdv · · focus · HN ↗
fg137 · · focus · HN ↗
badsectoracula · · focus · HN ↗
[0] <a href="https://github.com/open-watcom/open-watcom-v2" rel="nofollow">https://github.com/open-watcom/open-watcom-v2
jcranmer · · focus · HN ↗
(and I'm implicitly using C++11 here when I say "C++", given that it effectively defines 'modern' C++).
badsectoracula · · focus · HN ↗
whizzter · · focus · HN ↗
Adding some features of C++11 isn't close to building a C++ compiler capable of 11, 14, let alone 17, 20, 23 or 26.
If you can rip out a compliant parser, it might even be better to start over on a new compiler frontend if your current compiler frontend is targeting at pre-11 level.
kvuj · · focus · HN ↗
quuxplusone · · focus · HN ↗
AlotOfReading · · focus · HN ↗
quuxplusone · · focus · HN ↗
Actually I take that back. At the dawn of time (1982), GHS definitely had its own frontend. They switched to EDG sometime before my time. I meant I'd be surprised to learn they'd switched from EDG to something home-grown.
This also meant that in my time there was a hefty "glue" layer between the EDG frontend and the GHS middle-end (the middle-end being the tree transformations and "indep" optimizations before you got into the back-end stuff): you had to take the structures EDG produced and turn them into the structures the GHS middle-end wanted.
I was there right when John Regehr's Csmith was first making big waves. We started using it, and also rolled our own fuzzer with more focus on embedded-software trouble spots, such as `volatile` and `packed` and I forget what else. (Guy Goldstein originated and led this, as I recall.) I don't actually remember the fuzzer finding a lot of crashes, but maybe it did, and I do remember its finding a lot of miscompilations, i.e., bad optimizations.
Xirdus · · focus · HN ↗
jcranmer · · focus · HN ↗
apaprocki · · focus · HN ↗
fithisux · · focus · HN ↗
andikleen2 · · focus · HN ↗
TachyonProducti · · focus · HN ↗
[dead]