Michael S (already5chosen.delete@this.yahoo.com) on July 21, 2021 2:12 am wrote:
> Brett (ggtgp.delete@this.yahoo.com) on July 20, 2021 11:13 pm wrote:
> > Adrian (a.delete@this.acm.org) on July 20, 2021 12:00 pm wrote:
> > > Michael S (already5chosen.delete@this.yahoo.com) on July 20, 2021 10:14 am wrote:
> > > > Anon (no.delete@this.spam.com) on July 20, 2021 6:24 am wrote:
> > > > > gallier2 (gallier2.delete@this.gmx.de) on July 20, 2021 4:57 am wrote:
> > > > > > Looks like a good candidate for D.
> > > > > > https://tour.dlang.org/
> > > > >
> > > > > I like D, but this language don't have all the support for
> > > > > me to try it, the big boys usually prefer to create
> > > > > their own language instead of adopting one so we ended with many similar languages but incompatible.
> > > >
> > > > Isn't D GC-based, so unsuitable for kernel?
> > >
> > > No, the GC is optional and D can be used for an OS kernel without problems.
> > >
> > > Nevertheless, some parts of its standard library depend on the GC,
> > > so those parts are no longer available when the GC is not used.
> > >
> > > I like D much more than any other C replacement, because it is obvious that it was designed by people
> > > with experience in programming language implementation and it is uniformly better than C, unlike
> > > other alternatives that succeed to include some worse features besides the better features.
> > >
> > > Most such attempts of creating new programming languages
> > > include a few very useful and interesting new ideas
> > > in those languages, but then they combine them with other
> > > questionable programming language features, which have
> > > been proven to be inferior many decades ago, but the authors
> > > of those new programming languages do not seem to
> > > have any knowledge about the old programming languages or research papers that have shown better ways.
> >
> > You can lead a donkey to the fountain of knowledge, but you can’t make him drink.
> > The last major revision of Swift included the kitchen sink, including features that go against the
> > ethos of the language. Because stupid programers want to use stupid features and you have to support
> > everything to be successful. Don’t fight an ass, both of you will just end up unhappy.
> >
> > A Swift fanboy who did not get into this fight because all the alternatives are better than C++.
> >
> > And most of these languages are only different in a few wrappers around handling specific problems,
> > like better strings or better threading or better error handling, etc. add a library and you
> > can make them all look alike. Only C++ is too old and broken to fix, though they try. ;)
>
> All alternatives are better than C++ as long as you don't stretch it close to the edge.
> The edge of memory capacity, of speed, of access to non-common features of underlying OS... whatever.
> But when you do, then alternatives suddenly look less good.
> Of course, near the edge, "modern C++", with smart pointers, exceptions
> and overuse of RAII, does not look particularly good either.

In what way would using smart pointers, exceptins and RAII become overuse in C++? Overall though I do think it has reached the stage where one has to choose a sublanguage of C++ to have a workable system overal, and the whole business is becoming more and more baroque and unsafe. Code that needs more concepts than can be held in the mind at once will become a mess of creeping decay under maintenance. So the choice of basic concepts in a language has to be limited and very carefully chosen. Which is an argument for having one good person in overall control of a language rather than a committee.