Jump to page: 1 29  
Page
Thread overview
New competitor to D
Jul 19
Tejas
Jul 19
Tejas
Jul 19
Tejas
Jul 20
Kagamin
Jul 20
Kagamin
Jul 21
Kagamin
Jul 21
Kagamin
Jul 19
ryuukk_
Jul 19
jmh530
Jul 19
IGotD-
Jul 24
Don Allen
Jul 19
Martin B
Jul 19
Ali
Jul 20
jmh530
Jul 20
ryuukk_
Jul 20
Tejas
Jul 20
ryuukk_
Jul 20
ryuukk_
Jul 20
ryuukk_
Jul 21
ryuukk_
Jul 22
M.M.
Jul 23
ryuukk_
Jul 23
ryuukk_
Jul 23
ryuukk_
Jul 23
Martin B
Jul 23
ryuukk_
Jul 23
ryuukk_
Jul 24
claptrap
Jul 24
IGotD-
Jul 25
Tejas
Jul 26
jmh530
Jul 26
ryuukk_
Jul 26
ryuukk_
Jul 26
IGotD-
Jul 27
Tejas
Jul 27
Araq
Jul 27
IGotD-
July 19

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)

July 19

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++.

July 19

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?

July 19

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.

July 19

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

July 19
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
July 19

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.

July 19

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 :
«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… ;-)

July 19

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

July 19
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
« First   ‹ Prev
1 2 3 4 5 6 7 8 9