BetterC Is Not Ready

[Jack Stouffer]

I really hate to make yet another forum post complaining about 
the language, but I've seen a lot of people mention BetterC in 
discussions here and on reddit as a selling point for D. I want 
people to be realistic about the current state of BetterC before 
people make promises that D can't deliver. And, hopefully this 
post will let the language maintainers know what the BetterC 
real-world experience is.

It's currently practically impossible to translate existing D 
code to use BetterC in a large code base (haven't tried existing 
C code, I imagine it's easier). I have an existing app which is 
~100,000 lines of D code and I've tried and failed to convert it 
to BetterC with my own custom runtime.

The problem which stopped me cold was the BetterC error messages, 
which are useless. A lot of code which would normally silently 
use druntime now A) gives an error message with no line number 
and no indication of how to fix the problem or B) gives a linker 
error with no indication of how to fix it:

https://issues.dlang.org/show_bug.cgi?id=19945
https://issues.dlang.org/show_bug.cgi?id=19946
https://issues.dlang.org/show_bug.cgi?id=21477
https://issues.dlang.org/show_bug.cgi?id=22258
https://issues.dlang.org/show_bug.cgi?id=22334
https://issues.dlang.org/show_bug.cgi?id=22427

This is just a sample of the issues. Some of these have the same 
root cause, but you get the point.

These confusing error messages preclude BetterC's use in many 
production settings. Innocuous looking code produces errors whose 
source can only be identified via tedious trial and error, let 
alone figuring out how to fix the errors. Anyone who has to work 
against deadlines cannot waste their time like this. I don't 
think it's unreasonable to expect my compiler to give me line 
numbers in the error messages, especially when the alternative is 
manually auditing 100,000 lines of code.

Language features being in "beta" or in flux is fine. But it's 
not fine when they're touted as a major selling point of the 
language. BetterC isn't finished, and people need to stop 
promoting it like it is.

I really do hope BetterC continues to be worked on, as I think 
there's a lot of room for innovation in D with many custom 
runtimes. Each could be suited to specific programming tasks 
(think musl vs glibc but more specialized) which is something 
unique D could provide.