I have an idea. Due to the abundance of D capabilities, I propose to introduce the concept of D profiles to the community. In D, you can write firmware for a microcontroller, an OS, a web server, scripts, a vst plugin, and a compiler. All these niches have different requirements from the programming language. We already have a betterC mode, but what if we introduce a more understandable gradation? Well-defined subsets, let's say. We call these subsets profiles. With these profiles you can better search for the required packages in dub. Let's say I have a system profile, and it will be possible to filter all packages by this request. A system profile may have requirements not only for the absence of GC, but also for the API in general, for example, to be closer to a low level. Or I have a script profile, I can use both system and script profiles. This will also allow language developers to see the weaknesses of specific profiles and introduce features for them. You can build std like a pyramid, with a system profile at the bottom, and a managment profile based on it, for example.

Here is the list of profiles I suggest:

CompileTime profile. This profile is the most universal, since it does not affect runtime in any way.

System profile. This profile uses a DOD (data oriented design) approach. Minimum classes, delegates. Error handling via values. Data is not live, scope(exit) instead of destructors. Using std.sumtype. If it is a library, full dip1000 support. If it is a library, std.experimental.allocators are fully supported. Can call gc code at higher levels, so the nogc attribute is not required. The code will have a lot of boilerplate around memory management and error handling, just like in C or Zig.

Application profile. Classes and interfaces are already available in this profile. Structures have raii. Garbage collector is fully accessible. Processing through exceptions is possible. Support for OOP and FP paradigms. There may be some kind of runtime reflection. Totally @safe.

Script profile. It mainly differs in its API in the libraries. It should be simple and flexible. This can be used as 50 line scripts for image processing, parsing, data analysis, conversion. Maybe it’s a library that parses a binary file based on UDA (like imhex patterns). This could be a library for prototyping something. Data visualization, plotting, etc. That is, what Python is used for. Perhaps the compiler will need support for parsing a module simply as a main function. Perhaps a selective level of optimization is needed (O2 dependencies, O0 script). You need a fast linker, or the ability of a compiler to link the code in jit and execute it right here.

What do you think? Should we split D into 3 languages ​​with a common ffi?

On Saturday, 20 July 2024 at 23:29:57 UTC, Mensikov wrote:

I like the idea of targeting specific audiences and having the language just work for them. I think right now the biggest potential draw to D is from C developers migrating because people all of the sudden decided C was not safe. I think we can just target those groups specifically. I would imagine it is mostly hardware interfacing.

The other group we have are companies that sponsor D who write applications.

Another group would be people making games.

Lastly, you have new people.

I think if it becomes more popular with the first three groups, the last group would come on their own. I think having a profile set up that will support whatever the government is requiring from languages and easy porting from C would be smart.

On Saturday, 20 July 2024 at 23:29:57 UTC, Mensikov wrote:

Im pretty sure betterc doesnt exist as a well designed subset, its a collection of hacks

On Saturday, 20 July 2024 at 23:29:57 UTC, Mensikov wrote:

Not agreed

And I am absolutely convinced of opposite: there is no difference between developing for a desktop, mobile, MCU or some sort of "supercomputer"

Therefore, it makes sense to strive for universality and commonty of code

On Saturday, 20 July 2024 at 23:29:57 UTC, Mensikov wrote:

The restricted D subsets aren't fun. Adam and Hipreme (and Spasm?) have shown how you can be better off with a custom D runtime instead.

On Saturday, 20 July 2024 at 23:29:57 UTC, Mensikov wrote:

You're better off looking at D as a complete language and use it as is rather than a language that'll suddenly switch to some cool model. Versions of D isn't going to be significantly different. It just doesn't make sense. I don't see why current D can't do any of the above.

You can write every type of code in current D or use a custom runtime as mentioned above.