SDC needs you -- redux

[Shammah Chancellor via Digitalmars-d]

I'm going to re-iterate what deadalnix said.   I am doing this because 
the thread about SDC got co-opted in this forums usual fashion.

So, let me qualify:

I've been part of this community since late 2001.  We've come a long 
way.  However,  believe having another *good* frontend implementation 
is absolutely key for our success.

Let me qualify this need with some stats.  I don't mean for this list 
to in any way knock Walter or DMD, but rather to just stress the value 
of SDC to the community and also encourage people who do not want to 
spent the time getting over the learning curve for the DMD frontend to 
invest some time implementing simple things in SDC.

1) SDC, libd-llvm, and libd together are ~ 30KLOC of idiomatic and very 
intelligible D code.  Compare this with the 300KLOC for the DMD 
frontend.
	1.1) The 30KLOC is clean and easy to get into.  It took me less than 3 
days to get into it and start implementing language features.
	1.2) This is enabled by the use of a scheduler to easily handle 
complex Dlang features.
	1.3) This will enable advanced compiler normally be very difficult to 
implement
2) SDC supports a majority of the language at this point, the remaining 
work is mostly trivial. (When I say majority, I mean majority in terms 
of LOC needed to support, not in terms of implemented pieces of 
syntatic sugar)
	2.1) We won't need another 250KLOC to get to 100% feature parity.  
We're already at something like 80% feature parity by my estimation.
3) SDC is designed also to be a library that can used for tooling in an 
easy fashion!
	3.1) I work with Golang on a daily basis professionally.  The tooling 
for golang is a major reason for it's adoption.  This tooling looks 
like gofix, gofmt, govet, etc.  We need this tooling to be able to 
succeed.
4) SDC use of fibers and a scheduler allows us to have a very robust 
error handling mechanism that DMD will never be able to implement.   We 
emit beautiful clang-style errors telling you EXACTLY what is wrong 
with your code.
5) SDC is fast.  It is actually faster than DMD when you move into 
template and CTFE land.
6) SDC leverages all the work done by the HUGE llvm group.
7) SDC uses the LLVM JIT for CTFE, this means no double-implementation 
of language features for CTFE, and for normal compilation.
8) Because SDC is written in D, is clean, and uses a JIT this opens up 
the door for actually exposing compiler AST Nodes *directly* to the 
code being compiled. (!!!!!!!!!  No more __traits horror when doing 
metaprogramming)
9) Because SDC is clean, easy to understand, and easy to implement 
language feature on top of, we have been able to find quite a few bugs 
in DMD.  I have been submitting bug reports back to DMD and actually 
causing the mainline D compiler to do a *better* job!

I could go on and on about this.  But I would hope that maybe you just 
clone the git repo, and start fiddling around and submit some simple 
PRs.    We recently reorganized our git repos to make it much easier 
for people to get started.

Again,  I don't mean for this to come off as a knock against DMD or the 
work that has been done there over the last 15 years.   I also don't 
mean to steal any engineering resources from the DMD frontend.   
Instead, I am hoping to appeal to those people, who like myself, do not 
have the time to understand the DMD frontend and work on it.   SDC is 
simple, and easy to get started on.

So again, here is our TODO list:  
https://github.com/deadalnix/SDC/wiki/TODO-list

I hope you will join Amaury and myself in working on this awesome 
project.   We have a #slack channel set up to help us work 
asynchronously, and I would love it if you send me am email so I can 
invite you to the teamchat.   Even just having people in the channel to 
have discourse with would be helpful!

Cheers,
-Shammah