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.

On Thursday, 2 June 2022 at 19:40:49 UTC, Jack Stouffer wrote:

Why are specialized runtimes a good idea? It's so much stuff to get perfect, for what benefit?

What part of reimplementing exception handling helps me write a better lap time optimizer?

For target support diversity is useful but if you said "We're writing a new runtime implementation, no new features for a month" to your boss they would rightly be confused.

On Thursday, 2 June 2022 at 19:40:49 UTC, Jack Stouffer wrote:

More practically we can probably find a way to spot failed links and hint that you should be using D.

On Thursday, 2 June 2022 at 20:42:10 UTC, Adam D Ruppe wrote:

1. Smaller exe files
2. Faster link times
3. Ideally I want to remove a lot of my dependence on the C runtime and substitute my own because its quality varies wildly from implementation to implementation. It's hard to do that in across the app when I'm still using druntime.
4. It's a game, and if it's at all successful I don't look forward to having to port druntime to Playstation's OS.

On Thursday, 2 June 2022 at 21:18:55 UTC, max haughton wrote:

Same question could be asked about different programming languages in general. Was it a waste for D to be created when C++ exists?

A simple example of a specialized runtime would be an audited simple runtime that could be used in security applications.

I don't use exceptions and I think they're a bad idea. Without that, a GC, and OOP my runtime would be much smaller than druntime.

And the reason it helps you is because simpler or less code in general is easier to understand. When people understand what their code is doing it becomes easier to maintain and easier to optimize. I think a lot of people would be very surprised if they use the "step into" in their debugger throughout their code to see what the code is actually spending its time on.

I want less code not more. Phobos and druntime are a lot of code I don't need and don't want in my project. This is not to say that you're somehow wrong to use it in yours. That's fine. I just want the option not to use it.

Why are you assuming everyone is going to write a runtime themselves? I plan to but I don't expect most people to, just as I don't expect most people to write their own D compiler.