www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - BetterC Is Not Ready

reply Jack Stouffer <jack jackstouffer.com> writes:
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.
Jun 02 2022
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 2 June 2022 at 19:40:49 UTC, Jack Stouffer wrote:

 It's currently practically impossible to translate existing D 
 code to use BetterC in a large code base


.....why would you want to do that?
Jun 02 2022
parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Thursday, 2 June 2022 at 20:42:10 UTC, Adam D Ruppe wrote:

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

 It's currently practically impossible to translate existing D 
 code to use BetterC in a large code base


 .....why would you want to do that?


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.
Jun 02 2022
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 2 June 2022 at 23:01:11 UTC, Jack Stouffer 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.


All this is more realistically achieved with a minimal custom 
druntime, which betterC forbids!

Of course, ideally, the standard runtime would be a bit more 
modular and stuff you don't need easy to drop. But failing that, 
the next best thing is a custom runtime.

betterC is just marketing nonsense (aside from MAYBE being a 
common baseline for runtime-agnostic libraries) without much 
practical benefit.
Jun 02 2022
parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Friday, 3 June 2022 at 00:07:34 UTC, Adam D Ruppe wrote:

 All this is more realistically achieved with a minimal custom 
 druntime

 ...

 But failing that, the next best thing is a custom runtime.


I didn't know this was possible sans compiling a custom version 
of DMD yourself. Based on the way people talked about it I had 
assumed the only way to get rid of druntime was to use BetterC. 
Do you know of any resources on this topic?
Jun 02 2022
parent reply Adam Ruppe <destructionator gmail.com> writes:
On Friday, 3 June 2022 at 00:15:06 UTC, Jack Stouffer wrote:

 I didn't know this was possible sans compiling a custom version 
 of DMD yourself.


oh no, you just make a file called `object.d` and add it to your 
build and you'll override the normal druntime, and/or you can 
then just not link in the default one (`dmd -defaultlib= 
yourfile.d`). It is easiest to keep the default one around even 
if you don't link it in since some things will be auto-generated 
as needed.

I've written a little about this in the past: see my "D Cookbook" 
if you wanna buy one (though no-runtime D is a moving target and 
that is abit old now), or some of my blog posts:

http://dpldocs.info/this-week-in-d/Blog.Posted_2019_02_25.html#no-runtime-d
http://dpldocs.info/this-week-in-d/Blog.Posted_2020_07_27.html
http://dpldocs.info/this-week-in-d/Blog.Posted_2020_08_10.html#webassembly-in-d

There is a project called "lightweight D runtime" based on my 
webassembly code but retargeted to some arm devices, though the 
author had something come up in real life that derailed it. Some 
info here:
https://forum.dlang.org/post/zlnplbmdlcazkokccbxx forum.dlang.org


 Based on the way people talked about it I had assumed the only 
 way to get rid of druntime was to use BetterC.


This is part of why I hate betterC so much. It is a major 
distraction from better approaches to the point of both 
denigrating D itself and obscuring facts about real druntime.
Jun 02 2022
next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Friday, 3 June 2022 at 00:27:00 UTC, Adam Ruppe wrote:

 oh no, you just make a file called `object.d` and add it to 
 your build and you'll override the normal druntime, and/or you 
 can then just not link in the default one (`dmd -defaultlib= 
 yourfile.d`). It is easiest to keep the default one around even 
 if you don't link it in since some things will be 
 auto-generated as needed.

 I've written a little about this in the past: see my "D 
 Cookbook" if you wanna buy one (though no-runtime D is a moving 
 target and that is abit old now), or some of my blog posts:


This is fantastic. Thank you.

BTW, this is the description of defaultlib in the help page:

"-defaultlib=<name> set default library to name"
Jun 02 2022
parent Adam D Ruppe <destructionator gmail.com> writes:
On Friday, 3 June 2022 at 00:55:59 UTC, Jack Stouffer wrote:

 BTW, this is the description of defaultlib in the help page:

 "-defaultlib=<name> set default library to name"


Yeah, the trick is if you leave <name> blank, it sets the default 
library to none.
Jun 02 2022
prev sibling parent monkyyy <crazymonkyyy gmail.com> writes:
On Friday, 3 June 2022 at 00:27:00 UTC, Adam Ruppe wrote:

 oh no, you just make a file called `object.d` and add it to 
 your build and you'll override the normal runtime


anything fun you could do with that?
Jun 03 2022
prev sibling next sibling parent reply max haughton <maxhaton gmail.com> writes:
On Thursday, 2 June 2022 at 19:40:49 UTC, Jack Stouffer wrote:

 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.

 [...]


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.
Jun 02 2022
parent Jack Stouffer <jack jackstouffer.com> writes:
On Thursday, 2 June 2022 at 21:18:55 UTC, max haughton wrote:

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


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.


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


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.


 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.


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.
Jun 02 2022
prev sibling next sibling parent max haughton <maxhaton gmail.com> writes:
On Thursday, 2 June 2022 at 19:40:49 UTC, Jack Stouffer wrote:

 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.

 [...]


More practically we can probably find a way to spot failed links 
and hint that you should be using D.
Jun 02 2022
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/2/2022 12:40 PM, Jack Stouffer wrote:

 I really do hope BetterC continues to be worked on


I appreciate the time you took to post this, including the links. Yes, we'll 
continue to work on it! For reference, this link will produce all the open 
issues tagged with the keyword "betterC":

https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=betterC%2C%20&keywords_type=allwords&list_id=240903&query_format=advanced
Jun 03 2022
parent Jack Stouffer <jack jackstouffer.com> writes:
On Saturday, 4 June 2022 at 05:51:46 UTC, Walter Bright wrote:

 On 6/2/2022 12:40 PM, Jack Stouffer wrote:

 I really do hope BetterC continues to be worked on


 I appreciate the time you took to post this, including the links


Thanks for your movement on these. Got another one for you :)

https://issues.dlang.org/show_bug.cgi?id=23159
Jun 04 2022
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Thursday, 2 June 2022 at 19:40:49 UTC, Jack Stouffer wrote:

 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.


I have also used `-betterC` to some extent. Unfortunately I have 
to agree that you're mostly right.

IMO `-betterC` works somewhat well when you don't use Phobos 
much. But if you're using it to any significant extent it's far 
from working out of the box. I learned that one should copypaste 
and adapt stuff from Phobos and DRuntime when they don't work 
right away. `-i` to the standard library or `-allinst` might also 
help, have not tried them myself.

In principle all the ranges stuff that does not use the GC should 
work seamlessly with `-betterC` In practice the problem is that 
some of the `-betterC` features are implemented by simply not 
linking the Phobos binary in. Result is that the Phobos source 
files are processed as header files, but without anything to link 
to if anything precompilable is found in the files. It might be 
most practical to simply use the compiler switch to link the 
Phobos binary in with `-betterC`. On the other hand, I don't know 
how much this defeats the purpose of using `-betterC` in the 
first place.
Jun 04 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
You're right that -betterC means no use of Phobos.

On the other hand we'd definitely like to move in the direction of a "header 
only" D runtime library, which would resolve this.
Jun 04 2022
parent Jack Stouffer <jack jackstouffer.com> writes:
On Saturday, 4 June 2022 at 19:25:18 UTC, Walter Bright wrote:

 You're right that -betterC means no use of Phobos.


Personally I think that's fine, and probably even the situation 
you'd want to cultivate. Phobos can't be all things to all 
people. Especially since D is multi-paradigm, and those paradigms 
are mutually exclusive. Phobos necessarily needs to leave some 
people out in the cold.
Jun 04 2022