"Carbon, a new programming language from Google, aims to be C++ successor"

[Cholo Lennon]

Carbon, the latest programming language to be built within Google, was
unveiled today as an experimental successor to C++...

https://9to5google.com/2022/07/19/carbon-programming-language-google-cpp/

[Mut...@dastardlyhq.com]

IOW they've realised no one outside Google gives a damn about Go so they're
trying again. The only language that has a chance of replacing C is Rust but
apparently its object model is a bit limited so no idea if it could replace C++
yet.

[Juha Nieminen]

So what's the count for the number of "better than C++, to replace it"
languages now?

I have lost the count a couple of decades ago.

(To be fair, a couple of those "better than C++" languages have become
successful on their own right. They have still failed to replace C++,
though. Maybe the hundreth time is the charm?)

[Cholo Lennon]

I thought the same, that Rust could be the replacement for C/C++. I like
Rust, but I am not an expert on it to have a strong opinion, especially
about the integration with C/C++. Here the explanation "why not Rust"
from them:

https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/faq.md#why-not-rust

--
Cholo Lennon
Bs.As.
ARG

[Cholo Lennon]

Totally agree. A lot of "new" programming languages have advertised
themselves as a C++ successor/replacement, but all of them failed to
accomplish that goal.

My concern is that research efforts, and the community of developers,
are split, again, due to another new "promising" language.

[Malcolm McLean]

On Wednesday, 20 July 2022 at 20:38:26 UTC+1, Cholo Lennon wrote:
> On 7/20/22 5:29 AM, Mut...@dastardlyhq.com wrote:
> > On Tue, 19 Jul 2022 23:08:04 -0300
> > Cholo Lennon <cholo...@hotmail.com> wrote:
> >> Carbon, the latest programming language to be built within Google, was
> >> unveiled today as an experimental successor to C++...
> >>
> >> https://9to5google.com/2022/07/19/carbon-programming-language-google-cpp/
> >
> > IOW they've realised no one outside Google gives a damn about Go so they're
> > trying again. The only language that has a chance of replacing C is Rust but
> > apparently its object model is a bit limited so no idea if it could replace C++
> > yet.
> >
> I thought the same, that Rust could be the replacement for C/C++. I like
> Rust, but I am not an expert on it to have a strong opinion, especially
> about the integration with C/C++. Here the explanation "why not Rust"
> from them:
>

What would be telling is if language designers promised "a new Rust" rather
than "a new C++".

[Chris M. Thomasson]

Fwiw, I was playing around with Unity that uses C# as a main means to
develop games. However, they sure do have a rather robust C binding into
their render logic and explain that they did it in order to be able to
exploit the efficiency of C wrt performance critical code.

[Cholo Lennon]

Well, given the Carbon syntax is closer to Rust than C++, yes, for sure
it is a better motto for the language.

[Chris Vine]

On Wed, 20 Jul 2022 18:49:54 -0300

Cholo Lennon <cholo...@hotmail.com> wrote:
> On 7/20/22 18:38, Malcolm McLean wrote:
> > On Wednesday, 20 July 2022 at 20:38:26 UTC+1, Cholo Lennon wrote:
> >> On 7/20/22 5:29 AM, Mut...@dastardlyhq.com wrote:
> >>> On Tue, 19 Jul 2022 23:08:04 -0300
> >>> Cholo Lennon <cholo...@hotmail.com> wrote:
> >>>> Carbon, the latest programming language to be built within Google, was
> >>>> unveiled today as an experimental successor to C++...
> >>>>
> >>>> https://9to5google.com/2022/07/19/carbon-programming-language-google-cpp/
> >>>
> >>> IOW they've realised no one outside Google gives a damn about Go so they're
> >>> trying again. The only language that has a chance of replacing C is Rust but
> >>> apparently its object model is a bit limited so no idea if it could replace C++
> >>> yet.
> >>>
> >> I thought the same, that Rust could be the replacement for C/C++. I like
> >> Rust, but I am not an expert on it to have a strong opinion, especially
> >> about the integration with C/C++. Here the explanation "why not Rust"
> >> from them:
> >>
> > What would be telling is if language designers promised "a new Rust" rather
> > than "a new C++".
>
> Well, given the Carbon syntax is closer to Rust than C++, yes, for sure
> it is a better motto for the language.

You may have a better reading of the documentation and knowledge of
carbon than me, but my reading of it is that that motto would be
incorrect. From what I have read, carbon is designed for easy C++
interoperability via its FFI. Rust is not.

The carbon FAQ explicitly claims it is not "a new Rust". The FAQ says
"In fact, if you can use Rust or any other established programming
language, you should. Carbon is for organizations and projects that
heavily depend on C++; for example, projects that have a lot of C++
code or use many third-party C++ libraries."

Those with agendas or personal attachments on this newsgroup will have
their agendas or personal attachments. My guess, and it is no more than
that, is that over the next 20 years Rust will eat C++'s lunch and that
Carbon, which really does set out to be a "better C++", will not. But
it is a guess.

[Cholo Lennon]

No, I have just learned about Carbon yesterday.

> but my reading of it is that that motto would be
> incorrect. From what I have read, carbon is designed for easy C++
> interoperability via its FFI. Rust is not.
>
> The carbon FAQ explicitly claims it is not "a new Rust". The FAQ says
> "In fact, if you can use Rust or any other established programming
> language, you should. Carbon is for organizations and projects that
> heavily depend on C++; for example, projects that have a lot of C++
> code or use many third-party C++ libraries."

Yes, for sure, you're right, according to that FAQs it is not a new Rust
(I just associated Carbon to Rust because of the syntax. As a C++
successor I would like a syntax closer to it instead of Rust)

>
> Those with agendas or personal attachments on this newsgroup will have
> their agendas or personal attachments. My guess, and it is no more than
> that, is that over the next 20 years Rust will eat C++'s lunch and that
> Carbon, which really does set out to be a "better C++", will not. But
> it is a guess.
>

[Manfred]

One major problem I see with all those wannabe C++ successor is that C++
has built a foundation that is several decades long, which counts for
reliability and stability of the language (until the committee will
manage to ruin this by keeping on doing what they are doing as of late)
These qualities are very valuable in projects and organizations where
product quality matters.

In order to gain a comparable level of recognition, a successor of C++
would have to be building a similar foundation, and die along the way.

[Chris Vine]

On Thu, 21 Jul 2022 01:29:08 +0200
Manfred <non...@add.invalid> wrote:
> One major problem I see with all those wannabe C++ successor is that C++
> has built a foundation that is several decades long, which counts for
> reliability and stability of the language (until the committee will
> manage to ruin this by keeping on doing what they are doing as of late)
> These qualities are very valuable in projects and organizations where
> product quality matters.
>
> In order to gain a comparable level of recognition, a successor of C++
> would have to be building a similar foundation, and die along the way.

Indeed, as Keynes said "In the long run we are all dead". No one knows
what language people (if they then exist) will be programming in in 100
years time.

I don't know how "official" Carbon is at Google. Despite Google's
forays into things like Go, its codebase is heavily invested in C++.
The thing I take from this is that there is some level of organisation
within that company that is dissatisfied with C++'s evolution. Whether
this is a transient phenomenen, some cry for solace, or something more
long lasting remains to be seen.

[David Brown]

On 21/07/2022 02:06, Chris Vine wrote:
> On Thu, 21 Jul 2022 01:29:08 +0200
> Manfred <non...@add.invalid> wrote:
>> One major problem I see with all those wannabe C++ successor is that C++
>> has built a foundation that is several decades long, which counts for
>> reliability and stability of the language (until the committee will
>> manage to ruin this by keeping on doing what they are doing as of late)
>> These qualities are very valuable in projects and organizations where
>> product quality matters.
>>
>> In order to gain a comparable level of recognition, a successor of C++
>> would have to be building a similar foundation, and die along the way.
>
> Indeed, as Keynes said "In the long run we are all dead". No one knows
> what language people (if they then exist) will be programming in in 100
> years time.
>

We know some of it. We'll still have C, Cobol, and a bit of Fortran :-)

> I don't know how "official" Carbon is at Google. Despite Google's
> forays into things like Go, its codebase is heavily invested in C++.

These sorts of things are "bluesky" research for Google. They are
willing to finance them in the hope that they pay off, but they won't
bet the company on them.

> The thing I take from this is that there is some level of organisation
> within that company that is dissatisfied with C++'s evolution. Whether
> this is a transient phenomenen, some cry for solace, or something more
> long lasting remains to be seen.

They are not the first developers to realise that C++ is not perfect!

[Mut...@dastardlyhq.com]

On Thu, 21 Jul 2022 16:01:54 +0200
David Brown <david...@hesbynett.no> wrote:
>On 21/07/2022 02:06, Chris Vine wrote:
>> On Thu, 21 Jul 2022 01:29:08 +0200
>> Manfred <non...@add.invalid> wrote:
>>> One major problem I see with all those wannabe C++ successor is that C++
>>> has built a foundation that is several decades long, which counts for
>>> reliability and stability of the language (until the committee will
>>> manage to ruin this by keeping on doing what they are doing as of late)
>>> These qualities are very valuable in projects and organizations where
>>> product quality matters.
>>>
>>> In order to gain a comparable level of recognition, a successor of C++
>>> would have to be building a similar foundation, and die along the way.
>>
>> Indeed, as Keynes said "In the long run we are all dead". No one knows
>> what language people (if they then exist) will be programming in in 100
>> years time.
>>
>
>We know some of it. We'll still have C, Cobol, and a bit of Fortran :-)

It'll depend heavily on how hardware evolves and I suspect the hardware
that exists in 100 years will bear little to no resemblence to what we
have now either in physical construction or logical operation. Perhaps it'll
be quantum, perhaps it'll be something that hasn't even been thought of yet.

>> The thing I take from this is that there is some level of organisation
>> within that company that is dissatisfied with C++'s evolution. Whether
>> this is a transient phenomenen, some cry for solace, or something more
>> long lasting remains to be seen.
>
>They are not the first developers to realise that C++ is not perfect!

https://pmac-agpc.ca/project-management-tree-swing-story

Number 12 is how C++ started out, Number 6 is what C++ should be, Number 3 is
what the steering committee have created in the last 10 years.

[gdo...@gmail.com]

great name for a language.

[David Brown]

On 21/07/2022 17:01, Mut...@dastardlyhq.com wrote:
> On Thu, 21 Jul 2022 16:01:54 +0200
> David Brown <david...@hesbynett.no> wrote:
>> On 21/07/2022 02:06, Chris Vine wrote:
>>> On Thu, 21 Jul 2022 01:29:08 +0200
>>> Manfred <non...@add.invalid> wrote:
>>>> One major problem I see with all those wannabe C++ successor is that C++
>>>> has built a foundation that is several decades long, which counts for
>>>> reliability and stability of the language (until the committee will
>>>> manage to ruin this by keeping on doing what they are doing as of late)
>>>> These qualities are very valuable in projects and organizations where
>>>> product quality matters.
>>>>
>>>> In order to gain a comparable level of recognition, a successor of C++
>>>> would have to be building a similar foundation, and die along the way.
>>>
>>> Indeed, as Keynes said "In the long run we are all dead". No one knows
>>> what language people (if they then exist) will be programming in in 100
>>> years time.
>>>
>>
>> We know some of it. We'll still have C, Cobol, and a bit of Fortran :-)
>
> It'll depend heavily on how hardware evolves and I suspect the hardware
> that exists in 100 years will bear little to no resemblence to what we
> have now either in physical construction or logical operation. Perhaps it'll
> be quantum, perhaps it'll be something that hasn't even been thought of yet.
>

C, Cobol and Fortran have been around for 50 years or more, and are all
still in serious use. Other languages come and go - and some have come,
but haven't gone yet (like C++). So the best guess we have as to the
languages of the future, is these apparently ever-lasting languages. (I
don't claim they will be the /only/ languages, or even the most popular
ones - just that they'll still be around and in use.)

Quantum computers are an expensive excuse to play with cool toys. I
think it is unlikely that they will ever actually be cost-effective for
solving real-world problems (as distinct from completely artificial ones
invented just to suit quantum computers). They /might/ turn out to be
helpful for certain specific optimisation problems. But for "everyday"
computing, they haven't a chance, and never will do.

(Feel free to contact me in a hundred years if I turn out to be wrong!)

[Chris M. Thomasson]

On 7/21/2022 8:01 AM, Mut...@dastardlyhq.com wrote:
> On Thu, 21 Jul 2022 16:01:54 +0200
> David Brown <david...@hesbynett.no> wrote:
>> On 21/07/2022 02:06, Chris Vine wrote:
>>> On Thu, 21 Jul 2022 01:29:08 +0200
>>> Manfred <non...@add.invalid> wrote:
>>>> One major problem I see with all those wannabe C++ successor is that C++
>>>> has built a foundation that is several decades long, which counts for
>>>> reliability and stability of the language (until the committee will
>>>> manage to ruin this by keeping on doing what they are doing as of late)
>>>> These qualities are very valuable in projects and organizations where
>>>> product quality matters.
>>>>
>>>> In order to gain a comparable level of recognition, a successor of C++
>>>> would have to be building a similar foundation, and die along the way.
>>>
>>> Indeed, as Keynes said "In the long run we are all dead". No one knows
>>> what language people (if they then exist) will be programming in in 100
>>> years time.
>>>
>>
>> We know some of it. We'll still have C, Cobol, and a bit of Fortran :-)
>
> It'll depend heavily on how hardware evolves and I suspect the hardware
> that exists in 100 years will bear little to no resemblence to what we
> have now either in physical construction or logical operation. Perhaps it'll
> be quantum, perhaps it'll be something that hasn't even been thought of yet.

[...]

Wrt quantum... Check this out, Q#:

https://en.wikipedia.org/wiki/Q_Sharp

;^)

[gdo...@gmail.com]

> Quantum computers are an expensive excuse to play with cool toys. I
> think it is unlikely that they will ever actually be cost-effective for
> solving real-world problems (as distinct from completely artificial ones
> invented just to suit quantum computers). They /might/ turn out to be
> helpful for certain specific optimisation problems. But for "everyday"
> computing, they haven't a chance, and never will do.
>
> (Feel free to contact me in a hundred years if I turn out to be wrong!)

it's a date. lol, 2122, July 21.
we will be wearing quantum watches synced to our quantum eye glasses and contact lenses.
😂
we will never forget another face or fact. it will always appear before us. cool right.

[Chris M. Thomasson]

LOL! Internet on demand. The mere act of a thought will flood the brain
with search results... ;^)

[Michael S]

Sound like they don't have and don't plan to have BDFL.
Which mean mediocrity at best and irrelevance at worst.
Luckily, with google's weight behind them, worst case is not very likely,

[Juha Nieminen]

gdo...@gmail.com <gdo...@gmail.com> wrote:
> great name for a language.

I have my jokular hypothesis for why they named like that: So that
google searches for "google carbon footprint" would bring results
about the language rather than Google's emissions.

[Juha Nieminen]

David Brown <david...@hesbynett.no> wrote:
> C, Cobol and Fortran have been around for 50 years or more, and are all
> still in serious use.

I have never heard of Cobol and Fortran being still in serious use.
Even if they are, they must be a minuscule minority.

In contrast, C is rather obviously in very active use, especially in the
embedded world. And no doubt helped by the fact that the Linux kernel is
written pretty much entirely in C.


(I must admit: For the longest time I was slightly averse to the idea
of something like the Linux kernel adhering so strictly to C. However,
having actually had some experience on the Linux kernel in particular,
and low-level embedded programming in general, I have kind of warmed
up to the idea a bit. Not that I have become a rabid defender of C in
this context, taking my opinion to the grave (like a certain kernel
author), but I am perhaps not so averse anymore to the concept of the
kernel being written in C and remaining so. I don't consider it *so*
bad of an idea anymore, as I did eg. a decade ago. I have seen the
advantages and I'm not completely unappreciative of them.)

[Bonita Montero]

Wake me up when this language is at least so popular that is
has a Wikipedia article.

[Christian Gollwitzer]

Am 22.07.22 um 09:03 schrieb Juha Nieminen:

> David Brown <david...@hesbynett.no> wrote:
>> C, Cobol and Fortran have been around for 50 years or more, and are all
>> still in serious use.
>
> I have never heard of Cobol and Fortran being still in serious use.
> Even if they are, they must be a minuscule minority.

This is a strange thing to say. Maybe you should decribe your definition
of "serious use". Cobol still runs many financial transactions and
Fortran is used in high performance numerical computing. Granted, these
things are legacy and most people would be glad to get rid of them, but
it is very hard, especially if you have code that was tested for decades
and is now considered bug-free which runs critical infrastructure.

But there is a reason that compilers for these languages are still being
actively developed and sold[1-3].

Christian

[1] visual cobol:
https://www.microfocus.com/en-us/products/visual-cobol/overview
[2] ifort:
https://www.intel.com/content/www/us/en/developer/tools/oneapi/fortran-compiler.html
[3] gcobol: https://gcc.gnu.org/pipermail/gcc/2022-March/238408.html

[David Brown]

To be on the safe side, they should call the standard library for Carbon
"Footprint" :-)

[Malcolm McLean]

On Friday, 22 July 2022 at 08:45:14 UTC+1, Christian Gollwitzer wrote:
> Am 22.07.22 um 09:03 schrieb Juha Nieminen:
> > David Brown <david...@hesbynett.no> wrote:
> >> C, Cobol and Fortran have been around for 50 years or more, and are all
> >> still in serious use.
> >
> > I have never heard of Cobol and Fortran being still in serious use.
> > Even if they are, they must be a minuscule minority.
> This is a strange thing to say. Maybe you should decribe your definition
> of "serious use". Cobol still runs many financial transactions and
> Fortran is used in high performance numerical computing.
>

Remember that not everyone is a native English speaker.
"Serious" is one of those words which can be used in different ways.
"High seriousness", "a seriously fluffy kitten".

I'd understand "serious use" to be "not use in a hobby or educational
context, not use to demonstrate the capabilities of the language itself,
probably a use involving significant sums of money or, failing this,
important in some other way, such as for safety or science".
So a legacy Cobol system processing millions of dollars is clearly
"serious use", even thouhg the code might be quite simple and small.

[Mut...@dastardlyhq.com]

On Thu, 21 Jul 2022 18:52:57 +0200
David Brown <david...@hesbynett.no> wrote:

>On 21/07/2022 17:01, Mut...@dastardlyhq.com wrote:
>> It'll depend heavily on how hardware evolves and I suspect the hardware
>> that exists in 100 years will bear little to no resemblence to what we
>> have now either in physical construction or logical operation. Perhaps it'll
>> be quantum, perhaps it'll be something that hasn't even been thought of yet.
>>
>
>C, Cobol and Fortran have been around for 50 years or more, and are all
>still in serious use. Other languages come and go - and some have come,

When serious change happens it happens fast. The flip from analogue to digital
computers happened in the space of a few years. Ditto steam to diesel on the
railways. The von neumann architecture might be the dominant hardware design
today but I'd lay good money on it being a historic curiousity in 100 years.

>Quantum computers are an expensive excuse to play with cool toys. I

Right now yes. A lot can happen in a century.

>invented just to suit quantum computers). They /might/ turn out to be
>helpful for certain specific optimisation problems. But for "everyday"
>computing, they haven't a chance, and never will do.

I'm sure history is littered with people who said the same thing about cutting
edge tech that had no immediate advantage over the current state of the art.
Fixed wing aircraft vs airships springs to mind.

>(Feel free to contact me in a hundred years if I turn out to be wrong!)

We'll both be long dead then so no chance of either of us to say "I told you
so" :)

[Mut...@dastardlyhq.com]

Looks like something for post grads rather than something for serious use
right now.

Anyway, no doubt the C++ steering committee will soon run out of spurious
extra syntax and pointless semantics to add to the language and will probably
think about adding an entire quantum subsection for c++ 203X in order to
continue justifying their existence.

[Mut...@dastardlyhq.com]

On Fri, 22 Jul 2022 01:20:23 -0700 (PDT)
Malcolm McLean <malcolm.ar...@gmail.com> wrote:
>even thouhg the code might be quite simple and small.

Not a chance!

[Christian Gollwitzer]

Am 22.07.22 um 10:20 schrieb Malcolm McLean:

This is also how I understood it (not being a native English speaker
myself). But maybe Juha was thinking about something different: a lot of
this code is out and running, and it is being maintained, but if someone
were to write it from scratch, then they would choose a different
language. Even then they might choose Fortran, which got updated with
recent standards etc., but I highly doubt that anyone in their right
mind would choose Cobol.

So "serious use" could be debatable if it means "programming in Cobol"
as opposed to "running some legacy stuff in Cobol". Hence, my question
about Juha's understanding of "serious use".

Christian

[Malcolm McLean]

On Friday, 22 July 2022 at 09:39:42 UTC+1, Christian Gollwitzer wrote:
> Am 22.07.22 um 10:20 schrieb Malcolm McLean:
> > On Friday, 22 July 2022 at 08:45:14 UTC+1, Christian Gollwitzer wrote:
> >> Am 22.07.22 um 09:03 schrieb Juha Nieminen:
> >>> David Brown <david...@hesbynett.no> wrote:
> >>>> C, Cobol and Fortran have been around for 50 years or more, and are all
> >>>> still in serious use.
> >>>
> >>> I have never heard of Cobol and Fortran being still in serious use.
> >>> Even if they are, they must be a minuscule minority.
> >> This is a strange thing to say. Maybe you should decribe your definition
> >> of "serious use". Cobol still runs many financial transactions and
> >> Fortran is used in high performance numerical computing.
> >>
> > Remember that not everyone is a native English speaker.
> > "Serious" is one of those words which can be used in different ways.
> > "High seriousness", "a seriously fluffy kitten".
> >
> > I'd understand "serious use" to be "not use in a hobby or educational
> > context, not use to demonstrate the capabilities of the language itself,
> > probably a use involving significant sums of money or, failing this,
> > important in some other way, such as for safety or science".
> > So a legacy Cobol system processing millions of dollars is clearly
> > "serious use", even thouhg the code might be quite simple and small.
> >
> This is also how I understood it (not being a native English speaker
> myself).

"Serious" is used in a slightly slang way to mean "of large quantity" as
well as in its canonical meaning of "not jocular or unimportant".

[Juha Nieminen]

Christian Gollwitzer <auri...@gmx.de> wrote:
> Am 22.07.22 um 09:03 schrieb Juha Nieminen:
>> David Brown <david...@hesbynett.no> wrote:
>>> C, Cobol and Fortran have been around for 50 years or more, and are all
>>> still in serious use.
>>
>> I have never heard of Cobol and Fortran being still in serious use.
>> Even if they are, they must be a minuscule minority.
>
> This is a strange thing to say. Maybe you should decribe your definition
> of "serious use".

Or more like a definition of "use". There's a difference between "programs
written in Cobol are still in use" and "new programs are being written
using Cobol" (and by "new" I don't mean programs that are written in
that language for legacy reasons because they need to use existing
libraries or codebases written in Cobol. "New" as in starting from a
clean slate, without using existing legacy code.)

The latter is certainly true for C.

But even if it's true also for Cobol and Fortran, I would guess it's not
extraordinarily common overall.

[Michael S]

Current announcement is mostly for people that would like to participate in
definition of the language and to help reference implementation.
They openly admit that it will take several years until Carbon becomes viable for end users.

[Michael S]

I am not sure about Fortran.
Julia was supposed to be a hair apparent. But it's popularity grows too
slowly. If it still grows.
I'd guess that main reason for that is python+numpy+scipy, which is not
good enough solution to replace Fortran completely, but is good enough
take wind out of Julia's sails.

[Scott Lurndal]

Juha Nieminen <nos...@thanks.invalid> writes:
>David Brown <david...@hesbynett.no> wrote:
>> C, Cobol and Fortran have been around for 50 years or more, and are all
>> still in serious use.
>
>I have never heard of Cobol and Fortran being still in serious use.
>Even if they are, they must be a minuscule minority.

"COBOL is still very popular today in 2021. Depending on the
source you're looking at, there are still between 200 and 250
billion lines of COBOL code in production. Many large corporations,
70% in fact, still rely on COBOL for much of their mission critical work."

[Juha Nieminen]

Not "programs written in COBOL in use", but *the language itself*, as in
actually being used to write new programs.

[Bo Persson]

If you are one of those corporations having 10s of millions of lines of
Cobol, what language would you use to write the next million lines?

I recently worked for a bank, where 100s of developers wrote Cobol code
all day.

Sure, the phone apps are written in Java, but they have to "call home"
to the mainframe, where *newly written* Cobol code collects the info
from the database.


This use of Cobol is strictly inhouse, so doesn't show up on TIOBE. As a
matter of fact, we were **explicitly** told not to post any of the code
on StackOverflow or Reddit! Questions on inhouse code is supposed to be
handled inhouse. :-)

[Bonita Montero]

Am 20.07.2022 um 04:08 schrieb Cholo Lennon:
> Carbon, the latest programming language to be built within Google, was
> unveiled today as an experimental successor to C++...
>
> https://9to5google.com/2022/07/19/carbon-programming-language-google-cpp/

I don't know why such a language should be necessary. I don't have
notworthy issues with writing C++-code, even with C++20. But of course
such a language is easier to learn, but once you've get fluent with C++
there's no difference when the features are mostly the same.

[Bo Persson]

The Carbon github page lists some of their reasons to create a new
languagage:

Welcoming open-source community

- Clear goals and priorities with robust governance
- Community that works to be welcoming, inclusive, and friendly
- Batteries-included approach: compiler, libraries, docs, tools,
package manager, and more


Apparently those are things believed to be missing for C++.

[Michael S]

Useful features are, may be, the same. Or will become the same if C++
"constraints and concepts" end up working, which is not given.

But C++ is full of harmful features that are invariably used by any
team of more than two C++ programmers that does not have very strong
and not too benevolent dictator.

[Juha Nieminen]

Bo Persson <b...@bo-persson.se> wrote:
> - Community that works to be welcoming, inclusive, and friendly

Especially "inclusive" is a warning flag, because in modern political
vocabulary it means pretty much the exact opposite.

[Cholo Lennon]

On 7/19/22 11:08 PM, Cholo Lennon wrote:
> Carbon, the latest programming language to be built within Google, was
> unveiled today as an experimental successor to C++...
>
> https://9to5google.com/2022/07/19/carbon-programming-language-google-cpp/

Bjarne Stroustrup's opinion about Carbon:

https://devclass.com/2022/07/25/c-inventor-stroustrup-says-googles-carbon-too-new-and-under-specified-for-meaningful-technical-comment/

--
Cholo Lennon
Bs.As.
ARG

[gdo...@gmail.com]

every language where count begins at zero be fixed.
puppy 0
puppy 1
puppy 2
...
please. this lends itself to off by one all over the place. pointers of yesterday to think of just one. lol, lol, lol

i mean 0. lol

[Andreas Kempe]

The batteries-included part seems like something that is very much
today's flavour. You want a compiler that enforces a project
structure, handles fetching dependencies for you (Go can include
Github repositories directly in source if I'm not mistaken), lints
your code, generates documentation etc.

To some extent, it feels like these new programming languages are more
of an ecosystem that you need to buy into and do everything their way
rather than being a compiler and a grammar turning your scribbles into
machine code.

An example to compare with C++ is the problem of choosing your build
system. Do you use Scons, CMake, Automake, GNU Make, BSD Make, etc?
Freedom is nice, but I can understand why someone wouldn't want to put
energy into choosing a build system.

I don't really know how to feel about this. Maybe providing one true
way of organising your build system, managing dependencies etc.
dictated by the language is the way of the future?

[Chris M. Thomasson]

On 8/11/2022 10:38 AM, Andreas Kempe wrote:
> Den 2022-07-24 skrev Bo Persson <b...@bo-persson.se>:
>> On 2022-07-24 at 19:36, Bonita Montero wrote:
>>> Am 20.07.2022 um 04:08 schrieb Cholo Lennon:
>>>> Carbon, the latest programming language to be built within Google, was
>>>> unveiled today as an experimental successor to C++...
>>>>
>>>> https://9to5google.com/2022/07/19/carbon-programming-language-google-cpp/
>>>
>>> I don't know why such a language should be necessary. I don't have
>>> notworthy issues with writing C++-code, even with C++20. But of course
>>> such a language is easier to learn, but once you've get fluent with C++
>>> there's no difference when the features are mostly the same.
>>
>> The Carbon github page lists some of their reasons to create a new
>> languagage:
>>
>> Welcoming open-source community
>>
>> - Clear goals and priorities with robust governance
>> - Community that works to be welcoming, inclusive, and friendly
>> - Batteries-included approach: compiler, libraries, docs, tools,
>> package manager, and more
>>
>>
>> Apparently those are things believed to be missing for C++.
>>
>>
>
> The batteries-included part seems like something that is very much
> today's flavour. You want a compiler that enforces a project
> structure, handles fetching dependencies for you (Go can include
> Github repositories directly in source if I'm not mistaken), lints
> your code, generates documentation etc.

Fwiw, check this out:

https://vcpkg.io/en/index.html

;^)

[...]

[Paavo Helde]

11.08.2022 20:38 Andreas Kempe kirjutas:
> An example to compare with C++ is the problem of choosing your build
> system. Do you use Scons, CMake, Automake, GNU Make, BSD Make, etc?
> Freedom is nice, but I can understand why someone wouldn't want to put
> energy into choosing a build system.
>
> I don't really know how to feel about this. Maybe providing one true
> way of organising your build system, managing dependencies etc.
> dictated by the language is the way of the future?

There is an xkcd about this: https://xkcd.com/927

[Andreas Kempe]

I haven't used Windows in a good while now so I don't know how one
usually handles libraries on the Windows platform, but a package
manager that allows you to install library dependencies that can be
included using standard CMake syntax seems like a good idea if Windows
doesn't have its own package manager.

Unless you follow their advice of using the package manager as a Git
submodule and also decide to make it an integral part of the
compilation process, you should still be able to compile it
"normally".

[Bo Persson]

On 2022-08-11 at 19:38, Andreas Kempe wrote:
> Den 2022-07-24 skrev Bo Persson <b...@bo-persson.se>:
>> On 2022-07-24 at 19:36, Bonita Montero wrote:
>>> Am 20.07.2022 um 04:08 schrieb Cholo Lennon:
>>>> Carbon, the latest programming language to be built within Google, was
>>>> unveiled today as an experimental successor to C++...
>>>>
>>>> https://9to5google.com/2022/07/19/carbon-programming-language-google-cpp/
>>>
>>> I don't know why such a language should be necessary. I don't have
>>> notworthy issues with writing C++-code, even with C++20. But of course
>>> such a language is easier to learn, but once you've get fluent with C++
>>> there's no difference when the features are mostly the same.
>>
>> The Carbon github page lists some of their reasons to create a new
>> languagage:
>>
>> Welcoming open-source community
>>
>> - Clear goals and priorities with robust governance
>> - Community that works to be welcoming, inclusive, and friendly
>> - Batteries-included approach: compiler, libraries, docs, tools,
>> package manager, and more
>>
>>
>> Apparently those are things believed to be missing for C++.
>>
>>
>
> The batteries-included part seems like something that is very much
> today's flavour. You want a compiler that enforces a project
> structure, handles fetching dependencies for you (Go can include
> Github repositories directly in source if I'm not mistaken), lints
> your code, generates documentation etc.
>

But why do you need a new language to provide the tools? Can you not do
that for an existing language?

My impression is that the first two points might be the main reason for
the new language. The last one is just the effect of starting over.


Also, isn't it a bit odd - when having backward compatibility as a major
road block for new changes in C++ - to base your new language on total
interoperability with just C++?

[Andreas Kempe]

It depends on how we want to go about it, I guess. For C++, we already
have all those tools as separate projects. Hypothetically, the C++
steering folks could of course start working on integrating tools,
project layout, etc. into the C++ specification to standardise them,
but I'm not too sure I would like that.

> My impression is that the first two points might be the main reason for
> the new language. The last one is just the effect of starting over.
>

I agree and think the causality is indeed the other way around. People
want new languages for $reasons and it is currently expected of new
languages to provide an entire ecosystem.

>
> Also, isn't it a bit odd - when having backward compatibility as a major
> road block for new changes in C++ - to base your new language on total
> interoperability with just C++?

If I am to do a cynical reading of this, I would say that Google want
something they control and are free to change to suite their purpose,
but they are too heavily invested in C++ to scrap all the existing
code so they need to be able to do a gradual change.