www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - New competitor to D

reply Tejas <notrealemail gmail.com> writes:
There is a new language that claims to be the successor to C++ in 
town, and it's got Google's funding 😥

It's called carbon

https://github.com/carbon-language/carbon-lang


What do you folk think?

If this succeeds, then Google will have the advantage in cross 
platform code (with Dart) as well as high performance code(Carbon)
Jul 19 2022
next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Tuesday, 19 July 2022 at 16:27:25 UTC, Tejas wrote:

 https://github.com/carbon-language/carbon-lang


 What do you folk think?


The FAQ is interesting to see how a large C++ user like Google 
might have problems adopting new languages: 
https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/faq.md#why-not-rust
(mostly: Rust being too safe to incrementally port from C++ to 
Rust)

Carbon seems to uses clang as ImportCPP, a bit like Calypso?

It is, of course, a bit of a killer feature for people using C++ 
(like a C++ compiler supporting C, Typescript etc..) however now 
you would be tied to _both_ Google and Apple when using this one 
language ; codebases using Carbon will mechanically never get rid 
of their C++.
Jul 19 2022
parent Tejas <notrealemail gmail.com> writes:
On Tuesday, 19 July 2022 at 16:47:26 UTC, Guillaume Piolat wrote:

 On Tuesday, 19 July 2022 at 16:27:25 UTC, Tejas wrote:

 https://github.com/carbon-language/carbon-lang


 What do you folk think?


 The FAQ is interesting to see how a large C++ user like Google 
 might have problems adopting new languages: 
 https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/faq.md#why-not-rust
 (mostly: Rust being too safe to incrementally port from C++ to 
 Rust)

 Carbon seems to uses clang as ImportCPP, a bit like Calypso?

 It is, of course, a bit of a killer feature for people using 
 C++ (like a C++ compiler supporting C, Typescript etc..) 
 however now you would be tied to _both_ Google and Apple when 
 using this one language ; codebases using Carbon will 
 mechanically never get rid of their C++.


Yeah, but that won't be much of an advantage when people will 
compare D and Carbon strictly on the basis of technical merit

Very few will be bothered by the fact that they are now dependent 
on two corporations instead of one
Jul 19 2022
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 19 July 2022 at 16:27:25 UTC, Tejas wrote:

 There is a new language that claims to be the successor to C++ 
 in town, and it's got Google's funding 😥

 It's called carbon

 https://github.com/carbon-language/carbon-lang


 What do you folk think?


It is v0.1, so I cannot really tell what it will be like, but it 
my immediate reaction is that this looks like something a Rust 
programmer being forced to write in C++ would come up with.

Why would I want to write "fn" before functions and "var" in 
classes? Right now it seems to provide more downsides than 
upsides and is too close to C++ to be worthwhile, but it is v0.1, 
so who knows?
Jul 19 2022
next sibling parent reply Tejas <notrealemail gmail.com> writes:
On Tuesday, 19 July 2022 at 16:57:29 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 19 July 2022 at 16:27:25 UTC, Tejas wrote:

 There is a new language that claims to be the successor to C++ 
 in town, and it's got Google's funding 😥

 It's called carbon

 https://github.com/carbon-language/carbon-lang


 What do you folk think?


 It is v0.1, so I cannot really tell what it will be like, but 
 it my immediate reaction is that this looks like something a 
 Rust programmer being forced to write in C++ would come up with.

 Why would I want to write "fn" before functions and "var" in 
 classes? Right now it seems to provide more downsides than 
 upsides and is too close to C++ to be worthwhile, but it is 
 v0.1, so who knows?


In your experience, how long does it take a v0.1 language to get 
to v1.0? This is the first time I'm witnessing the rise of a 
language funded by one of MAANG, so I'm extremely ignorant of how 
things usually proceed.
Jul 19 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 19 July 2022 at 17:03:23 UTC, Tejas wrote:

 In your experience, how long does it take a v0.1 language to 
 get to v1.0? This is the first time I'm witnessing the rise of 
 a language funded by one of MAANG, so I'm extremely ignorant of 
 how things usually proceed.


That would depend on demands and resources? In this case they say 
they are more of a successor to C++, so they can perhaps lock 
down more design choices than if you go for something novel.

Bu if it takes less than 3 years to reach V1.0 then I would say 
they are rushing it… On the other hand they also say that they 
focus on language evolution and intend to break things: «Our 
goals are focused on migration from one version of Carbon to the 
next rather than compatibility between them.»

I don't know how to interpret that… Some would say that would 
make it dead on arrival, but if the migration is fully automatic… 
well, we have to wait and see. The proof is in the pudding.
Jul 19 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 19 July 2022 at 17:09:33 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 19 July 2022 at 17:03:23 UTC, Tejas wrote:

 In your experience, how long does it take a v0.1 language to 
 get to v1.0? This is the first time I'm witnessing the rise of 
 a language funded by one of MAANG, so I'm extremely ignorant 
 of how things usually proceed.


 That would depend on demands and resources? In this case they 
 say they are more of a successor to C++, so they can perhaps 
 lock down more design choices than if you go for something 
 novel.

 Bu if it takes less than 3 years to reach V1.0 then I would say 
 they are rushing it…


I found this now:
[Potential 2024-2025 goals: ship 1.0 language & 
organization](https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/roadmap.md#potential-2024-2025-goals-ship-10-lan
uage--organization) :
«A major milestone will be the first version of a production 
language. We should also have finished transferring all 
governance of Carbon to an independent open source organization 
at that point. However, we won't know what a more realistic or 
clear schedule for these milestones will be until we get closer.»

Since all software projects of some size are delayed, I'd say 
2026… ;-)
Jul 19 2022
prev sibling parent reply Kagamin <spam here.lot> writes:
On Tuesday, 19 July 2022 at 16:57:29 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 19 July 2022 at 16:27:25 UTC, Tejas wrote:

 There is a new language that claims to be the successor to C++ 
 in town, and it's got Google's funding 😥

 It's called carbon

 https://github.com/carbon-language/carbon-lang


 What do you folk think?


 It is v0.1, so I cannot really tell what it will be like, but 
 it my immediate reaction is that this looks like something a 
 Rust programmer being forced to write in C++ would come up with.

 Why would I want to write "fn" before functions and "var" in 
 classes? Right now it seems to provide more downsides than 
 upsides and is too close to C++ to be worthwhile, but it is 
 v0.1, so who knows?


It's clearly Rust--.
Jul 20 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 20 July 2022 at 13:46:25 UTC, Kagamin wrote:

 It's clearly Rust--.


They already have a bunch of fans that defends poorly thought out 
aspects of the syntax that a usability analysis ought to have 
uncovered. So I think we can expect that Google will move ahead 
with it… as it is already «popular» on social media…

Reminds me of how Google created Dart as dynamic language, then 
as an afterthought made a U-turn and redesigned it to become more 
like Java. Or how Go doesn't have exceptions, then added a 
hackish «panic» solution . How they didn't have generics, then 
added a weak generics design many years later. Also the Go 
dynamic arrays uses slices that will split when you extend it, so 
that you have two arrays instead of one as a surprise. (D also 
has this flaw).

Designers are often not good at being objective about their own 
design, so I would expect a large organisation like Google to use 
usability experts and make sure to get an external usability 
evaluation and also an external critical examination of semantics 
before the design is presented to the world.

Makes you wonder what the internal project management is like?
Jul 20 2022
parent reply Kagamin <spam here.lot> writes:
On Wednesday, 20 July 2022 at 17:46:15 UTC, Ola Fosheim Grøstad 
wrote:

 Reminds me of how Google created Dart as dynamic language, then 
 as an afterthought made a U-turn and redesigned it to become 
 more like Java.


Can't blame them for that, it's the right thing to do, even 
javascript does it. Dynamic languages scale poorly beyond 100 LOC.
Jul 20 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 20 July 2022 at 18:13:44 UTC, Kagamin wrote:

 Can't blame them for that, it's the right thing to do, even 
 javascript does it. Dynamic languages scale poorly beyond 100 
 LOC.


Can't blame them for not being focused and making a U-turn? It 
wasn't a small scale hobby project. Do you know how many people 
worked on it? :-)
Jul 20 2022
parent reply Kagamin <spam here.lot> writes:
On Wednesday, 20 July 2022 at 18:20:17 UTC, Ola Fosheim Grøstad 
wrote:

 Can't blame them for not being focused and making a U-turn?


They had a mistake and fixed it, happens all the time.
Jul 21 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 21 July 2022 at 08:15:56 UTC, Kagamin wrote:

 On Wednesday, 20 July 2022 at 18:20:17 UTC, Ola Fosheim Grøstad 
 wrote:

 Can't blame them for not being focused and making a U-turn?


 They had a mistake and fixed it, happens all the time.


No, they didn't make a mistake, it was designed as a JavaScript 
replacement. They had an experienced language designer, but put 
in so many mainstream requirements that he felt that the 
resulting language was watered down and "bland". Then internal 
demands for something Java-like (I think they used Dart for their 
Google Ads software) forced it in a more Java-like direction. 
There is really no other reason for Dart to exist today than 
Google's internal use and Flutter. It is a "me too" language with 
no real identity.
Jul 21 2022
parent reply Kagamin <spam here.lot> writes:
On Thursday, 21 July 2022 at 11:06:37 UTC, Ola Fosheim Grøstad 
wrote:

 No, they didn't make a mistake, it was designed as a JavaScript 
 replacement.


My understanding is that it was designed as a language for 
webapps. Simply replacing JavaScript isn't much of a goal.
Jul 21 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 21 July 2022 at 12:16:31 UTC, Kagamin wrote:

 My understanding is that it was designed as a language for 
 webapps. Simply replacing JavaScript isn't much of a goal.


The Dart VM JIT was supposed to go into the Chrome executable as 
a more performant VM JIT than the one for JavaScript, but it was 
dropped. The people who designed Dart also worked on StrongTalk, 
a faster SmallTalk variant, and that [VM design was later turned 
into HotSpot for 
Java](https://comp.lang.smalltalk.narkive.com/GIFQd2Ri/strongtalk-vm-is-now-open-source).
So the Dart designers had knowledge of how language design 
affects VM/JIT performance.

(Dart also compiles to JavaScript as a cross-platform feature, 
but that was not the original primary use case.)
Jul 21 2022
prev sibling next sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
On Tuesday, 19 July 2022 at 16:27:25 UTC, Tejas wrote:

 There is a new language that claims to be the successor to C++ 
 in town, and it's got Google's funding 😥

 It's called carbon

 https://github.com/carbon-language/carbon-lang


 What do you folk think?

 If this succeeds, then Google will have the advantage in cross 
 platform code (with Dart) as well as high performance 
 code(Carbon)


The syntax is a big turn off for me.

- Alex
Jul 19 2022
prev sibling next sibling parent ryuukk_ <ryuukk.dev gmail.com> writes:
C++ needs a replacement, that is for sure

But this one replicates one of its issues: needing forward 
declaration

This is enough to turn me off personally

D is one of the few to have done modules right

Zig is a close 2nd since it did it in a more pragmatic way 
(everything is a struct, and it only compiles what you use, not 
what you import)

I think it is enough to compete with C++, but not enough to 
compete with other languages including D imo
Jul 19 2022
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Tue, Jul 19, 2022 at 04:27:25PM +0000, Tejas via Digitalmars-d wrote:

 There is a new language that claims to be the successor to C++ in
 town, and it's got Google's funding 😥
 
 It's called carbon
 
 https://github.com/carbon-language/carbon-lang
 
 
 What do you folk think?


[...]

Seems it has quite a few of D's good ideas:
- Integer types have specific widths.
- UTF8 by default.
- Slices.
- Type inference, auto return types, et al.
- Single inheritance.  Good that they recognize the problems with
  multiple inheritance.
- Module system.
- Signature constraints.

In some areas it even excels over D:
- Treating bool as its own distinct type rather than a 1-bit integer.
- Treating types as 1st class citizen compile-time values and using
  expressions to form them.
- Built-in tuples with built-in syntax and destructuring.
- Compile-time generic code type-checking. Eliminates the problems
  caused by templates not being type-checked until instantiation.

Other interesting features:
- No null pointers. Trying to fix the billion-dollar mistake, I suppose;
  but it remains to be seen how this will actually pan out.
- Explicit assignment to return value instead of relying on NRVO. Seems
  like a nice thing, but hard to tell at a glance how it plays out.
- No constructors, only factory functions. May not necessarily be a bad
  thing, seems like an exploratory feature. Interesting to see how it
  pans out.
- Explicit move operators.
- Built-in tagged unions (choice types) that unify C/D unions with
  enums. Interesting design.
- `observe` declarations to provide case-specific knowledge to compiler
  where a generic type inference would be undecidable.
- Fluid ABI except at explicit ABI boundaries.  Interesting idea that
  could allow more optimizations.

A few bad ideas, however, it continues to promulgate from C++:
- Forward declarations.  Ick.  Triple ick.
- Class friends. Ugh.
- Separate API file from implementation files: reminiscient of the bad
  ole .h / .cc split, ugh. Can't say it's necessarily bad, but I've a
  bad feeling about this. Would lead to boilerplate. I hate boilerplate.
- Namespaces. Ugh.

Also, the generics system uses type erasure, which could be problematic
in some use cases. But it's hard to judge this without more details
about how it would be implemented.

Currently, metaprogramming is still unspecified, there's only some
initial sketch.  Just based on this alone, Carbon wouldn't be on my
radar; I can't live without metaprogramming. :-D

Also wannabe- safe, and currently undecided error-handling system,
though leaning towards choice types.


T

-- 
By understanding a machine-oriented language, the programmer will tend
to use a much more efficient method; it is much closer to reality. -- D.
Knuth
Jul 19 2022
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 19 July 2022 at 17:40:45 UTC, H. S. Teoh wrote:

 On Tue, Jul 19, 2022 at 04:27:25PM +0000, Tejas via 
 Digitalmars-d wrote:

 There is a new language that claims to be the successor to C++ 
 in town, and it's got Google's funding 😥
 
 It's called carbon
 
 https://github.com/carbon-language/carbon-lang
 
 
 What do you folk think?


 [...]

 Seems it has quite a few of D's good ideas:
 [snip]


Thanks for the summary. It feels like a big language, at least 
from what I've read so far.

The generics system looks like two things: interfaces with type 
erasure plus a templates system comparable to C++'s. Interfaces 
come across as an alternative to Concepts and wouldn't be 
consistent with how Andrei has pushed Design by Introspection. 
Regardless I can think of where that would be useful. 
Particularly on the type erasure side of things. Some consistent 
way to handle that type of behavior would have been nice. inout 
feels bolted on.
Jul 19 2022
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 19.07.22 19:40, H. S. Teoh wrote:

 Currently, metaprogramming is still unspecified, there's only some
 initial sketch.  Just based on this alone, Carbon wouldn't be on my
 radar; I can't live without metaprogramming. :-D


Well, it seems they are on track: 
https://github.com/carbon-language/carbon-lang/blob/99c568e66300dd90526f706634dfdf640e051c29/docs/design/metaprogramming.md

No string mixins so far, though. ;)
Jul 19 2022
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
On Tuesday, 19 July 2022 at 16:27:25 UTC, Tejas wrote:

 There is a new language that claims to be the successor to C++ 
 in town, and it's got Google's funding 😥

 It's called carbon

 https://github.com/carbon-language/carbon-lang


 What do you folk think?

 If this succeeds, then Google will have the advantage in cross 
 platform code (with Dart) as well as high performance 
 code(Carbon)


It looks more like a Rust replacement to me. Nothing is written 
about the memory management but they hint that they want to use 
some kind of life time annotation like Rust. That is enough for 
me wanting to avoid it.

Since there are no plans for full meta programming, then it is no 
D or C++ replacement. Rust replacement maybe.

It's another me too Rust language. Good, then D can let other 
language imitate Rust instead.
Jul 19 2022
parent Don Allen <donaldcallen gmail.com> writes:
On Tuesday, 19 July 2022 at 21:25:28 UTC, IGotD- wrote:

 On Tuesday, 19 July 2022 at 16:27:25 UTC, Tejas wrote:

 There is a new language that claims to be the successor to C++ 
 in town, and it's got Google's funding 😥

 It's called carbon

 https://github.com/carbon-language/carbon-lang


 What do you folk think?

 If this succeeds, then Google will have the advantage in cross 
 platform code (with Dart) as well as high performance 
 code(Carbon)


 It looks more like a Rust replacement to me. Nothing is written 
 about the memory management but they hint that they want to use 
 some kind of life time annotation like Rust. That is enough for 
 me wanting to avoid it.

 Since there are no plans for full meta programming, then it is 
 no D or C++ replacement. Rust replacement maybe.

 It's another me too Rust language. Good, then D can let other 
 language imitate Rust instead.


Because I am at a time in my life where I can do things such as 
this, I have written about 10,000 lines of Rust. I have described 
it as programming while wearing a hair-shirt while on a bed of 
nails. What I learned from this exercise is that there is a very 
large cost, in the sense of a steep learning curve and continuing 
demands on the programmer, to providing memory safety without a 
garbage collector. The Rust Kool-aid drinkers, who appear to be 
mostly from the C++ community, don't seem to have much experience 
with garbage-collected languages and therefore don't understand 
the tradeoffs. It's the classic shiny new object to them.

If I were charged with developing an application where C or C++ 
would be an appropriate choice (a situation requiring absolutely 
predictable latency and/or small footprint), I'd certainly 
consider Rust as a safer, less bug-prone alternative. But 
choosing Rust in situations where Go or Nim or Haskell or D would 
get the job done is, to me, completely crazy. As a (now-retired) 
software manager, if I had a deadline to meet, I wouldn't even 
think about using Rust. And I say this having tested the waters.
Jul 24 2022
prev sibling next sibling parent Martin B <martin.brzenska googlemail.com> writes:
On Tuesday, 19 July 2022 at 16:27:25 UTC, Tejas wrote:

 What do you folk think?


 From the code examples, It looks like a mixture of golang and 
typescript to me - which is what I like to see.
Jul 19 2022
prev sibling next sibling parent reply Ali <fakeemail example.com> writes:
On Tuesday, 19 July 2022 at 16:27:25 UTC, Tejas wrote:

 There is a new language that claims to be the successor to C++ 
 in town, and it's got Google's funding 😥

 It's called carbon

 https://github.com/carbon-language/carbon-lang


 What do you folk think?

 If this succeeds, then Google will have the advantage in cross 
 platform code (with Dart) as well as high performance 
 code(Carbon)


Carbon is nicely discussed on hackernews 
https://news.ycombinator.com/item?id=32151609

In summary it seems to be a language customized to Google needs, 
Google uses C++ extensively and have their own C++ style guide

Rust was too safe for them, so a migration to Rust seem to have 
been too much work

This is doesn't seem like competitor to D or even Rust, this is a 
custom language for Google

I don't think D should even try to compete or compare with it, 
you can't compete with a custom language and you should not
Jul 19 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 19 July 2022 at 22:46:47 UTC, Ali wrote:

 This is doesn't seem like competitor to D or even Rust, this is 
 a custom language for Google


They currently label it as being an experiment. I am not sure it 
will take over C++ for cultural reason, but if they go through 
with it then they will displace other system level languages 
without a doubt.


 I don't think D should even try to compete or compare with it, 
 you can't compete with a custom language and you should not


Their goal is that no organization should have more than 50% 
influence.

D would be better off taking actors seriously, start giving 
‘shared’ meaning and find a real alternative to the current GC.

A language like Carbon would be disruptive in this space as it 
would be the first alternative for people who find C++ to be 
complicated.
Jul 19 2022
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 20 July 2022 at 04:02:46 UTC, Ola Fosheim Grøstad 
wrote:

 D would be better off taking actors seriously, start giving 
 ‘shared’ meaning


There's a preview flag for that! Maybe its time to start looking 
into making it set by default?


 and find a real alternative to the current GC.


We have multiple GC's, there is also std.experimental.allocator.
I feel it should probably be moved out of std.experimental at 
some point.
Jul 20 2022
next sibling parent reply Templated Person <templated person.com> writes:
On Wednesday, 20 July 2022 at 07:23:04 UTC, Nicholas Wilson wrote:

 We have multiple GC's


Do we _really_ have multiple GCs though? How do you we use them, 
what are the advantages / disadvantages of each one?


 there is also std.experimental.allocator


Which is useless until Phobos data types are refactored to use 
that as a parameter.

---

If you ask me, D is better than most languages out there and it 
should be the default way of migrating out of C++. But that's not 
gonna happen until at least multiple of the following happens:

- The runtime gets leaner and more configurable, gotta have that 
wasm support.
- Modern features such as sum types & pattern matching, nullables 
& tuples in the language (not as libraries).
- Allocators passed into functions (+ a "garbage collecting 
allocator" like we have now)

Right now D is trying to compete with Java / Go and C++ / Rust 
and failing at both. Just choose to compete with the lower level 
ones and then higher-level stuff can be added later.
Jul 20 2022
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 20 July 2022 at 09:35:14 UTC, Templated Person 
wrote:

 - The runtime gets leaner and more configurable, gotta have 
 that wasm support.


Yes, I think leaner runtime is on the plan?

Memory management is still a big question mark with no clear 
resolution.


 - Modern features such as sum types & pattern matching, 
 nullables & tuples in the language (not as libraries).
 - Allocators passed into functions (+ a "garbage collecting 
 allocator" like we have now)


This is the tricky bit, this should be thought through from 
scratch. None of the current directions can converge on something 
that fits well together, but with better move semantics you can 
at least implement decent ref-counting schemes where `shared` is 
used to good effect. E.g. ref counting of objects that are shared 
across execution contexts, ref counted arenas. And what about 
local GCs that are dropped in O(1) when the execution context is 
pulled down?

Quite a bit of language tuning has to be done to get there. Like, 
if you allow the entire GC pool to be dropped, then you need to 
distinguish between destructors that manage external resources 
from destructors that has no consequences outside the context. So 
you need a finalizer scheme or a resource manager scheme to make 
arena-like allocation pleasant and performant.
Jul 20 2022
prev sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 20 July 2022 at 09:35:14 UTC, Templated Person 
wrote:

 On Wednesday, 20 July 2022 at 07:23:04 UTC, Nicholas Wilson 
 wrote:

 We have multiple GC's


 Do we _really_ have multiple GCs though? How do you we use 
 them, what are the advantages / disadvantages of each one?


Yes, there is the standard (conservative) GC, there is a Precise 
GC (which is really the same as the standard GC but with a 
precise sweep), and there is a fork GC (which is only for linux) 
which is different to the other two.
  I believe you can choose which one with a `--DRT` flag, and I 
think you can set some config at runtime in druntime somewhere, 
but I'm not sure. I've not bothered to change it.

The standard GC is a stop the world, conservative mark and sweep. 
It treats any value that looks like it could point to valid 
objects to be pointers (called false pointers). False pointers 
are only really a problem on 32-bit, which unless you are writing 
for microcontrollers are going the way of the dodo.
The precise GC is a stop the world, precise mark and sweep. 
Advantage: should not ever get confused by false pointers. 
Disadvantage often slower than the conservative GC.
Fork GC forks the current process and uses linux's cheap copy on 
write pages to mark dead objects asynchronously and then reap 
them. Advantages: not stop the world, asynchronous, usable in 
soft (and probably hard) realtime. Disadvantages: Linux only.


 there is also std.experimental.allocator


 Which is useless until Phobos data types are refactored to use 
 that as a parameter.


Theres not really that many "data" types in the standard library. 
We should have a better container library that should be 
parameterised by the allocator that backs it, but the advantages 
of ranges is most of the code doing computation doesn't care what 
the memory is that backs it.


 If you ask me, D is better than most languages out there and it 
 should be the default way of migrating out of C++. But that's 
 not gonna happen until at least multiple of the following 
 happens:

 - The runtime gets leaner and more configurable, gotta have 
 that wasm support.


LDC has (some?) support for WASM, and the runtime is becoming 
less reliant on TypeInfo, by becoming templated to what is 
actually used. I'm not sure how far away we are from a no 
typeinfo runtime being usable.


 - Modern features such as sum types & pattern matching, 
 nullables & tuples in the language (not as libraries).


Good tuples would be very nice to have.


 - Allocators passed into functions (+ a "garbage collecting 
 allocator" like we have now)


There is nothing stopping you from doing that now. I'm not sure 
what you mean here.
Jul 20 2022
parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 20 July 2022 at 12:27:07 UTC, Nicholas Wilson wrote:

 [snip]
 There is nothing stopping you from doing that now. I'm not sure 
 what you mean here.


I think he meant in the standard library. One thing that might be 
interesting is a blog post that just summarizes some basic 
information on what in the standard library is compatible with 
 nogc and what currently isn't usable with  nogc.
Jul 20 2022
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 20 July 2022 at 07:23:04 UTC, Nicholas Wilson wrote:

 On Wednesday, 20 July 2022 at 04:02:46 UTC, Ola Fosheim Grøstad 
 wrote:

 D would be better off taking actors seriously, start giving 
 ‘shared’ meaning


 There's a preview flag for that! Maybe its time to start 
 looking into making it set by default?


 and find a real alternative to the current GC.


 We have multiple GC's, there is also std.experimental.allocator.
 I feel it should probably be moved out of std.experimental at 
 some point.


I still believe that the easiest way to give D a better chance is:

1. Clean up syntax and enable precise collection by getting rid 
of type punning of pointers (C union), tagged unions is the 
easiest way to do it (but other alternatives are possible).

2. Formalize execution contexts (Task/Actor/GPUCompute) that 
manage their own memory (GC, Arena, whatever) independent of 
other contexts.

3. Require `shared` for items that are accessible from multiple 
contexts.
Jul 20 2022
prev sibling next sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
https://github.com/carbon-language/carbon-lang/tree/trunk/docs/design#choice-types

They got tagged union built in! as well as .Enum and pattern 
matching!

What are we waiting for? We failing behind
Jul 20 2022
parent reply Tejas <notrealemail gmail.com> writes:
On Wednesday, 20 July 2022 at 14:31:49 UTC, ryuukk_ wrote:

 https://github.com/carbon-language/carbon-lang/tree/trunk/docs/design#choice-types

 They got tagged union built in! as well as .Enum and pattern 
 matching!

 What are we waiting for? We failing behind


We're waiting for someone with the skills and motivation to add 
all that to dmd while ensuring it doesn't break the compiler in 
subtle ways, and is willing to go to through the DIP process

Basically, we lack the $$$
Jul 20 2022
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
 On Wednesday, 20 July 2022 at 14:31:49 UTC, ryuukk_ wrote:

 https://github.com/carbon-language/carbon-lang/tree/trunk/docs/design#choice-types
 
 They got tagged union built in! as well as .Enum and pattern
 matching!
 
 What are we waiting for? We failing behind




[...]

We are waiting for highly-motivated and skilled people like you to
submit DIPs and PRs to implement these features in D.


T

-- 
"The number you have dialed is imaginary. Please rotate your phone 90 degrees
and try again."
Jul 20 2022
next sibling parent germandiago <germandiago gmail.com> writes:
On Wednesday, 20 July 2022 at 16:40:14 UTC, H. S. Teoh wrote:

 On Wednesday, 20 July 2022 at 14:31:49 UTC, ryuukk_ wrote:

 https://github.com/carbon-language/carbon-lang/tree/trunk/docs/design#choice-types
 
 They got tagged union built in! as well as .Enum and pattern 
 matching!
 
 What are we waiting for? We failing behind




 [...]

 We are waiting for highly-motivated and skilled people like you 
 to submit DIPs and PRs to implement these features in D.


 T


Lol! :D
Jul 20 2022
prev sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Wednesday, 20 July 2022 at 16:40:14 UTC, H. S. Teoh wrote:

 On Wednesday, 20 July 2022 at 14:31:49 UTC, ryuukk_ wrote:

 https://github.com/carbon-language/carbon-lang/tree/trunk/docs/design#choice-types
 
 They got tagged union built in! as well as .Enum and pattern 
 matching!
 
 What are we waiting for? We failing behind




 [...]

 We are waiting for highly-motivated and skilled people like you 
 to submit DIPs and PRs to implement these features in D.


 T


Let's not suggest anything then, let's accept your faith and 
become irrelevant

I'll just use a different language, i'm fine with that 
personally, what ever empowers me, i'm only just a mere language 
user after all, who cares about the users when you have compiler 
developers telling language users to submit PRs to implement 
their suggestion ;)
Jul 20 2022
next sibling parent ryuukk_ <ryuukk.dev gmail.com> writes:
On Wednesday, 20 July 2022 at 17:19:33 UTC, ryuukk_ wrote:

 On Wednesday, 20 July 2022 at 16:40:14 UTC, H. S. Teoh wrote:

 On Wednesday, 20 July 2022 at 14:31:49 UTC, ryuukk_ wrote:

 https://github.com/carbon-language/carbon-lang/tree/trunk/docs/design#choice-types
 
 They got tagged union built in! as well as .Enum and 
 pattern matching!
 
 What are we waiting for? We failing behind




 [...]

 We are waiting for highly-motivated and skilled people like 
 you to submit DIPs and PRs to implement these features in D.


 T


 Let's not suggest anything then, let's accept your faith and 
 become irrelevant

 I'll just use a different language, i'm fine with that 
 personally, what ever empowers me, i'm only just a mere 
 language user after all, who cares about the users when you 
 have compiler developers telling language users to submit PRs 
 to implement their suggestion ;)


Downloads still down btw, sending PRs myself doesn't even work, 
if nobody left to drive the car

https://github.com/dlang/dlang.org/pull/3344

What's your suggestion for that?
Jul 20 2022
prev sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Wed, Jul 20, 2022 at 05:19:33PM +0000, ryuukk_ via Digitalmars-d wrote:

 On Wednesday, 20 July 2022 at 16:40:14 UTC, H. S. Teoh wrote:

 On Wednesday, 20 July 2022 at 14:31:49 UTC, ryuukk_ wrote:

 https://github.com/carbon-language/carbon-lang/tree/trunk/docs/design#choice-types

 They got tagged union built in! as well as .Enum and pattern
 matching!
 What are we waiting for? We failing behind






 [...]
 
 We are waiting for highly-motivated and skilled people like you to
 submit DIPs and PRs to implement these features in D.




[...]

 Let's not suggest anything then, let's accept your faith and become
 irrelevant
 
 I'll just use a different language, i'm fine with that personally,
 what ever empowers me, i'm only just a mere language user after all,
 who cares about the users when you have compiler developers telling
 language users to submit PRs to implement their suggestion ;)


I think you have a wrong perception of what's going on here.

I'm not a compiler developer, I'm also a mere language user, I just
happened to have occasionally contributed some PRs, mainly to Phobos, a
few to druntime and dmd (simple ones, mind you).  I'm not personally
associated with the language maintainers, and I do not get paid by the D
Foundation for my contributions; I'm not an employee of the Foundation,
I'm just a volunteer.  So you're yelling at the wrong person here. :-D
If anybody, you should be complaining rather to Walter.

This is an open source project primarily run by volunteers (perhaps with
the exception of the language developers and some of the people paid by
the D Foundation).  This isn't some commercial company that pays me to
do work for them; so telling me what I should do with my free time is
rather presumptuous, and quite insulting.  I have no obligations to
serve you or anyone else on this forum, because you're not my customer
-- I don't have any customers, I don't even run this show. You'll gain
nothing by yelling at a fellow D user.

Besides, being a volunteer-run project, what matters isn't how loudly
somebody demands for things to happen, what matters is who is willing to
get their hands dirty and actually write the code to make it happen. If
someone is not willing to do that, then the volume of their voice
matters little in the grand scheme of things.  Time and again people
have shown up on the forums demanding this or that, start a flamewar or
two, but in the end, nothing came of it.  The advances that actually
happened came from people who were willing stoop down and do the actual
work necessary to make it happen. Quite often they were the ones who
hardly said a thing in the forums because they were busy actually
writing code instead of demanding others to do what they want.


T

-- 
Being able to learn is a great learning; being able to unlearn is a greater
learning.
Jul 20 2022
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Wednesday, 20 July 2022 at 18:01:09 UTC, H. S. Teoh wrote:

 On Wed, Jul 20, 2022 at 05:19:33PM +0000, ryuukk_ via 
 Digitalmars-d wrote:

 On Wednesday, 20 July 2022 at 16:40:14 UTC, H. S. Teoh wrote:

 On Wednesday, 20 July 2022 at 14:31:49 UTC, ryuukk_ wrote:

 https://github.com/carbon-language/carbon-lang/tree/trunk/docs/design#choice-types

 They got tagged union built in! as well as .Enum and 
 pattern
 matching!
 What are we waiting for? We failing behind






 [...]
 
 We are waiting for highly-motivated and skilled people like 
 you to submit DIPs and PRs to implement these features in D.




 [...]

 Let's not suggest anything then, let's accept your faith and 
 become irrelevant
 
 I'll just use a different language, i'm fine with that 
 personally, what ever empowers me, i'm only just a mere 
 language user after all, who cares about the users when you 
 have compiler developers telling language users to submit PRs 
 to implement their suggestion ;)


 I think you have a wrong perception of what's going on here.

 I'm not a compiler developer, I'm also a mere language user, I 
 just happened to have occasionally contributed some PRs, mainly 
 to Phobos, a few to druntime and dmd (simple ones, mind you).  
 I'm not personally associated with the language maintainers, 
 and I do not get paid by the D Foundation for my contributions; 
 I'm not an employee of the Foundation, I'm just a volunteer.  
 So you're yelling at the wrong person here. :-D If anybody, you 
 should be complaining rather to Walter.

 This is an open source project primarily run by volunteers 
 (perhaps with the exception of the language developers and some 
 of the people paid by the D Foundation).  This isn't some 
 commercial company that pays me to do work for them; so telling 
 me what I should do with my free time is rather presumptuous, 
 and quite insulting.  I have no obligations to serve you or 
 anyone else on this forum, because you're not my customer -- I 
 don't have any customers, I don't even run this show. You'll 
 gain nothing by yelling at a fellow D user.

 Besides, being a volunteer-run project, what matters isn't how 
 loudly somebody demands for things to happen, what matters is 
 who is willing to get their hands dirty and actually write the 
 code to make it happen. If someone is not willing to do that, 
 then the volume of their voice matters little in the grand 
 scheme of things.  Time and again people have shown up on the 
 forums demanding this or that, start a flamewar or two, but in 
 the end, nothing came of it.  The advances that actually 
 happened came from people who were willing stoop down and do 
 the actual work necessary to make it happen. Quite often they 
 were the ones who hardly said a thing in the forums because 
 they were busy actually writing code instead of demanding 
 others to do what they want.


 T


I think you are the one having the wrong perception of what's 
going on

If nobody suggest anything, if nobody tells what they need, then 
how do you expect someone with the skills to step in and say "Hey 
i know how to do  that, i can maybe offer a hand"

I also volunteer, and i also sent various PRs to the language 
server, i don't brag about it, that is not point of my posts

Without demand, there can't be offers, maybe the way i phrase 
them is poor, i'll make an effort about it

But if everyone turns down every suggestions/discussions how can 
you create momentum?

Not everything needs to start with a PR or DIPs, sometimes it is 
someone fed up with how he has to write code in a certain way and 
wishes feature X existed so he let people know

Telling people to stfu because we don't have $$$ or they should 
do it themselves doesn't sound positive, and kills 
discussions/hype/momentum
Jul 20 2022
next sibling parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Wed, Jul 20, 2022 at 06:15:22PM +0000, ryuukk_ via Digitalmars-d wrote:
[...]

 I think you are the one having the wrong perception of what's going on
 
 If nobody suggest anything, if nobody tells what they need, then how
 do you expect someone with the skills to step in and say "Hey i know
 how to do that, i can maybe offer a hand"


That's fine.  But if nobody steps up to do it, then what?



 I also volunteer, and i also sent various PRs to the language server,
 i don't brag about it, that is not point of my posts
 
 Without demand, there can't be offers, maybe the way i phrase them is
 poor, i'll make an effort about it
 
 But if everyone turns down every suggestions/discussions how can you
 create momentum?


I didn't turn down your suggestion.  That would imply that I have some
kind of decision-making power over the language, which I don't.  The
decision-making is done by Walter and Atila, I have no say over that.



 Not everything needs to start with a PR or DIPs, sometimes it is
 someone fed up with how he has to write code in a certain way and
 wishes feature X existed so he let people know


That's fine too.  But it requires someone to pick up the tab and
actually implement it, otherwise nothing will change.



 Telling people to stfu because we don't have $$$ or they should do it
 themselves doesn't sound positive, and kills discussions/hype/momentum


I didn't tell you to STFU.  Maybe something got lost in the ether,
sometimes forum posts convey words but not the expression. All happened
was, you asked "what are we waiting for" to implement feature XYZ, and I
replied to your question of what we're waiting for: i.e., what must
happen before we will have feature XYZ. That is, somebody needs to sit
down and implement feature XYZ. Until that happens, feature XYZ won't
exist in D.  It's as simple as that.  You can feel free to continue to
make suggestions, complain about the lack of XYZ, etc., which is fine,
I'm not going to stop you. (I *can't* stop you, even if I wanted to,
anyway.)  But feature XYZ isn't going to suddenly drop down from the sky
all implemented and ready to go until somebody actually sits down and
does the work.


T

-- 
Question authority. Don't ask why, just do it.
Jul 20 2022
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 20 July 2022 at 18:15:22 UTC, ryuukk_ wrote:

 But if everyone turns down every suggestions/discussions how 
 can you create momentum?


What is a needed is a plan with dependencies mapped out and 
priorities assigned, and focused process, but the D evolution 
history is more impulse driven and the planning aspect has been 
vague… this is the most limiting factor at this point.

In contrast Carbon has one, and primarily one, huge advantage: 
they have a big internal business critical use case in Google 
that will drive new features and tooling. Management will get 
resources allocated to improve on the weak language spots as they 
start to use Carbon internally (features driven by internal 
demand). As such the evolution cannot follow impulses, but has to 
be driven by plans (which will ensure steady progress).

It remains to be seen whether Carbon will be useful for small 
projects or end up like Ada: too tedious to be used for small and 
medium sized projects?

It is very difficult to tell at this point, but there is some 
arrogance in claiming to be a "C++ successor" at V0.1 and then 
push a somewhat flawed ML/Rust/TypeScript mashup syntax and less 
flexible semantics than C++.

One big future problem for D is that Carbon has this huge 
internal use case and most likely will get solid open source 
tooling funded by Google and a bunch of tutorials written by 
self-promoting bloggers.

Today we have the situation that people look at C++, finds it 
overwhelming, looks at Rust, finds it difficult to get into, then 
looks at niche alternatives (Zig, D etc). With 3 major system 
level languages I think many devs will stop looking further when 
they have looked at the three major contenders and just pick the 
one they find easier to deal with.

This might be a good time to consider a D3 move.
Jul 21 2022
next sibling parent ryuukk_ <ryuukk.dev gmail.com> writes:
On Thursday, 21 July 2022 at 11:00:11 UTC, Ola Fosheim Grøstad 
wrote:

 On Wednesday, 20 July 2022 at 18:15:22 UTC, ryuukk_ wrote:

 But if everyone turns down every suggestions/discussions how 
 can you create momentum?


 What is a needed is a plan with dependencies mapped out and 
 priorities assigned, and focused process, but the D evolution 
 history is more impulse driven and the planning aspect has been 
 vague… this is the most limiting factor at this point.

 In contrast Carbon has one, and primarily one, huge advantage: 
 they have a big internal business critical use case in Google 
 that will drive new features and tooling. Management will get 
 resources allocated to improve on the weak language spots as 
 they start to use Carbon internally (features driven by 
 internal demand). As such the evolution cannot follow impulses, 
 but has to be driven by plans (which will ensure steady 
 progress).

 It remains to be seen whether Carbon will be useful for small 
 projects or end up like Ada: too tedious to be used for small 
 and medium sized projects?

 It is very difficult to tell at this point, but there is some 
 arrogance in claiming to be a "C++ successor" at V0.1 and then 
 push a somewhat flawed ML/Rust/TypeScript mashup syntax and 
 less flexible semantics than C++.

 One big future problem for D is that Carbon has this huge 
 internal use case and most likely will get solid open source 
 tooling funded by Google and a bunch of tutorials written by 
 self-promoting bloggers.

 Today we have the situation that people look at C++, finds it 
 overwhelming, looks at Rust, finds it difficult to get into, 
 then looks at niche alternatives (Zig, D etc). With 3 major 
 system level languages I think many devs will stop looking 
 further when they have looked at the three major contenders and 
 just pick the one they find easier to deal with.

 This might be a good time to consider a D3 move.


I agree with you, and even more with your last sentence
Jul 21 2022
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 21 July 2022 at 11:00:11 UTC, Ola Fosheim Grøstad 
wrote:

 On Wednesday, 20 July 2022 at 18:15:22 UTC, ryuukk_ wrote:

 But if everyone turns down every suggestions/discussions how 
 can you create momentum?


 What is a needed is a plan with dependencies mapped out and 
 priorities assigned, and focused process, but the D evolution 
 history is more impulse driven and the planning aspect has been 
 vague… this is the most limiting factor at this point.

 In contrast Carbon has one, and primarily one, huge advantage: 
 they have a big internal business critical use case in Google 
 that will drive new features and tooling. Management will get 
 resources allocated to improve on the weak language spots as 
 they start to use Carbon internally (features driven by 
 internal demand). As such the evolution cannot follow impulses, 
 but has to be driven by plans (which will ensure steady 
 progress).

 It remains to be seen whether Carbon will be useful for small 
 projects or end up like Ada: too tedious to be used for small 
 and medium sized projects?

 It is very difficult to tell at this point, but there is some 
 arrogance in claiming to be a "C++ successor" at V0.1 and then 
 push a somewhat flawed ML/Rust/TypeScript mashup syntax and 
 less flexible semantics than C++.

 One big future problem for D is that Carbon has this huge 
 internal use case and most likely will get solid open source 
 tooling funded by Google and a bunch of tutorials written by 
 self-promoting bloggers.

 Today we have the situation that people look at C++, finds it 
 overwhelming, looks at Rust, finds it difficult to get into, 
 then looks at niche alternatives (Zig, D etc). With 3 major 
 system level languages I think many devs will stop looking 
 further when they have looked at the three major contenders and 
 just pick the one they find easier to deal with.

 This might be a good time to consider a D3 move.


The arrogance can be explained by being the same people that lost 
the C++ ABI vote at ISO, and since then ramped down their 
involvement either at ISO or clang further development.

https://old.reddit.com/r/programming/comments/w2thvo/carbon_an_experimental_c_successor_language/igs25eu/

and also https://cor3ntin.github.io/posts/abi/

This is one of the reasons why clang is now third in ISO C++ 
support, and since no other compiler vendor that enjoys clang, 
seems willing to step into Apple (focused on Swift/Objective-C) 
or Google's previous roles, it doesn't look like it will change.

Meanwhile those previous clang contributors are now having fun 
tailoring Carbon as they wish instead of fighting for their 
papers at ISO.
Jul 21 2022
next sibling parent M.M. <matus email.cz> writes:
On Friday, 22 July 2022 at 05:39:22 UTC, Paulo Pinto wrote:

 On Thursday, 21 July 2022 at 11:00:11 UTC, Ola Fosheim Grøstad 
 wrote:

 [...]


 The arrogance can be explained by being the same people that 
 lost the C++ ABI vote at ISO, and since then ramped down their 
 involvement either at ISO or clang further development.

 https://old.reddit.com/r/programming/comments/w2thvo/carbon_an_experimental_c_successor_language/igs25eu/

 and also https://cor3ntin.github.io/posts/abi/

 This is one of the reasons why clang is now third in ISO C++ 
 support, and since no other compiler vendor that enjoys clang, 
 seems willing to step into Apple (focused on Swift/Objective-C) 
 or Google's previous roles, it doesn't look like it will change.

 Meanwhile those previous clang contributors are now having fun 
 tailoring Carbon as they wish instead of fighting for their 
 papers at ISO.


Very interesting read, thank you for the links. But does that all 
mean that C++ will become a less popular choice in new (large) 
projects in industry?

I always thought that C++ is here to stay...
Jul 22 2022
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 22 July 2022 at 05:39:22 UTC, Paulo Pinto wrote:

 This is one of the reasons why clang is now third in ISO C++ 
 support, and since no other compiler vendor that enjoys clang, 
 seems willing to step into Apple (focused on Swift/Objective-C) 
 or Google's previous roles, it doesn't look like it will change.


Apple tutorials use Objective-C++, but I think they view it as a 
support language for Swift.

Maybe GPL is the better license for programming languages... gcc 
could benefit from clang being wiped out.


 Meanwhile those previous clang contributors are now having fun 
 tailoring Carbon as they wish instead of fighting for their 
 papers at ISO.


But they are not very good at it... They are going to end up with 
some of D’s problems. They need an external qualified reviewer.

Also only support for C++17 as a stated goal does not make you a 
C++ successor outside of big business legacy code bases.
Jul 22 2022
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 22 July 2022 at 07:10:02 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 22 July 2022 at 05:39:22 UTC, Paulo Pinto wrote:

 This is one of the reasons why clang is now third in ISO C++ 
 support, and since no other compiler vendor that enjoys clang, 
 seems willing to step into Apple (focused on 
 Swift/Objective-C) or Google's previous roles, it doesn't look 
 like it will change.


 Apple tutorials use Objective-C++, but I think they view it as 
 a support language for Swift.



Which tutorials?

Objective-C++ has been almost erradicated from Apple's developer 
site, only old timers like myself still have the docs in their 
original forms.

In what concerns C++ at Apple, the only uses of it are for IO Kit 
and Driver Kit (an embedded C++ subset), Metal Shading Language 
(a C++14 dialect), and whatever is needed on LLVM to support 
Swift and Objective-C implementations.


 Maybe GPL is the better license for programming languages... 
 gcc could benefit from clang being wiped out.


 Meanwhile those previous clang contributors are now having fun 
 tailoring Carbon as they wish instead of fighting for their 
 papers at ISO.


 But they are not very good at it... They are going to end up 
 with some of D’s problems. They need an external qualified 
 reviewer.

 Also only support for C++17 as a stated goal does not make you 
 a C++ successor outside of big business legacy code bases.


Here is the thing, if the large majority of C++ world never moves 
beyond C++17, with cherry picked features from later standards, 
does it really matter?

https://en.cppreference.com/w/cpp/compiler_support

A paper standard only matter as much as there are actually 
compilers supporting it.
Jul 22 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 22 July 2022 at 08:10:49 UTC, Paulo Pinto wrote:

 Which tutorials?


Performance oriented ones, such as GPU-compute with Metal.


 Here is the thing, if the large majority of C++ world never 
 moves beyond C++17, with cherry picked features from later 
 standards, does it really matter?


Perhaps not for legacy corporate codebases, but for people who 
have more recent code bases it probably will.

It matters because stack-less coroutines is a significant 
feature, by the time Carbon is ready with tooling (say in 5 
years) frameworks will have adopted stack-less and people will 
look forward to C++26. That most likely includes HPC stuff.


 A paper standard only matter as much as there are actually 
 compilers supporting it.


MSVC and GCC are heavy weights, and most Clang extensions are 
close to GCC, so switching a codebase from Clang to GCC isn't 
really a big deal (or shouldn't be for reasonable code bases).
Jul 22 2022
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 22 July 2022 at 08:42:40 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 22 July 2022 at 08:10:49 UTC, Paulo Pinto wrote:

 Which tutorials?


 Performance oriented ones, such as GPU-compute with Metal.


The more recent ones make use of Objective-C runtime API called 
directly from C++,

https://developer.apple.com/metal/sample-code/

Objective-C++ documentation is gone from 
https://developer.apple.com


 Here is the thing, if the large majority of C++ world never 
 moves beyond C++17, with cherry picked features from later 
 standards, does it really matter?


 Perhaps not for legacy corporate codebases, but for people who 
 have more recent code bases it probably will.

 It matters because stack-less coroutines is a significant 
 feature, by the time Carbon is ready with tooling (say in 5 
 years) frameworks will have adopted stack-less and people will 
 look forward to C++26. That most likely includes HPC stuff.


HPC cares about MPI, OpenACC, SYCL and CUDA, they will go with 
whatever version they support.

Also they are already good served with HPX (C++11 based).


 A paper standard only matter as much as there are actually 
 compilers supporting it.


 MSVC and GCC are heavy weights, and most Clang extensions are 
 close to GCC, so switching a codebase from Clang to GCC isn't 
 really a big deal (or shouldn't be for reasonable code bases).


MSVC only matters for Windows and XBox developers, and the new 
push is most likely triggered from WinDev and XBox business units 
not being .NET fans, contrary to what is happening at Azure, 
where .NET, Go, Java and Rust rule the party.

So that leaves GCC, and how much Red-Hat/IBM care to keep it up 
to date post ISO C++20.
Jul 22 2022
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 22 July 2022 at 08:42:40 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 22 July 2022 at 08:10:49 UTC, Paulo Pinto wrote:

 Which tutorials?


 Performance oriented ones, such as GPU-compute with Metal.


The more recent ones make use of Objective-C runtime API called 
directly from C++,

https://developer.apple.com/metal/sample-code/

Objective-C++ documentation is gone from 
https://developer.apple.com


 Here is the thing, if the large majority of C++ world never 
 moves beyond C++17, with cherry picked features from later 
 standards, does it really matter?


 Perhaps not for legacy corporate codebases, but for people who 
 have more recent code bases it probably will.

 It matters because stack-less coroutines is a significant 
 feature, by the time Carbon is ready with tooling (say in 5 
 years) frameworks will have adopted stack-less and people will 
 look forward to C++26. That most likely includes HPC stuff.


HPC cares about MPI, OpenACC, SYCL and CUDA, they will go with 
whatever version they support.

Also they are already good served with HPX (C++11 based).


 A paper standard only matter as much as there are actually 
 compilers supporting it.


 MSVC and GCC are heavy weights, and most Clang extensions are 
 close to GCC, so switching a codebase from Clang to GCC isn't 
 really a big deal (or shouldn't be for reasonable code bases).


MSVC only matters for Windows and XBox developers, and the new 
push is most likely triggered from WinDev and XBox business units 
not being .NET fans, contrary to what is happening at Azure, 
where .NET, Go, Java and Rust rule the party.

So that leaves GCC, and how much Red-Hat/IBM care to keep it up 
to date post ISO C++20.
Jul 22 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 22 July 2022 at 09:47:57 UTC, Paulo Pinto wrote:

 On Friday, 22 July 2022 at 08:42:40 UTC, Ola Fosheim Grøstad 
 wrote:

 On Friday, 22 July 2022 at 08:10:49 UTC, Paulo Pinto wrote:

 Which tutorials?


 Performance oriented ones, such as GPU-compute with Metal.


 The more recent ones make use of Objective-C runtime API called 
 directly from C++,


Yes, you are right, they use Objective-C in the tutorials, not 
Objective-C++.

They seem to have added C++ support to their package manager 
fairly recently:
https://github.com/apple/swift-evolution/blob/main/proposals/0181-package-manager-cpp-language-version.md

I don't quite see Apple adopting Carbon… but who knows?


 MSVC only matters for Windows and XBox developers, and the new 
 push is most likely triggered from WinDev and XBox business 
 units not being .NET fans, contrary to what is happening at 
 Azure, where .NET, Go, Java and Rust rule the party.

 So that leaves GCC, and how much Red-Hat/IBM care to keep it up 
 to date post ISO C++20.


The ISO process will not move faster than GCC/MSVC, so in that 
case it means that the evolution will slow down. Which is not a 
bad thing at this point. The most glaring missing piece in C++ is 
standardized SIMD support, which is easy to add.

Library only extensions are not going to be a problem for GCC.
Jul 22 2022
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 22 July 2022 at 10:17:00 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 22 July 2022 at 09:47:57 UTC, Paulo Pinto wrote:

 On Friday, 22 July 2022 at 08:42:40 UTC, Ola Fosheim Grøstad 
 wrote:

 On Friday, 22 July 2022 at 08:10:49 UTC, Paulo Pinto wrote:

 Which tutorials?


 Performance oriented ones, such as GPU-compute with Metal.


 The more recent ones make use of Objective-C runtime API 
 called directly from C++,


 Yes, you are right, they use Objective-C in the tutorials, not 
 Objective-C++.

 They seem to have added C++ support to their package manager 
 fairly recently:
 https://github.com/apple/swift-evolution/blob/main/proposals/0181-package-manager-cpp-language-version.md

 I don't quite see Apple adopting Carbon… but who knows?


They already have Swift for that,

"Swift is intended as a replacement for C-based languages (C, 
C++, and Objective-C)."

https://www.swift.org/about/


 MSVC only matters for Windows and XBox developers, and the new 
 push is most likely triggered from WinDev and XBox business 
 units not being .NET fans, contrary to what is happening at 
 Azure, where .NET, Go, Java and Rust rule the party.

 So that leaves GCC, and how much Red-Hat/IBM care to keep it 
 up to date post ISO C++20.


 The ISO process will not move faster than GCC/MSVC, so in that 
 case it means that the evolution will slow down. Which is not a 
 bad thing at this point. The most glaring missing piece in C++ 
 is standardized SIMD support, which is easy to add.

 Library only extensions are not going to be a problem for GCC.


It means that if Google is sucessful with Carbon, we are at a 
turning point for C++'s evolution.

You just need to see how the C, COBOL, Fortran and Ada ecosystems 
care about latest ISO revisions across all existing compilers.
Jul 22 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 22 July 2022 at 11:05:06 UTC, Paulo Pinto wrote:

 They already have Swift for that,

 "Swift is intended as a replacement for C-based languages (C, 
 C++, and Objective-C)."


I followed an interview with Chris Lattner a long time ago where 
he stated that he would like to see Swift evolved into a system 
level programming language with low level support, but it is 
still not attractive for lower level programming.

Also, Apple want games to be ported over from other platforms, 
so… they don't actually want to be an island.


 It means that if Google is sucessful with Carbon, we are at a 
 turning point for C++'s evolution.


Yes, that is possible, if we talk about the core language, but I 
am not sure if the core language should be extended much further. 
C++ can evolve quite a bit by adding library constructs on the 
current foundation.

Intel also has a clang based compiler now, so the picture is a 
bit more complicated.


 You just need to see how the C, COBOL, Fortran and Ada 
 ecosystems care about latest ISO revisions across all existing 
 compilers.


I think this is an ISO process requirement.
Jul 22 2022
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 22 July 2022 at 11:29:01 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 22 July 2022 at 11:05:06 UTC, Paulo Pinto wrote:

 They already have Swift for that,

 "Swift is intended as a replacement for C-based languages (C, 
 C++, and Objective-C)."


 I followed an interview with Chris Lattner a long time ago 
 where he stated that he would like to see Swift evolved into a 
 system level programming language with low level support, but 
 it is still not attractive for lower level programming.

 Also, Apple want games to be ported over from other platforms,


Most game studios don't care about modern C++.

In what Apple is concerned, as long as Unreal and Unity compile 
they're good.

Same applies to Google on Android, where NDK is stuck in C++17 as 
well.


 so… they don't actually want to be an island.


 It means that if Google is sucessful with Carbon, we are at a 
 turning point for C++'s evolution.


 Yes, that is possible, if we talk about the core language, but 
 I am not sure if the core language should be extended much 
 further. C++ can evolve quite a bit by adding library 
 constructs on the current foundation.

 Intel also has a clang based compiler now, so the picture is a 
 bit more complicated.


Everyone except Microsoft has as clang based compiler, they 
hardly contribute to ISO C++ compliance.

That means IBM, HP, ARM, Intel, Sony, Nintendo, GreenHills, 
Apple, Google, TI, Microship, Embarcadero, and probably a few 
others I have forgotten about.


 You just need to see how the C, COBOL, Fortran and Ada 
 ecosystems care about latest ISO revisions across all existing 
 compilers.


 I think this is an ISO process requirement.


It definitely is, the talk is now available.

https://youtu.be/omrY53kbVoA
Jul 22 2022
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Saturday, 23 July 2022 at 06:54:45 UTC, Paulo Pinto wrote:

 Most game studios don't care about modern C++.


That doesn't mean they don't care about C++, Carbon is v0.1, its 
goals might be interesting enough for people to care once released



game server, both, to C++

https://hytale.com/news/2022/7/summer-2022-development-update

Lot of potential for a Kotlin story in C++
Jul 23 2022
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Saturday, 23 July 2022 at 12:49:44 UTC, ryuukk_ wrote:

 On Saturday, 23 July 2022 at 06:54:45 UTC, Paulo Pinto wrote:

 Most game studios don't care about modern C++.


 That doesn't mean they don't care about C++, Carbon is v0.1, 
 its goals might be interesting enough for people to care once 
 released



 game server, both, to C++

 https://hytale.com/news/2022/7/summer-2022-development-update

 Lot of potential for a Kotlin story in C++


They care about C++ alright, not where ISO C++ is heading though.

I advise some talks from Mike Acton or from WG21 SG14 members.
Jul 23 2022
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Saturday, 23 July 2022 at 13:13:04 UTC, Paulo Pinto wrote:

 On Saturday, 23 July 2022 at 12:49:44 UTC, ryuukk_ wrote:

 On Saturday, 23 July 2022 at 06:54:45 UTC, Paulo Pinto wrote:

 Most game studios don't care about modern C++.


 That doesn't mean they don't care about C++, Carbon is v0.1, 
 its goals might be interesting enough for people to care once 
 released



 Java game server, both, to C++

 https://hytale.com/news/2022/7/summer-2022-development-update

 Lot of potential for a Kotlin story in C++


 They care about C++ alright, not where ISO C++ is heading 
 though.

 I advise some talks from Mike Acton or from WG21 SG14 members.


I saw them, i agree with them, C++ is headed into the abyss, but 
it still remains the best choice today, since you can stick to C, 
sort of, and cherry picking few of the nice things about modern 
C++

Enthusiast devs are more strict about it 
https://gist.github.com/bkaradzic/2e39896bc7d8c34e042b
Jul 23 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 23 July 2022 at 13:55:31 UTC, ryuukk_ wrote:

 I saw them, i agree with them, C++ is headed into the abyss, 
 but it still remains the best choice today, since you can stick 
 to C, sort of, and cherry picking few of the nice things about 
 modern C++

 Enthusiast devs are more strict about it 
 https://gist.github.com/bkaradzic/2e39896bc7d8c34e042b


This is kinda pointless. If you know the language then you know 
what to avoid and where. Right now C++20 looks like a better 
language than Carbon, but that could change of course.
Jul 23 2022
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Saturday, 23 July 2022 at 15:38:49 UTC, Ola Fosheim Grøstad 
wrote:

 On Saturday, 23 July 2022 at 13:55:31 UTC, ryuukk_ wrote:

 I saw them, i agree with them, C++ is headed into the abyss, 
 but it still remains the best choice today, since you can 
 stick to C, sort of, and cherry picking few of the nice things 
 about modern C++

 Enthusiast devs are more strict about it 
 https://gist.github.com/bkaradzic/2e39896bc7d8c34e042b


 This is kinda pointless. If you know the language then you know 
 what to avoid and where. Right now C++20 looks like a better 
 language than Carbon, but that could change of course.


Modern C++ has the same problem as D

They think language features should be in `std::` and removing 
features should be forbidden

Wich is why Carbon is interesting, at least to me, that doesn't 
mean i'll use it, since i have 0 interest in C++
Jul 23 2022
next sibling parent reply Martin B <martin.brzenska googlemail.com> writes:
On Saturday, 23 July 2022 at 15:47:40 UTC, ryuukk_ wrote:

 Modern C++ has the same problem as D
[...]
 Wich is why Carbon is interesting, at least to me, that doesn't 
 mean i'll use it, since i have 0 interest in C++


If I may ask, what are you doing here?
Jul 23 2022
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Saturday, 23 July 2022 at 16:42:44 UTC, Martin B wrote:

 On Saturday, 23 July 2022 at 15:47:40 UTC, ryuukk_ wrote:

 Modern C++ has the same problem as D
[...]
 Wich is why Carbon is interesting, at least to me, that 
 doesn't mean i'll use it, since i have 0 interest in C++


 If I may ask, what are you doing here?


What do you mean? you do not like objective opinions?
Jul 23 2022
next sibling parent ryuukk_ <ryuukk.dev gmail.com> writes:
On Saturday, 23 July 2022 at 16:50:28 UTC, ryuukk_ wrote:

 On Saturday, 23 July 2022 at 16:42:44 UTC, Martin B wrote:

 On Saturday, 23 July 2022 at 15:47:40 UTC, ryuukk_ wrote:

 Modern C++ has the same problem as D
[...]
 Wich is why Carbon is interesting, at least to me, that 
 doesn't mean i'll use it, since i have 0 interest in C++


 If I may ask, what are you doing here?


 What do you mean? you do not like objective opinions?


I was referring to tagged union (including pattern matching) and 
nullable being std libraries in both D and C++ as opposed to new 
languages making them builtin types, as i kept mentioning in all 
of my posts (check history)

If one stops being objective and is emotional about opinions and 
features, there is no room for evolution no more

Understanding strength and weaknesses of projects helps make 
proper documented choice

I try to stay objective, no matter what
Jul 23 2022
prev sibling parent claptrap <clap trap.com> writes:
On Saturday, 23 July 2022 at 16:50:28 UTC, ryuukk_ wrote:

 On Saturday, 23 July 2022 at 16:42:44 UTC, Martin B wrote:

 On Saturday, 23 July 2022 at 15:47:40 UTC, ryuukk_ wrote:

 Modern C++ has the same problem as D
[...]
 Wich is why Carbon is interesting, at least to me, that 
 doesn't mean i'll use it, since i have 0 interest in C++


 If I may ask, what are you doing here?


 What do you mean? you do not like objective opinions?


An objective opinion is like an exact estimate.

See...

https://en.wiktionary.org/wiki/contradiction_in_terms
Jul 24 2022
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 23 July 2022 at 15:47:40 UTC, ryuukk_ wrote:

 Modern C++ has the same problem as D

 They think language features should be in `std::` and removing 
 features should be forbidden


So… an important concept in language design is to keep the core 
language minimal and try to implement as much as possible as 
library constructs. This isn't specific to D or C++, this is a 
core language design principle.

Some languages are more explorative in nature… C++ and D falls 
into this category. So they accumulate some bloat by not adhering 
to the idea of having a minimal core language. Then you end up in 
a situation where you want to make a major revision after some 
years once you have figured out what the core language ought to 
be.

Until there is consensus on the minimal language then things will 
not change significantly.


 Which is why Carbon is interesting, at least to me, that 
 doesn't mean i'll use it, since i have 0 interest in C++


Well, it is easy for the Carbon designers to say that they will 
break things with a light heart now, but that is not really an 
appealing property, so it remains to see what that means in 
practice.
Jul 23 2022
prev sibling next sibling parent reply solidstate1991 <laszloszeremi outlook.com> writes:
On Tuesday, 19 July 2022 at 16:27:25 UTC, Tejas wrote:

 There is a new language that claims to be the successor to C++ 
 in town, and it's got Google's funding 😥

 It's called carbon

 https://github.com/carbon-language/carbon-lang


 What do you folk think?

 If this succeeds, then Google will have the advantage in cross 
 platform code (with Dart) as well as high performance 
 code(Carbon)


I'm not really concerned. It's just an even uglier C++.
Jul 22 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 22 July 2022 at 22:12:35 UTC, solidstate1991 wrote:

 I'm not really concerned. It's just an even uglier C++.


The syntax is quite bad, e.g. this is for destructors:

```
    destructor [me: Self] { ... } // unable to modify object
    destructor [addr me: Self*] { ... } // can modify object

```

But I guess they can provide syntax sugar for such annoyances at 
a later stage. It is unclear if this is just the core language 
without syntax sugar or if it is meant code that is meant to be 
written…
Jul 23 2022
prev sibling parent reply IGotD- <nise nise.com> writes:
On Tuesday, 19 July 2022 at 16:27:25 UTC, Tejas wrote:

 There is a new language that claims to be the successor to C++ 
 in town, and it's got Google's funding 😥


Thanks to LLVM new languages are popping up frequently now, which 
is a good thing. Carbon was not the first and will not be the 
last. In my opinion Carbon (why did they name it that) is dead on 
arrival because what I've read it offers zero novelties compared 
to for example Rust. Also the syntax isn't particulary nice.

There will be a language up ahead that will be smash hit when you 
least expect it. Carbon is not one of them.
Jul 24 2022
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 24 July 2022 at 19:38:53 UTC, IGotD- wrote:

 In my opinion Carbon (why did they name it that) is dead on 
 arrival because what I've read it offers zero novelties 
 compared to for example Rust. Also the syntax isn't particulary 
 nice.


It is too early to tell. Depends on how good they are at taking 
feedback and cater to seasoned C++ developers. Their first goal 
is to release a minimal-viable-product which is quite a big task 
since it involves all of C++17 and their own generics solution. 
It was stated that another team at Google is looking at interop 
between Rust and C++, and they are following efforts of adding 
lifetimes to C++…

Anyway, it all hangs on the semantics and how fast they deliver. 
Syntax issues are easy to fix later…
Jul 24 2022
prev sibling parent reply Tejas <notrealemail gmail.com> writes:
On Sunday, 24 July 2022 at 19:38:53 UTC, IGotD- wrote:

 On Tuesday, 19 July 2022 at 16:27:25 UTC, Tejas wrote:

 There is a new language that claims to be the successor to C++ 
 in town, and it's got Google's funding 😥


 Thanks to LLVM new languages are popping up frequently now, 
 which is a good thing. Carbon was not the first and will not be 
 the last. In my opinion Carbon (why did they name it that) is 
 dead on arrival because what I've read it offers zero novelties 
 compared to for example Rust. Also the syntax isn't particulary 
 nice.

 There will be a language up ahead that will be smash hit when 
 you least expect it. Carbon is not one of them.



All the disinterest/lack of belief regarding Carbon's 
(potential)success is really making me think about Go, where 
people said something about it not having used any of the 
research in type theory since the 1970s, coupled with their 
insistence on not having generics, a stupid error handling system 
all combined to make it stand no chance in the future.

But it's still popular today

Maybe there's a non-trivial chance Carbon will end up the same? 
As we have already seen, it's not always about the technical 
merit.
Jul 24 2022
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 25 July 2022 at 02:56:53 UTC, Tejas wrote:

 On Sunday, 24 July 2022 at 19:38:53 UTC, IGotD- wrote:

 On Tuesday, 19 July 2022 at 16:27:25 UTC, Tejas wrote:

 There is a new language that claims to be the successor to 
 C++ in town, and it's got Google's funding 😥


 Thanks to LLVM new languages are popping up frequently now, 
 which is a good thing. Carbon was not the first and will not 
 be the last. In my opinion Carbon (why did they name it that) 
 is dead on arrival because what I've read it offers zero 
 novelties compared to for example Rust. Also the syntax isn't 
 particulary nice.

 There will be a language up ahead that will be smash hit when 
 you least expect it. Carbon is not one of them.



 All the disinterest/lack of belief regarding Carbon's 
 (potential)success is really making me think about Go, where 
 people said something about it not having used any of the 
 research in type theory since the 1970s, coupled with their 
 insistence on not having generics, a stupid error handling 
 system all combined to make it stand no chance in the future.

 But it's still popular today

 Maybe there's a non-trivial chance Carbon will end up the same? 
 As we have already seen, it's not always about the technical 
 merit.


Thanks Docker, Kubernetes and the cloud native foundation 
ecosystem that sprung from them.

clang is already lagging in ISO C++ support because Apple focus 
on Swift, Google's loss of interest (we know now why, it is even 
mentioned on the talk) and everyone else not caring enough about 
upstream.

Google only needs to push Carbon on Android or something like 
that.
Jul 24 2022
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Monday, 25 July 2022 at 05:24:54 UTC, Paulo Pinto wrote:

 Google only needs to push Carbon on Android or something like 
 that.


I'm still struggling to understand why would Google goes to the 
effort of creating a new language (that they seemingly don't want 
to manage alone in the long-run) instead of forking Calypso. 
AFAIK Carbon is similar to Calypso. It all just seems really 
expensive.
Jul 26 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 26 July 2022 at 11:12:15 UTC, Guillaume Piolat wrote:

 I'm still struggling to understand why would Google goes to the 
 effort of creating a new language (that they seemingly don't 
 want to manage alone in the long-run) instead of forking 
 Calypso. AFAIK Carbon is similar to Calypso. It all just seems 
 really expensive.


They build a compiler so that they can change and extend C++ 
semantics with full freedom, including improved semantic 
analysis. Calypso would be a drop in the ocean and even more 
limiting than evolving Clang (they are not evolving clang as 
such).

I don't know if they mind maintaining the compiler themselves. 
Most likely they need a proof of concept and industry backing to 
get management approval for a bigger budget. Also, you get better 
tooling such as dedicated IDEs by being open.

In the end I assume they will fork clang and maintain their own 
C++ parser/semantic analysis in addition to maintaining a Carbon 
compiler written from scratch. I assume they have millions of 
lines of C++ code and the Carbon repo will pass 10 times the 
number of likes that is on the DMD repo in another week (they are 
close to 20K likes after only a week). Despite the syntax…

Or… maybe they will drop it after a year and take their 
design-artifacts as improvments to ISO C++. Either way, the 
Carbon team doesn't have much to loose from this approach. (The 
risk is on the early adopters.)
Jul 26 2022
parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 26 July 2022 at 11:44:19 UTC, Ola Fosheim Grøstad 
wrote:

 [snip]
 Or… maybe they will drop it after a year [snip]


It is Google...
Jul 26 2022
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 25 July 2022 at 02:56:53 UTC, Tejas wrote:

 All the disinterest/lack of belief regarding Carbon's 
 (potential)success is really making me think about Go, where 
 people said something about it not having used any of the 
 research in type theory since the 1970s, coupled with their 
 insistence on not having generics, a stupid error handling 
 system all combined to make it stand no chance in the future.

 But it's still popular today

 Maybe there's a non-trivial chance Carbon will end up the same? 
 As we have already seen, it's not always about the technical 
 merit.


Well, Go has some key technical merits: solid GC, stable 
non-breaking language, fast spinup time (compared to Java), easy 
build process, web-centric standard library.

So it is ok for smaller services that are to be maintained for 
years and years. I don't think Go is a good language, but I am 
also not able to point to another language that is more suited 
for hosting micro-web-services.

How does Carbon fit into this? By and large, slightly 
higher-level than C++, yet potentially better performing.

How can Carbon achieve this? By doing the opposite of D: throwing 
out C.
Jul 25 2022
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Monday, 25 July 2022 at 08:05:52 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 25 July 2022 at 02:56:53 UTC, Tejas wrote:

 All the disinterest/lack of belief regarding Carbon's 
 (potential)success is really making me think about Go, where 
 people said something about it not having used any of the 
 research in type theory since the 1970s, coupled with their 
 insistence on not having generics, a stupid error handling 
 system all combined to make it stand no chance in the future.

 But it's still popular today

 Maybe there's a non-trivial chance Carbon will end up the 
 same? As we have already seen, it's not always about the 
 technical merit.


 Well, Go has some key technical merits: solid GC, stable 
 non-breaking language, fast spinup time (compared to Java), 
 easy build process, web-centric standard library.

 So it is ok for smaller services that are to be maintained for 
 years and years. I don't think Go is a good language, but I am 
 also not able to point to another language that is more suited 
 for hosting micro-web-services.

 How does Carbon fit into this? By and large, slightly 
 higher-level than C++, yet potentially better performing.

 How can Carbon achieve this? By doing the opposite of D: 
 throwing out C.


Throwing C is the worst one can do

Throwing C++ too is not the right way to go

The proper way to do is following Kotlin's success, embracing it 
to then do your own thing

The problem is most languages can't get past "embracing C", and 
they are stuck with it

Carbon already on a poor start by having to predeclare everything

It's 0.1, so they have long way to go, but reading what their 
goals are and roadmap makes it clear that it's something with 
huge potential, for people with C++ codebases

I feel you guys put too much emotions in your analysis, same with 
Go
Jul 26 2022
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 26 July 2022 at 13:09:03 UTC, ryuukk_ wrote:

 On Monday, 25 July 2022 at 08:05:52 UTC, Ola Fosheim Grøstad 
 wrote:

 [...]


 Throwing C is the worst one can do

 Throwing C++ too is not the right way to go

 The proper way to do is following Kotlin's success, embracing 
 it to then do your own thing

 The problem is most languages can't get past "embracing C", and 
 they are stuck with it

 Carbon already on a poor start by having to predeclare 
 everything

 It's 0.1, so they have long way to go, but reading what their 
 goals are and roadmap makes it clear that it's something with 
 huge potential, for people with C++ codebases

 I feel you guys put too much emotions in your analysis, same 
 with Go


It is easy to see where this goes if their business unit funding 
doesn't run out.

Most of the team are ex-clang contributors that have moved on 
from clang and ISO related work, since Google lost the ABI break 
vote at ISO C++.

Carbon primary customer base is Google itself.
Jul 26 2022
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 26 July 2022 at 13:09:03 UTC, ryuukk_ wrote:

 Throwing C is the worst one can do


Because? There is nothing particularly interesting about C, 
except very poor typing.

Besides, they already did this, you cannot increment pointers for 
instance.



 Throwing C++ too is not the right way to go


Well, they did this too. They interop with it, but they do it in 
such a way that they have the option to phase it out in a later 
version, if my reading between the lines is correct.



 The proper way to do is following Kotlin's success, embracing 
 it to then do your own thing


Kotlin's success is Android, but the JVM environment is a 
completely different setting.

I guess you could say this is like Objective-C/Swift, but I 
suspect that Apple will phase out Objective-C eventually.



 The problem is most languages can't get past "embracing C", and 
 they are stuck with it


C is a big bleeding wound in your type system.



 I feel you guys put too much emotions in your analysis, same 
 with Go


In what way? I observe what they do, what they say and how the 
wider programming community responds… There are no emotions 
involved.

What they have said is that Google has one team looking at 
integrating C++ with Rust. Then they have the Carbon team going 
the other way, from C++ towards something closer to Rust, and 
this is experimental.

At this stage, this probably is tagged as research and not 
development, that is my guess. They put a lot of emphasis on 
experimental, they would not do that if they had been allocated 
40+ developers. So I guess they have to prove that this is a 
project that should move from research to development by showing 
industry interest or something like that? It isn't obvious that 
this is an initiative from high level managers, probably the 
other way around, don't you think?
Jul 26 2022
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Tuesday, 26 July 2022 at 13:31:00 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 26 July 2022 at 13:09:03 UTC, ryuukk_ wrote:

 Throwing C is the worst one can do


 Because? There is nothing particularly interesting about C, 
 except very poor typing.



Because there is code still written in C, and rewriting it is not 
worth it, languages able to play nice with C gets ahead (C++, GO 
with cgo for example, they were able to kickstart a lot of their 
projects, and our beloved D too ;))




 Besides, they already did this, you cannot increment pointers 
 for instance.



 Throwing C++ too is not the right way to go


 Well, they did this too. They interop with it, but they do it 
 in such a way that they have the option to phase it out in a 
 later version, if my reading between the lines is correct.



That's the thing i mention, being able to consume it to then eat 
it and get rid of it, most languages are stuck at the consume it 
part, Go managed to get past it



 The proper way to do is following Kotlin's success, embracing 
 it to then do your own thing


 Kotlin's success is Android, but the JVM environment is a 
 completely different setting.

 I guess you could say this is like Objective-C/Swift, but I 
 suspect that Apple will phase out Objective-C eventually.



Kotlin is also phasing out Java/JVM by focusing on Kotlin Native 
for sharing code between Android/iOS and they are working on 
their WebAssembly compiler; completly phasing out JVM, notice the 
pattern ;)


 The problem is most languages can't get past "embracing C", 
 and they are stuck with it


 C is a big bleeding wound in your type system.


 I feel you guys put too much emotions in your analysis, same 
 with Go


 In what way? I observe what they do, what they say and how the 
 wider programming community responds… There are no emotions 
 involved.



Maybe emotions wasn't the proper word, skepticism maybe, i don't 
know, it's an impression i have, Go have merits and i feel we 
downplay its success a little, we should learn from it



 What they have said is that Google has one team looking at 
 integrating C++ with Rust. Then they have the Carbon team going 
 the other way, from C++ towards something closer to Rust, and 
 this is experimental.

 At this stage, this probably is tagged as research and not 
 development, that is my guess. They put a lot of emphasis on 
 experimental, they would not do that if they had been allocated 
 40+ developers. So I guess they have to prove that this is a 
 project that should move from research to development by 
 showing industry interest or something like that? It isn't 
 obvious that this is an initiative from high level managers, 
 probably the other way around, don't you think?


Exactly, i agree with you
Jul 26 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 26 July 2022 at 14:35:21 UTC, ryuukk_ wrote:

 Because there is code still written in C, and rewriting it is 
 not worth it, languages able to play nice with C gets ahead 
 (C++, GO with cgo for example, they were able to kickstart a 
 lot of their projects, and our beloved D too ;))


Sure, they will be able to call C, I thought you meant that the 
language would retain C semantics at the bottom layer.


 That's the thing i mention, being able to consume it to then 
 eat it and get rid of it, most languages are stuck at the 
 consume it part, Go managed to get past it


True, it makes no sense for Carbon to stay at C++17 compatibility 
when C++ hits C++29 :-)


 Kotlin is also phasing out Java/JVM by focusing on Kotlin 
 Native for sharing code between Android/iOS and they are 
 working on their WebAssembly compiler; completly phasing out 
 JVM, notice the pattern ;)


Interesting, I didn't know this.


 Maybe emotions wasn't the proper word, skepticism maybe, i 
 don't know, it's an impression i have, Go have merits and i 
 feel we downplay its success a little, we should learn from it


Yes, having a coherent memory management story is important. Go 
had a coherent memory management and concurrency solution from 
V1.0. That makes a biiig difference. It doesn't even have to be 
excellent, just something you can rely on.

Carbon does not have this yet, though… so maybe their success 
depends on how many years it takes for them to get there.
Jul 26 2022
parent reply IGotD- <nise nise.com> writes:
On Tuesday, 26 July 2022 at 15:36:10 UTC, Ola Fosheim Grøstad 
wrote:

 Yes, having a coherent memory management story is important. Go 
 had a coherent memory management and concurrency solution from 
 V1.0. That makes a biiig difference. It doesn't even have to be 
 excellent, just something you can rely on.

 Carbon does not have this yet, though… so maybe their success 
 depends on how many years it takes for them to get there.


They should be careful and determine roughly what kind of memory 
management they want as early as possible. If they don't they 
risk ending up like D which is painted into a corner with tracing 
GC and there is also a risk with too much annotation like Rust. 
Nim did this right as they have a good compromise between easy of 
use and GC versatility.

V language is currently using a tracing GC as a back drop until 
their "auto free" engine is complete, we will see how they 
succeed. Nim is similar that sometimes their ORC GC fails and you 
need to use Bohem. In general the strategy should be keep it 
simple and stupid in the beginning at the same time you do not 
prevent any advancement of new GC methods which D totally failed 
at.

That they mentioned that they want to a have lifetime annotation 
like Rust makes me suspicious that they will fail their goal, 
which is a simpler C++. Rust is not simpler than C++ as long you 
don't trench too far into meta programming and templates.
Jul 26 2022
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 26 July 2022 at 16:00:38 UTC, IGotD- wrote:

 That they mentioned that they want to a have lifetime 
 annotation like Rust makes me suspicious that they will fail 
 their goal, which is a simpler C++. Rust is not simpler than 
 C++ as long you don't trench too far into meta programming and 
 templates.


Carbon will not have a GC. It will also not have Rust semantics 
as the checker would be too slow, at least that is what has been 
said.

Carbon will have more limited generics than C++, so that the 
"template" can be selected based on the signature constraints 
without instantiating it. In that sense it is simpler than C++.

I think they actually aim for faster than C++. I assume faster 
compilation and perhaps more clever optimizations, but I don't 
know if it is realistic to expect any significant speedups for 
performance oriented code. Perhaps for naive code?

I would hope that it would be possible to use ARC, but I don't 
think this will come from Google. I suspect ARC is "too slow" for 
their use cases?

I would hope that they make the compiler modular so that things 
like ARC can be "plugged" in by a third party.
Jul 26 2022
parent reply Tejas <notrealemail gmail.com> writes:
On Tuesday, 26 July 2022 at 16:34:49 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 26 July 2022 at 16:00:38 UTC, IGotD- wrote:

 That they mentioned that they want to a have lifetime 
 annotation like Rust makes me suspicious that they will fail 
 their goal, which is a simpler C++. Rust is not simpler than 
 C++ as long you don't trench too far into meta programming and 
 templates.


 Carbon will not have a GC. It will also not have Rust semantics 
 as the checker would be too slow, at least that is what has 
 been said.

 Carbon will have more limited generics than C++, so that the 
 "template" can be selected based on the signature constraints 
 without instantiating it. In that sense it is simpler than C++.

 I think they actually aim for faster than C++. I assume faster 
 compilation and perhaps more clever optimizations, but I don't 
 know if it is realistic to expect any significant speedups for 
 performance oriented code. Perhaps for naive code?

 I would hope that it would be possible to use ARC, but I don't 
 think this will come from Google. I suspect ARC is "too slow" 
 for their use cases?

 I would hope that they make the compiler modular so that things 
 like ARC can be "plugged" in by a third party.


I don't think they can afford to provide any automatic memory 
management solutions, since everyone is basically looking for an 
excuse to hate on them

At best, I can imagine them enshrining C++'s `make_shared`, 
`shared/unique_ptr`, etc constructs for better 
optimisations/error reporting/airtight implementations, so that 
nobody can accuse them of introducing performance detrimental 
things like GC(notwithstanding the fact that RC is also a GC 
technique)

I genuinely think this thing might be successful, people disliked 
Go so much, yet look where it is today: the entire foundation of 
the cloud is built on it; Dart had nothing to it's name, now it's 
fighting JavaScript for supremacy as the most cross-platform 
friendly language; I feel Carbon will be a similar success as 
well, if they really get C++ interop, tooling, and job 
opportunities right
Jul 26 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 27 July 2022 at 03:51:28 UTC, Tejas wrote:

 I don't think they can afford to provide any automatic memory 
 management solutions, since everyone is basically looking for 
 an excuse to hate on them


They have already scared away the most opinionated C++ users by 
using an unfamiliar syntax and removing things like constructors, 
multiple inheritance and exceptions...



 At best, I can imagine them enshrining C++'s `make_shared`, 
 `shared/unique_ptr`, etc constructs for better 
 optimisations/error reporting/airtight implementations, so that


That would be great, as make_shared provides the same as you 
would get from ARC in Swift!



 I genuinely think this thing might be successful, people 
 disliked Go so much, yet look where it is today: the entire 
 foundation of the cloud is built on it;


Yeah, that is the scary part, isn't it? Carbon currently uses 
«CapitalizedFunctionNames()» just like public Go functions. Which 
is somewhat annoying as it creates a rather noisy picture in the 
editor. I prefer everything in a standard-lib being lower case as 
my own types should be more visible than the standard ones. 
(Phobos…).



 I feel Carbon will be a similar success as well, if they really 
 get C++ interop, tooling, and job opportunities right


I don't think they will start implementing the compiler itself 
until late 2023, so I guess we have to wait and see. Maybe ready 
for adoption in 5 years? So they effectively compete with what 
people expect from C++29?

I would feel better about Carbon if they had to compete with C++, 
as then they would listen more to the community, but maybe they 
only "compete" with their own management? In which case it will 
end up with whatever Chandler Carruth fancies.

Anyway, they are open for breaking changes for another year, and 
that is a breath of fresh air :-)
Jul 27 2022
prev sibling parent reply Araq <rumpf_a web.de> writes:
On Tuesday, 26 July 2022 at 16:00:38 UTC, IGotD- wrote:

 Nim is similar that sometimes their ORC GC fails and you need 
 to use Bohem.


No, that's not how Nim's ORC works. It is precise and doesn't 
need Boehm. But nice try to conflate my decade of hard work with 
some vaporware clown language.
Jul 26 2022
parent reply IGotD- <nise nise.com> writes:
On Wednesday, 27 July 2022 at 05:08:24 UTC, Araq wrote:

 No, that's not how Nim's ORC works. It is precise and doesn't 
 need Boehm. But nice try to conflate my decade of hard work 
 with some vaporware clown language.


That was because of bugs in ORC where it was necessary to revert 
to an earlier GC type, for example Bohem. Will ORC be production 
ready?
Jul 27 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
Btw, looks like Carbon might end up with the same parameter 
passing as `-preview=in` ?

https://www.foonathan.net/2022/07/carbon-calling-convention/
Jul 31 2022