On Wednesday, 17 November 2021 at 08:16:10 UTC, zjh wrote:

>

On Wednesday, 17 November 2021 at 07:54:26 UTC, SealabJaster

Therefore, it is necessary to provide capabilities similar to betterC + STD to compete with others.
Otherwise, more and more people will run to C/C++/Rust.

On Wednesday, 17 November 2021 at 08:21:09 UTC, Robert Schadek wrote:

>

Sounds to me like my argument for leadership.

I just checked out the dconf page again, and it seems the overview for Atila's talk has been added now.

https://dconf.org/2021/online/index.html

Seems to be in the right direction, although I'm wary trying to avoid breaking changes may be to our detriment in the long run (ironically).

On Wednesday, 17 November 2021 at 07:54:26 UTC, SealabJaster wrote:

>

On Wednesday, 17 November 2021 at 07:37:24 UTC, Elronnd wrote:

>

On Wednesday, 17 November 2021 at 07:25:46 UTC, Robert Schadek wrote:

>

Also you can not have string interpolation without dynamic memory.

Both of the string interpolation proposals were specifically designed to permit this.

And I believe this ties into his "Let's not aim for perfect" angle, which I agree with.

If anything, this thread simply shows yet again the extreme divide in D's userbase.

"Get rid of GC"
"Make GC optional"
"Fully embrace GC"

"Go after the C devs"
"Go after the higher level devs"

"I want to be able to write kernals in D"
"And I want to be able to do embedded stuff in D!"
"Well, I want to make games in D"
"Humph, I want to make Native applications in D"
"Jokes on you, I want to make a web server in D"
"pfft, I just want to make quick scripts and tools!"
[All the above are on differing levels of requirements regarding high-level and low-level features]

"Don't you dare touch Phobos with your GC trash"
"Pretty please actually put stuff into Phobos"

"Don't you dare add features to this language, just write a library"
"Pretty please add native sumtypes so it's actually possible to debug when things don't compile"

"Add string interpolation"
"but it has to also work with printf because Walter says so"
"also not like that since it needs to work in -betterC @nogc nothrow pure const shared"
"but it also needs to be easy to use because people from other languages expect things to just work"
"but that means we can't use @nogc which is a hard requirement for the GC-phobics"
"but but but"
"fuck it let's just scrap it so everyone loses out, just write mixin(interp!"") instead, nerds"

D - the language of endless bickering and lack of cohesive action.

Still absolutely love the language though, but we really need to get ourselves together at some point, because we're stuck in an endless loop of trying to be everything yet nothing.

this sums up the community really well. I would love if we would go forward with the plan proposed by Robert here really, though keeping the options to disable runtime and stuff like betterC.

Phobos should really be for the average D programmer, and if that can be -betterC @nogc nothrow pure const shared, great! But that shouldn't be the design goal IMO. When I use phobos, I want easy to use, flexible, readable code that doesn't make me do the wrong things - I want to save time using it. When I need -betterC @nogc code to make a kernel or program a micro-controller there are plenty of good utility libraries on DUB that nobody seems to be using - we should make that group of users especially use and publish more DUB libraries.

I think -betterC @nogc code is for rare use-cases (compared to 90% of other code you will write) - they exist and certainly are important, especially for building a good base for some of your other D code, but they are not what I want to use for all code.

Unstructured rambling section:

When I started using D I was especially drawn in by the great easy-to-use, flexible, batteries-included stdlib + package manager bundled with the language installation for all my other needs. Not a lot has been added to the stdlib since then, actually useful stuff like std.xml has been/will be removed due to it being not up to phobos' standards. Having too many dependencies quickly introduces issues, especially when the dependencies have more dependencies, worse even if they have different versions.

D really shined in making web servers with vibe.d - it was easy to transition from express.js. Vibe.d is still my go-to library for all my web services, but not a lot is really moving forward in this space, would love to push more here, especially with stuff like HTTP 2/3 that was promised with vibe-http, that halted for some reason though and I don't know how to improve on that really other than making my own vibe-http from scratch.

I'm also a big fan of GtkD, would love to see proper GTK 4 support going in though - I'm feeling unsafe using the gtk4 branch right now with the d_adw library on DUB that doesn't even have a README! Here too I think gtk4 is pretty usable, I don't know what's holding it up. Sure there are gonna be issues, but you can always fix those with later updates.

On Tuesday, 16 November 2021 at 22:46:24 UTC, bachmeier wrote:

>

I'm not sure about "GC only", but yes, D is only relevant if it has a GC. Going after the GC-free segment of the market is like releasing OpenBSD-only binaries. It's just too small to be worth the effort, especially with a well-funded competitor already in that space.

This is not true at all. Lots of people want a cleaned up C++, with C-like syntax. Without global GC.

C++ will never be productive for application level programming. I don't think Rust will either.

What is primarily holding D back is that the project is not run by sound software engineering practices. If you were a professional, would you put a tool in your foundation where the design and development practices are not better than your own practices? I would think not.

One reason that developers trust tools made by Google, Apple and Mozilla is that they assume that they use proven software development methods. Small projects have to prove that they do. If they don't they are off the table.

Restructuring the compiler, cleaning up the language and having zero regressions in releases is the first step to producing a tool that appeal to professional use.

Right now, D appeals to hobbyists, and that is ok. It is a nice hobby. Nothing wrong with that. And the big advantage of D primarily appealing to hobbyists is that the cost of breaking changes are small, if you don't do them all the time, but collect them and do them at once.

On Wednesday, 17 November 2021 at 09:54:31 UTC, WebFreak001 wrote:

>

On Wednesday, 17 November 2021 at 07:54:26 UTC, SealabJaster wrote:

>

[...]

this sums up the community really well. I would love if we would go forward with the plan proposed by Robert here really, though keeping the options to disable runtime and stuff like betterC.

[...]

I believe the GtkD author said that he disagrees philosophically over the direction Gtk 4 has taken so he won't be supporting it... dunno if he later changed his mind though.

On Tuesday, 16 November 2021 at 21:00:48 UTC, Robert Schadek wrote:

>

I imagine a DConf where you guys yell at me, not because we disagree,
but because I'm old and forgot my hearing aid.

Love the intro! :-D

>

And if we follow our own project planing, they might just follow along as well.

Just having a plan and showing how it correlates to progress is the first box to check in a risk assessment for a software project that considers using the language.

But you also need a stable branch and a good versioning scheme (no breaking changes between major releases).

>

Imagine, a compiler daemon that you start once per
project/program that keeps
track of all files related to this project.

Yes, what is needed is a highlevel IR that can be emitted. A formal spec of the compilation stages are needed too. It may require language adjustments. Speccing what the compiler does now will most likely not be what you want.

But it is totally worth it. It will improve the language semantics.

>

There GC is here to stay, you don't do manual memory management (MMM) in a
compiler daemon that tracks dependency.
I don't care how smart you are, you are not that smart.

I think "smart" is the wrong argument. We have to also think about costs. So plain MMM is costly, true. But global GC scanning does not work well.

Would you be ok with local GC scanning and RC for shared references?

>

ImportC must have a preprocessor, or it is DOA.

It also has to emulate common GCC extensions :-). Reference implementations follow ISO C11, other code often does not.

>

This was already partially discussed in the long term goals, but needs better
documentation or better yet a spec.
The cool thing is, we don't need to be an ISO spec aka. a pdf.
We could very well be a long .d file with lots of comments and unittests.

Well, a slow reference implementation that is validating input thoroughly is better than just documentation. But then you need to streamline the language semantics, otherwise the reference will be incomprehensible I think.

But the language would be better if it was done, so not a disadvantage. Some breakage would have to be expected.

I you design a high level IR, then you only need to emit that from the reference compiler.

>

The dart language people shall come to fear our binding generation
capabilities.

I don't think so. Dart supports live coding. You can modify it when the application is running. Anyway iOS/Android are moving targets. Too expensive to do well.

>

Being a bit dramatic, given people false hope, that gets disappointed, will
drive them away from D.

Not from D, but maybe from compiler development. But that is a big time investment. You cannot expect people to be willing to invest so much in an uncertain outcome.

>

A simple solution, IMO, is to take clear stance on issues.

Yes. Why invest time in extending the compiler if you don't know where D is heading or what is considered a good addition?

>

I see the DIP process troublesome as it gives the impression of say of what D
will become.

Yes. I think a reference compiler would be better. Then people can implement what they want and show that as a proof of concept. If it is interesting then it will gain momentum.

>

I'm serious about the motto at the top.
When people start complaining that their language is better, its free
marketing for D.

Ok, I don't think mottos matter much, maybe for the insiders it does, but for outsiders it can be seen as childish...

White papers and vision documents matter.

If you have a clear vision, then there is no need for a motto. It is self evident.

Kudos again, for taking the time to write a thoughtful and passionate post! Some changes are necessary, and they will only happen if people show their passion. So what yo do here is important, I think.

On Wednesday, 17 November 2021 at 12:54:10 UTC, Ola Fosheim Grøstad wrote:

>

Yes. I think a reference compiler would be better. Then people can implement what they want and show that as a proof of concept. If it is interesting then it will gain momentum.

An interesting aspect of using a reference implementation written for clarity instead of a spec is that if the proof of concept is good, then people can use the reference compiler. If enough people do that then that proof-of-concept feature will make it into the main compiler (or the main compiler will die off).

Never thought about that before, it is an interesting idea.

On Wednesday, 17 November 2021 at 11:01:41 UTC, Ola Fosheim Grøstad wrote:

>

On Tuesday, 16 November 2021 at 22:46:24 UTC, bachmeier wrote:

>

I'm not sure about "GC only", but yes, D is only relevant if it has a GC. Going after the GC-free segment of the market is like releasing OpenBSD-only binaries. It's just too small to be worth the effort, especially with a well-funded competitor already in that space.

This is not true at all. Lots of people want a cleaned up C++, with C-like syntax. Without global GC.

C++ will never be productive for application level programming. I don't think Rust will either.

What is primarily holding D back is that the project is not run by sound software engineering practices. If you were a professional, would you put a tool in your foundation where the design and development practices are not better than your own practices? I would think not.

One reason that developers trust tools made by Google, Apple and Mozilla is that they assume that they use proven software development methods. Small projects have to prove that they do. If they don't they are off the table.

Restructuring the compiler, cleaning up the language and having zero regressions in releases is the first step to producing a tool that appeal to professional use.

Right now, D appeals to hobbyists, and that is ok. It is a nice hobby. Nothing wrong with that. And the big advantage of D primarily appealing to hobbyists is that the cost of breaking changes are small, if you don't do them all the time, but collect them and do them at once.

Hobbyism is a nice way of putting it, and at this point, I think you're right. Project goals were last relevant about a decade ago.

I think the undesired outcome of D's place in the world comes down to the project management style that ultimately creeps in to the final product.

Basically it is the proof of how this style of pleasing everybody fails on limited manpower and influence. C++ can do it, D can not. Even when the principal author spent all his life in the gravitas of C++, does not mean there is reward for good behaviour. By that, I mean obviously the crowd-pleasing attitude (for the crowd you want, not the one you have). As mentioned somewhere, implementing new features on a whim goes against being community-led - it seems he would prefer people working for him instead of with him. Ironically, it becomes the exact opposite of pleasing everybody.

By the way, I haven't seen Walter engaging in these "future" conversations in a while. Maybe he's getting deja vu too? Forums look exactly the same as 5 years ago, debating the same things. Making them quite a sad place on the internet.

On Wednesday, 17 November 2021 at 13:27:16 UTC, maltedbarley97 wrote:

>

On Wednesday, 17 November 2021 at 11:01:41 UTC, Ola Fosheim Grøstad wrote:

>

On Tuesday, 16 November 2021 at 22:46:24 UTC, bachmeier wrote:

>

I'm not sure about "GC only", but yes, D is only relevant if it has a GC. Going after the GC-free segment of the market is like releasing OpenBSD-only binaries. It's just too small to be worth the effort, especially with a well-funded competitor already in that space.

This is not true at all. Lots of people want a cleaned up C++, with C-like syntax. Without global GC.

C++ will never be productive for application level programming. I don't think Rust will either.

What is primarily holding D back is that the project is not run by sound software engineering practices. If you were a professional, would you put a tool in your foundation where the design and development practices are not better than your own practices? I would think not.

One reason that developers trust tools made by Google, Apple and Mozilla is that they assume that they use proven software development methods. Small projects have to prove that they do. If they don't they are off the table.

Restructuring the compiler, cleaning up the language and having zero regressions in releases is the first step to producing a tool that appeal to professional use.

Right now, D appeals to hobbyists, and that is ok. It is a nice hobby. Nothing wrong with that. And the big advantage of D primarily appealing to hobbyists is that the cost of breaking changes are small, if you don't do them all the time, but collect them and do them at once.

Hobbyism is a nice way of putting it, and at this point, I think you're right. Project goals were last relevant about a decade ago.

I think the undesired outcome of D's place in the world comes down to the project management style that ultimately creeps in to the final product.

Basically it is the proof of how this style of pleasing everybody fails on limited manpower and influence. C++ can do it, D can not. Even when the principal author spent all his life in the gravitas of C++, does not mean there is reward for good behaviour. By that, I mean obviously the crowd-pleasing attitude (for the crowd you want, not the one you have). As mentioned somewhere, implementing new features on a whim goes against being community-led - it seems he would prefer people working for him instead of with him. Ironically, it becomes the exact opposite of pleasing everybody.

By the way, I haven't seen Walter engaging in these "future" conversations in a while. Maybe he's getting deja vu too? Forums look exactly the same as 5 years ago, debating the same things. Making them quite a sad place on the internet.

Stuff can get pretty negative down here, as well as other platforms(regrettably, I myself recently spat venom from my mouth in our Discord channel just a couple days ago...)

He recently came up with another idea that will help D gain traction: integrating a C compiler(parser, actually) directly into the front-end.

How much skepticism and criticism was thrown upon him(I'm not judging whether that was good or bad)?

He's trying, honest to god he's doing everything he thinks that can help, but its not working out :(

Plus, as you say, things are getting a little circular here(although there is serious action behind stdv2 now, so maybe a little bit of genuine progress is being made), so I don't blame him for thinking that its better to keep your head down and work rather than engage in fruitless discussion.

Plus Plus, I think he was interacting relatively recently in the refcounting thread, plus a discussion in ImportC as well, so its not as if he's completely absent from the forums

On Wednesday, 17 November 2021 at 13:51:09 UTC, Tejas wrote:

>

He recently came up with another idea that will help D gain traction: integrating a C compiler(parser, actually) directly into the front-end.

How much skepticism and criticism was thrown upon him(I'm not judging whether that was good or bad)?

Nothing wrong with integrating with C, it is interesting, but it has to happen in the right order. The compiler internals should be be cleaned up first. It is kinda like eating the desert before eating dinner. We are all guilty of that, I assume, but in a compiler the long term costs are higher than usual.

So the vision was ok, but the software engineering part of it is questionable.